Time from time there are mails from FFmpeg developers to different distributions saying “Oh, we are better, have more features and more secure, pick us and not libav”. In case somebody wonders here are two examples: Ubuntu and Debian.
So let’s walk through and see the claims. Comparison was made from git snapshots made 2011-10-15 11:00 CEST.
More codecs
FFmpeg claims to have more codecs. In numbers that’s true. Let’s see what are those codecs though:
- VDPAU accels for MPEG-1 and MPEG-2.
- AMV encoder. Really just a quick hack to flip picture before using standard JPEG encoding.
- 8SVX raw audio. Really just a hack to support one particular case of raw planar audio.
- Flash Screen Video 2 encoder. If you look at the discussion here and the committed file you’ll see that encoder was committed by the same person who had some objections but they never were addressed. Also committing encoder for the codec without any working opensource decoder (well, no decoder beside Adobe Flash client could decode the output properly) is not the brightest idea IMO.
- CrystalHD MPEG-2, MPEG-4, H.264 and VC-1 support.
- JPEG-2000 codec. Known to be very buggy and yet included.
- M$ Video 1 encoder. That was the last review for it – link on gmane and then it was just committed verbatim. Such hypocrisy is one of the reasons I don’t contribute to FFmpeg directly (they pull all patches from libav anyway).
- DTS encoder. It was considered not to be good enough by the person who was responsible for its development (Benjamin Larsson) but not bad enough to not be included to FFmpeg.
- G.723.1 codec. The same story.
- G.729 decoder. It was abandoned halfway by original developer so it’s not complete and buggy.
- Sonic codec. An experimental codec that was not touched since 2004. It’s not supported by anything and my tests show that it often cannot even compress audio losslessly (output size is bigger than original). That’s why we finally threw it out at libav.
- Subtitle and text codecs.
- Stagefright H.264 decoder. It’s too ugly to be included to libav (C++ ABI issues, internal bitstream filter usage).
- Speex encoder wrapper and Celt encoder wrapper.
- libaacplus encoder wrapper. It’s based on 3GPP source code and hence not redistributable.
In conclusion, those additional codecs supported by FFmpeg are either hardware acceleration (VDPAU, CrystalHD, stagefright), trivial or some old patches previously rejected but now picked up to maintain impression of superiority.
More muxers and demuxers
Now to muxers and demuxers.
- ACT and BIT demuxers. Containers for G.729 data.
- ADF/IDF/bintext/xbin demuxers Containers for text formats.
- CAF muxer.
- G.723 demuxer. Container for G.723 data
- LOAS demuxer. It’s just a hack for probing raw AAC stream.
- MicroDVD subtitles muxer and demuxer.
- PMP demuxer.
- WTV muxer.
- libmodplug Module tracker file support (libmodplug decodes the files, demuxer outputs decoded raw sound and optional text information).
Most of (de)muxers are either for formats we don’t support or trivial. But I admit there are maybe two demuxers and one muxer that can be included into libav after some cleanup.
Filters
I’m not fully familiar with filter subsystem but it still has too many problems and having an ugly wrapper for MPlayer filters (which are also not of the highest code quality) was one of the points that drove FFmpeg-libav split.
Features, security and overall
When FFmpeg claims to have more features than libav it’s true — they merge everything from libav nowadays. And FFmpeg gets more side features for two reasons: the name is more known and it’s easy to get a feature in because nobody seems to bother with proper reviews nowadays. As for security, it’s the same. For example, when there was a report for some minor security flaw in Chinese AVS decoder, original patch from security investigators (applied in FFmpeg) just made decoder more secure but it still crashed on that file, in libav we created our own patch that dealt with both of these problems. FFmpeg often reminds me of a saying “Socialistic system successfully overcomes the problems it creates itself”.
In conclusion, my opinion is that FFmpeg is trying to compete with libav by lowering standards on accepted stuff. Hence the name of this post.
And I’m glad we can’t have commits like this. For those who have not so good C understanding: it compares addresses of two different strings and it’s an undefined operation that works mostly by luck. So my advise is simple: if you want quality then choose libav, if you want some special features — look for suitable fork at github.
