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

Michael Niedermayer michaelni
Tue Dec 16 00:43:18 CET 2008

On Mon, Dec 15, 2008 at 04:52:34AM +0200, Uoti Urpala wrote:
> On Mon, 2008-12-15 at 01:33 +0100, Michael Niedermayer wrote:
> > One has to weigh the advantage against the disadvantage
> > 
> > here, advanatge, of the change is largely cosmetic
> > disadvantage is a 0.5% speed loss, after 10 such changes our decoder is 5%
> > slower.
> Real speed change yes, but 0.5% change in benchmark result tells you
> very little about whether speed changed or not ("real" speed could have
> become faster or slower).

Please see my mail i just posted for an actual test of what can reliably
be detected.

> > also ive developed and optimized other codecs like the mpeg4 variants based
> > on this concept and they are pretty much the fastest around. Had i applied
> > random changes that made the code by 0.5% slower they would not be as
> > fast.
> But benchmarking is not a reliable way to tell whether the h264 decoder
> really became 0.5% slower (at least you'd need a big collection of
> various possible "irrelevant" code changes and of compiler versions to
> benchmark against).

Please see my mail i just posted for an actual test of what can reliably
be detected.

> > doing optimzation well is not a matter of asking why its slower and then
> > ignoring it when its not obvious, its a matter of picking the faster.
> > Like in evolution, the question is not why some species is consistently
> > 0.5% less effective than another just that it is.
> Evolution relies on a large collection of individuals with varying
> traits. It wouldn't work if it abandoned a trait when one individual
> with it dies.

are we speaking about the same thing? it seems not

> > if one can find out why its 0.5% worse one may be able to find a solution
> > that makes the wanted change and avoids the speedloss, but if not the
> > change isnt ok.
> What about all the other changes you applied that made it 0.5% slower?

which change?

> Since the speed varies back and forth with most changes, about half of
> them (other than clearly beneficial optimizations) have made it slower,
> and a significant portion of those by 0.5% or more. Even changes in
> other decoders can affect h264 speed that much (probably some memory
> aliasing effect).

The speed very likely does vary yes, if its half faster half slower is
something you are guessing not knowing i suspect. Same for the relation
to 0.5%

> > and about other random changes making the code 0.5% faster, these are VERY
> > welcome, adding a noinline here, and inline there and such, really!
> > [of course only when the patch is clean and doesnt mix unrelated stuff]
> Such random changes have about 50% chance of being beneficial on any
> other combination of compiler, machine and exact FFmpeg source used. 

> The
> changes I tested probably wouldn't have the same effect in ffplay as in
> my test under MPlayer. 

> The results really are essentially "random".

So what? is it "probably" or "really are essentially"
Diego tested the change in ffmpeg and mplayer, the results where the same
you just said you didnt test except one case (mplayer). Now you extrapolate
from 1 case that it would be random. Are you studying cosmology by chance?

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081216/83e1393c/attachment.pgp>

More information about the ffmpeg-devel mailing list