Multithreaded playback

Multithreaded playback

If I read that right, still no non-slice based H.264 multithreaded decoding though? In the mainstream (though patent-encumbered, where applicable) world, that would be an important step. Though there is "multithreaded/SMP motion estimation", does that help with this too?

I've sometimes wondered, since doing proper parallel decoding is evidently hard work, why don't they slap in the quick and dirty solution: just start decoding from two (or more) adjanced keyframes and buffer. Sure, you'll have to buffer a lot, and sure, there'd perhaps be a slight delay or some stutter in starting the playback and right after a seek, but wouldn't this be an otherwise easily workable solution while waiting for frame/block-based parallelization, given enough memory?

Mind you, "enough" is not even that much nowadays. A 10-second buffer of uncompressed 1080p30 video would take ~1.75 gigabytes of memory, less at 24 fps. Mainstream content tends to have much smaller keyframe intervals, blu-ray around a second IIRC (necessitating around 2 seconds of buffering with dual decoders), and digital television can't have a very large interval either to facilitate changing channels. So, while the 10-second example buffer still is actually not that hard to come by on many computers today, it's also conveniently overkill for many if not most applications.

I'm not very knowledgeable in this field, so feel free to educate me why this shouldn't be a workable interim solution for generic (and pretty much codec-agnostic!) multithreaded playback of HD content?