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

Jason Garrett-Glaser darkshikari
Fri Dec 3 05:24:19 CET 2010

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


More information about the ffmpeg-devel mailing list