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

[Vitor Sessak]

Jason Garrett-Glaser wrote:
>> 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

[...]

> 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?

How many forks of dsputils would this produce? Not to mention 
copy&pasting our FFT implementation and lots of code shared between 
codecs. Or did you suggest we fork libvorbis/FLAC/etc?

-Vitor