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

Baptiste Coudurier baptiste.coudurier
Fri Dec 3 12:00:03 CET 2010


On 12/2/10 8:24 PM, Jason Garrett-Glaser wrote:
> On Thu, Dec 2, 2010 at 8:35 PM, compn <tempn at twmi.rr.com> wrote:
>> 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?
> 
> I wish.  It's hard enough for students to figure out which filters are
> and aren't being ported -- even for the ones on the mailing list!
> 
> Currently, IIRC, we have gradfun and 2xSAI through GCI.  Someone else
> is porting "fil", I think.

In any case, thanks for the help, Jason, this is appreciated.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list