FFmpeg 0.5 released [LWN.net]

It has been a long time since we have seen an FFmpeg release, but version 0.5 is now out. As one might expect, the changes are extensive and are mostly in the form of new codecs. More information can be found on the web site and in the version 0.5 changelog. "It is codenamed 'half-way to world domination A.K.A. the belligerent blue bike shed' to give an idea where we stand in the grand scheme of things and to commemorate the many fruitful discussions we had during its development."

to post comments

I like the codename

Posted Mar 10, 2009 15:00 UTC (Tue) by renox (guest, #23785) [Link] (1 responses)

Apparently the one who choose the codename had his tongue firmly planted in his cheek ;-)

I like the codename

Posted Mar 11, 2009 18:34 UTC (Wed) by jd (guest, #26381) [Link]

It's to distinguish it from the belligerent blue police box.

Multithreaded playback

Posted Mar 10, 2009 16:21 UTC (Tue) by mjr (guest, #6979) [Link] (3 responses)

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?

Multithreaded playback

Posted Mar 10, 2009 19:33 UTC (Tue) by jengelh (subscriber, #33263) [Link] (1 responses)

(BTW, I have found that turning off GMC and B-Frames during encoding benefits decoding speed, at the cost of somewhat increased file size. But it is damn well worth it if you want to watch stuff on low processing power devices.)

As to your comment about needing large amount of memory for the cache:

You could stop decoding just before the RLE codes are unpacked, and do that decoding step then just right before the frame is displayed. Unpacking the RLE and applying the delta-frame should be pretty straightforward.

Multithreaded playback

Posted Mar 12, 2009 4:44 UTC (Thu) by krasic (guest, #4782) [Link]

After RLE, you have to apply the idct, iquant, and then apply the delta. That's still a lot of work.

No?

Multithreaded playback

Posted Mar 10, 2009 20:26 UTC (Tue) by rathann (subscriber, #50815) [Link]

There is an experimental branch which aims to implement frame-based multithreaded decoding, but it's still incomplete. Feel free to try it out and/or help with its development. You can find it behind the URL below.

http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt