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.
Where does so much hate comes from? :\
That fork was the dirtiest think in OSS world i’m aware of. Why exactly do you make such posts instead of coming back to ffmpeg? Are there any technical issues, which cannot be fixed in ffmpeg but are addressed in libav, or is it only a personal thing?
You forgot one decoder: FFmpeg has two ProRes decoders. One written by a famous and dead person and being constantly renamed to avoid confusion.
Dear Anonymous,
I don’t think trying to engage in that discussion anonymously will be any help. So I’ll just ignore you.
@Janne
I’m aware of their additional decoder but I have nothing to say about that situation (and nobody will see me facepalming anyway).
G729 decoder is in such a bad shape, there are just two things that bothers me: the problem with dsputil.scalarproduct_int16 and the G729_BITEXACT define.
@Vitor
dsputil.scalarproduct_int16 is messed up indeed, during MMX part review it was requested to use shifts at the end of scalar product, so it produces wrong result for speech codecs, there was something wrong with NEON version too.
@Kostya
dsputil.scalarproduct_int16 is only used for G729, and in this codec calls it only with “shift == 0”. My plan is to remove the shift parameter from the function to actually have something whose C code matches MMX.
“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.”
Doesn’t the fact that said string are found within the same static const array of structs matter here, i.e. we are just comparing pointers within this array? I indeed don’t know enough the standard to know what section would be relevant.
@kurosu: It’s section 6.5.6: “When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object.” Different string literals are distinct objects thus do not fulfil this requirement.
You neglected to mention the biggest mistake in that linked commit: misspelling ‘conversion’. 🙂
From a distance, this smells a lot like FreeBSD vs. OpenBSD 😀
[ I don’t think the Debian and Ubuntu comparison is valid. Debian still publishes all those new/incomplete/buggy/niche features like you describe in the unstable package repository. The Debian comparison would be more valid, if the libav group tracked the ffmpeg patches in similar way. Perhaps you are already doing that with a git unstable branch, I haven’t looked lately! ]
iirc reimar wrote the pmp demuxer based from the mplayer pmp demuxer found in mplayer-ww project.
pmp samples are in the usual place.
people complained years ago when ffmpeg development was slow and patches were meticulously reviewed and each patch author had to babysit his patches. sometimes patches were resubmitted and reviewed for months on end. now ffmpeg has faster commits than it previously did, and people complain that the code quality has dropped.
theres no pleasing anyone around here.
The G723.1 code is in good shape. The DTS encoder is ok but dead slow, not good enough to merge though.
The pmp demuxer in mplayer-ww was just confusing, I took a few hints about the format from it but the FFmpeg pmp demuxer is rather based on my own reverse engineering.
I implemented it because some people made builds with the other demuxer which had some rather serious security issues.
If there are issues (beyond that nobody sent a patch, which I am too lazy to do) that keep it from Libav I’ll look into it.
And while I see the point about them (maybe :-)) not making a good argument to prefer FFmpeg for distributions, I do think it is good that more of the “somewhat but maybe not quite” working patches are now collected in a single place.
Are you stupid or what?
I find it interesting to criticise ffmpeg for being _more_ accepting of patches, when this seemed to be the underlying theme for the libav fork.
Subtitle and text codecs.
Speex encoder wrapper and Celt encoder wrapper.
libaacplus encoder wrapper.
This already means less work to make customers happy. I’d rather have something half broken than code myself everything! You seem to forget that code patents are not enforceable everywhere on the planet. For libaacplus google seems ho have bought from On2 a license, http://spectralhole.blogspot.fr/2010/12/androids-stagefright-aac-encoder-or.html.
On a positive side I have seen a huge number of new features since the split-up (and as many core dumps 🙂 )
libav are more close to freesoftware guidelines.. and ffmpeg are more close to opensource but with optional “features” including “all” possibilities..
this are the most powerfully reason that many multimedia related professionals dont swicht to libav zealot’s its this fanatic do not include feature that is not free stupid … etc etc
i prefer one thing that enable all posible fatured that i could be need, rather thant a fanatic libav non capable due FSF guidelines.,.
I came across this post when googling for information about libav. I am an Ubuntu user and have been migrated to libav by my distro. I have no opinion about the fork and no preference for either ffmpeg or libav. I do however have an opinion about user choice and the problem I just faced (and solved) is not one that users should be confronted with. I needed AAC encoded output. By default this is not available in libav in Ubuntu. Whatever the reason, I am OK with this kind of crippling as long as users are empowered to fix the crippling themselves. I found the fix on the ffmpeg side of the fork: . I have found no such user-empowering document on the libav side of the fork. I agree with you that the quantity of codecs and other features is (or should) not (be) the critical decision-making factor. Lack of users-empowerment is what disturbs me about libav. The user is served eye-candy and easy downloads. Unfortunately the easy downloads are incomplete. I rather have a handbook that helps me looking under the hood and tune the software to do what I need. You may want to fix this on libav.org:
cd ~/src
git clone –depth 1 git://git.libav.org/libav.git
cd libav
./configure
./configure –enable-gpl –enable-libfaac –enable-libfdk-aac –enable-libmp3lame \
–enable-libopencore-amrnb –enable-libopencore-amrwb –enable-librtmp –enable-libtheora \
–enable-libvorbis –enable-libvpx –enable-x11grab –enable-libx264 –enable-nonfree \
–enable-version3
make
sudo make install
The article talks about a DTS encoder developed by Benjamin Larsson. Do you mean something else than dcaenc.c in ffmpeg source? That would be very interesting to read. [I am asking because I am the author of http://aepatrakov.narod.ru/dcaenc/, a standalone open-source DTS encoder that is not part of ffmpeg, and dcaenc.c in ffmpeg was actually based on my very early draft that served only the purpose to understand the QMF transform].
Also I think I should say that I had a conversation with Michael Niedermayer in October 2012, where he reported a bug in allegedly-my code (but actually in the code contributed by Xiang Wang). As a response, I suggested to delete the encoder, because it is too incomplete even after several years of being there, and the relatively recent addition of 5.1
encoding actually produces broken streams. Still, the experimental encoder is there, and even receives some “unused header” type of cleanups.
@Alexander
Of course we know that you are the original author, I meant the fact that your code served as a base for native encoder in FFmpeg. And that work (enhancing your encoder, porting it for libavcodec and such) was performed by Xiang Wang under mentoring of Benjamin Larsson (that’s why he’s called “person responsible for development”, not developer). I’m sorry that it was not clear enough.
As for me, I would like to see libmodplug support in libav. After all I have some tracker music and I don’t see why I should lack access to them via “universal” library. So to the date ffmpeg wins one point for me, sorry.