[Ffmpeg-devel] I'm giving up

Michael Niedermayer michaelni
Tue Nov 21 16:17:04 CET 2006


Hi

On Tue, Nov 21, 2006 at 01:44:10PM +0100, Cyril Russo wrote:
[...]
> What could have been a 5 mn process is becoming a 3 days issue for what 
> ? 50 lines of code.

there are 1 line changes which get discussed for month before they are
accepted or rejected


> 
> > Can you do a benchmark also ? More info here:
> 
> I don't know if it's me. In the previous code, s->progressive was tested 
> 3 times in an iteration while it doesn't change inside the loop at all.
> Then there are 2 possible cases :
> - The compiler is smart enough to move the test out the loop, it is 
> going to duplicate the code with 2 paths (but the path are not the 
> exactly same length, so I really doubt the compiler will do it), in that 
> case there will be twice as much code as currently.
> - The compiler let the processor predict the branch, which result in 
> much more code anyway (because the branches are still here), and it is 
> not faster than the patched function.
> 
> My first patch did this, creating a new function with all tests removed. 
> It was 34 lines long.
> The attached patch use function pointers which are set at declaration 
> and add 1 line to current mjpeg.c file.

well, first there are 2 unrelated optimizations in the patch first changes
idct_add/put to a single pointer the second does the same with decode_block

for the idct case i have no doubt that your code is faster still a benchmark
would be interresting
for the second case there is an extra wraper function and more arguments get
passed so it could be faster or slower, a benchmark is needed before this
part can be applied or rejected
also the inline keyword for the wraper function is useless as its only called
through a function pointer


> 
> Anyway, I give up. I'm sorry if I'm too blue or too red for you. My 
> initial purpose was to give back since I'm using ffmpeg, and so far, 
> I've followed the lines to contribute back correctly.
> My contribution was very, very easy to check/deny/modify. In fact, 
> you've spent more time criticizing the shape of the sun than understand 
> why it shines.
> I'm fed up having to justify myself everytime, instead of explaining 
> what I've done.

you dont have to explain what you done as i understand your code if i
didnt i would have asked (similarely if anyone else wouldnt understand
it they too would ask i guess ...)

and you dont have to justify anything, its just that we have some strict
rules about code quality, and no doubt they are a PITA to follow sometimes
still i dont think it would be in anyones interrest if we would apply every
patch which adds a feature or fixes a bug independant of how its done ...

also ive seen many cases where trivial optimizations (removial of unused
variables or removial of duplicated expressions) caused the code to run
slower so benchmarks are generally very welcome for anything which is
supposed to make the code faster

also if you disagree with some rules, decissions or comments feel free 
to disscuss them here

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list