[FFmpeg-devel] Google Summer of Code 2010 is coming
Sat Jan 30 16:36:58 CET 2010
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
> 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
>> 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
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?
More information about the ffmpeg-devel