[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h

[Uoti Urpala]

On Tue, 2008-12-16 at 15:31 -0800, Baptiste Coudurier wrote:
> Uoti Urpala wrote:
> > I say a thrown die can end up any side up, and present a sequence of
> >  throws which shows every number appearing. You cannot reproduce the
> >  exact sequence of throws but you can reproduce every number 
> > appearing. You asking for the particular code changes I used is like 
> > asking for the particular way I threw the die to produce a certain 
> > number.
> 
> Comparing the situation to "die throwing" is awkward IMHO, considering
> your first sentence, you need to show me first that your die can end up
> and down. I did see this claim about the code, however Im still waiting
> for your backup, until this I do not trust you, and I refute your claim.
> 
> Furthermore code relates in nothing to die, since a die has a fixed
> number of faces at the beginning, code has probably unlimited number of
> variants, especially in this case (H264). Please choose a better example.

I told you how to reproduce the random behavior. Pick some h264 video
and benchmark decoder performance with that. Then add an unused function
in the middle of h264.c and repeat the benchmark with the new binary. If
there was no change then make the function bigger (it probably doesn't
make much difference exactly what it computes) and repeat.

So there is a clearly defined way to see performance variations caused
by even unused code. I've told you how to test it yourself if you don't
want to take my word for it. Then why are still complaining? I can't
tell exactly which changes will cause what performance variations on
your system, but I'd expect you to hit some before too long. Why can't
you just do that test instead of complaining that I gave no proof?