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

[compn]

On Thu, 2 Dec 2010 19:07:38 -0800, Jason Garrett-Glaser wrote:
>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.

well, you could always tell the students not to change the libmpcodecs
asm when portan' :)

is there a repo or wiki or webpage or ml that has a summary of done
filters or porting status etc? or is it all organized on irc (and if
irc, which channel?

-compn