[FFmpeg-devel] Read this if you are porting filters from MPlayer

[Jason Garrett-Glaser]

On Thu, Dec 2, 2010 at 6:46 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Dec 02, 2010 at 05:58:26PM -0800, Jason Garrett-Glaser wrote:
>> On Thu, Dec 2, 2010 at 4:52 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > Hi everyone
>> >
>> > Its great to see all the porting effort.
>> > Its less great that the quality of alot of that is kinda uhm...
>> > Ive the feeling people just want to, at any price change the existing code in
>> > ways totally unrelated to porting. Dont do it, dont even think of doing it!
>> > It costs you time to do, it costs me time to review and benchmark the changes
>> > and with 99% chance if you didnt benchmark. your change will be to the worse
>> > (thats unless your name is jason, loren, fabrice, arpi and a few others)
>> > and you will have to painfully undo it. Because i will benchmark your filter
>> > and if mplayers original is faster even by just 1% you get a 1 line
>> > "rejected its slower" comment and you can then find out where you messed up
>> > Similarly if theres some feature dissappearance like geqs ability to read
>> > from arbitrary pixels disappearing.
>> >
>> > There have been man-years of optimization and debuging thrown into mplayers
>> > filters. If you feel like throwing that away and playing NIH then i suggest you
>> > rather play russian roulett. That at least doesnt waste precious review time.
>> >
>> > Porting is one thing, and is easy to review and get approved.
>> > Changes to the code are another thing and also easy to get approved if they
>> > are to the better.
>> > But mix them and review becomes hard because its no longer clear what has
>> > been changed for porting and what because the author felt an itch about
>> > something.
>> > Also consider to diff your code against mplayers before submitting. Iam going
>> > to compare it no matter how its posted and i will find changes and make
>> > sarcastic comments about them if they are completely brain amputated
>> >
>> >
>>
>> You should not be so harsh on high school students... this is not
>> Google Summer of Code, this is Google Code-In. ?Most of them neither
>> have the time, nor the skill; nor the sanity, to deal with this level
>> of nitpicks.
>>
>> I am doing my best to try to recruit new blood to the project; don't
>> scare them away.
>
> its embarrassing but i was unware of them being students from code in.
> if them being high scool students being considered i agree with you that my
> comment was way too harsh, i was writing this in the belive that they where
> older and experienced developers
>
> Thats what happens with IRC-logs being dead and myself not being on IRC ...
> either way id appreciate if people could give a quick summary of such major
> things like google code in students from other projects working on ffmpeg.
> Not everyone is on IRC and i would suspect iam not the only one who didnt
> know about that.

Summary:

1.  x264 got into Google Code-In through Videolan.

2.  One of our proposed tasks was to port filters to x264's filter framework.

3.  Loren decreed that we shall port them to libavfilter instead, then
call them from x264, to avoid code duplication.

4.  <We smuggle ffmpeg tasks into Google Code-In through x264 through Videolan>

5.  The current situation.

Sorry for not keeping you up to date.

Jason