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

[Michael Niedermayer]

On Sat, Jan 30, 2010 at 01:30:26AM -0800, 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.

The question is why arent you the one telling him to add
AVOutputFormat dvbh264_muxer = {
    "dvb-h264",
    NULL_IF_CONFIG_SMALL("H264 specific DVB muxer"),
    "video/mpeg",
    "dvb",
    sizeof(DVBMuxContext),
    NULL,
    CODEC_ID_H264,
    init,
    write_packet,
    end,
};

?

was it in libavformat, every project using libavformat could use it
people could remux h264 videos from mp4,avi,...


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

You surely can have common ratecontrol, motion estimation, keyframe detecton
and a few other things.
what cant be common would have been seperate, we also support decoding
cavs, vc1, rv40 which are more different from mpeg2.


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

Thats a silly assumtation, the libc authors also can change printf()
without testing every existing application.
you just need a clear API between X and its users (ABCDEF)
also you can do development with just checking A and watching
fate do BCDEF. If it does break once in 20 commits you revert that single
commit and try again


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

this is just untrue, we have rv10,rv20,mpeg1,mpeg2,h261,h263,flv,
msmpeg4v1/v2/v3,wmv1,wmv2 use our mpegvideo framework.
Thats 12 encoders not 5 and never had i noticed that this draged
development down. Its very hard for a change to comon code to
break an encoder using it without breaking all others as well.


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

The difference is that ffmpeg is the multimedia framework where all these
codecs, muxers and demuxers should be. its what ffmpeg is about ...

you could compare this to
someone reimplementing NTFS for linux to support it vs.
someone else forking linux and redesigning it to just support NTFS while
droping support for every other file system and then dropping support
for everything except x86_32


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

uhm, better than what? we have no h264 encoder, so there really is
nothing that could be better or worse
but i could fork x264 and make it better, if you think this is the way
FOSS development should be done


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

Well, id still tell the libc maintainers that its not a good idea to
reimplement mysql if they tried but would not have a problem with mysql
reimplementing some database related functions if they need them instead
of linking to some other database.

Also if you could please at least write a fully functional TS/DVB muxer that
works with more than just h264 then we could (if it turns out better than ours)
borrow it and replace ours

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100130/00882652/attachment.pgp>