[FFmpeg-devel] Google Summer of Code 2010 is coming

Jason Garrett-Glaser darkshikari
Sat Jan 30 10:30:26 CET 2010


> of course not, its pure medical issue of the psychology part.
> Something about hatered, undermining of common efforts, NIH syndrom,
> ape courtship behaviour in the sense of "Look i got the bigger muxer"
> That just sounds better if you stand alone with your big muxer standing
> out.

Actually, I would of course support using libavformat's; the reason
that we're getting a DVB muxer is because someone wanted to write a
DVB muxer.  If I was the one writing it, I would NEVER have chosen to
do it like this.  But it's the choice of the author, and the author
isn't me.  He came to me after he had already written quite a bit of
it, so I wasn't exactly about to tell him to throw it out.
Furthermore, it has served the valuable purpose of helping us check
our HRD patch.

> In an alternative world x264 would be part of ffmpeg and all our
> mpeg1/2/4/h263/h261/rv/msmpeg4
> encoders would be able to use all the applicable improvments x264 contains
> sure x264 would be a few month behind where it is now as more work would
> have been needed for the integrating it all but i think it would be a
> overall better world for the end user

I don't believe that it's possible to develop a sane common framework
for dozens of different video formats.  It only worked for
MPEG-2/MPEG-4 derived formats because they were so conceptually
similar.

The main problem is simple: if changing X affects A, B, C, D, and E,
one is forced to test A, B, C, D, and E before changing X.  This takes
5 times more time and effort than merely checking A.  Development
wouldn't be "a few months behind", it would have been many times
slower, because every single change would have affected every a dozen
other encoders and required careful testing for each one.

Lastly, anyone working on ffmpeg who complaints about NIH syndrome and
reinventing the wheel is an absurd hypocrite.  ffmpeg's entire history
is filled with reinventions of the wheel: the native vorbis decoder
(and oh god, encoder), the native AAC encoder (why not fix the one
file with license problems in FAAC and make it better?), AMR-NB
(opencore already supports it), and so forth.  ffmpeg is covered with
capabilities, both major and minor, that were implemented first
somewhere else under a compatible license.  But since ffmpeg doesn't
like dependencies, we re-implement them.

But!--you might say--many of those decoders turned out much better
than the existing ones!  But wouldn't it have turned out better if you
redirected the effort towards the original instead of reinventing the
wheel?  The situation with, for example, ffmpeg's vorbis decoder and
libvorbis is hardly any different from ffmpeg and x264: ffmpeg wrote
an independent implementation of vorbis for no apparent reason
whatsoever other than to have one, and it turned out to be better.
x264 wrote an independent encoder implementation instead of placing it
in the current framework, and it turned out to be better.

For the past half decade ffmpeg has served as a bastion of
reinventions of the wheel.  Don't tell x264 to stop with the NIH when
ffmpeg has been addicted to NIH for years and continues to be so to
this day.

Now you know how libvorbis, FLAC and other such projects feel when
ffmpeg creates their own independent implementation instead of
contributing back to the original code.  Maybe you'll think about that
next time you fork yet another open source project to try to keep
ffmpeg's external dependency list short.

Dark Shikari



More information about the ffmpeg-devel mailing list