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

[Diego Biurrun]

On Sat, Nov 29, 2008 at 05:28:27PM +0100, Michael Niedermayer wrote:
> On Fri, Nov 28, 2008 at 09:46:19PM +0100, Diego Biurrun wrote:
> > On Fri, Nov 28, 2008 at 07:14:57PM +0100, Michael Niedermayer wrote:
> > > On Fri, Nov 28, 2008 at 05:48:50PM +0100, Diego Biurrun wrote:
> > > > Will this need to be benchmarked at some point?
> > > 
> > > id say it cant hurt to benchmark it before commit
> > 
> > Hmmmmm
> > 
> > I ran the following benchmarks on my K6-III with two different samples:
> > 
> > http://samples.mplayerhq.hu/V-codecs/h264/cathedral-beta2-400extra-crop-avc.mp4
> > http://samples.mplayerhq.hu/V-codecs/h264/Aladin.mpg
> > 
> > I used the following MPlayer command lines to benchmark:
> > 
> > mplayer -quiet -frames 1000 -benchmark -nosound -vo xmga
> > mplayer -quiet -frames 1000 -benchmark -nosound -vo null
> > 
> > I made five runs for each sample and vo and threw away the best and
> > worst times.  The results are attached.
> > 
> > Unfortunately there seems to be a slight slowdown with the cathedral
> > sample, with Aladin it's a bit inconclusive.
> > 
> > Now I don't know how to continue from here.  Were my benchmarking
> > procedures sensible?  (BTW, is there a good way to benchmark with ffmpeg
> > directly?)  
> 
> time ffmpeg ... >&/dev/null

Sure, but what options would I use?

> > Are these intermediate results worth anything at all or
> > should the benchmarks be done once the split is complete to be
> > significant?
> > 
> > I remember that WMV2 decoding times improved after the split from
> > msmpeg4.  Please point me in the right direction.
> 
> iam not sure, one thing that may or may not help is figuring out which
> table it is that causes the slowdown. I dont really belive it is
> a specific table, rather gcc doing something randomly silly.

I ran the test on my K6-III with gcc 4.1, but I could reproduce similar
numbers on my G4 with gcc 4.3.  So all in all this might actually be for
real.

I redid the benchmarks with the ugly but complete split I have in my
local tree:

http://www1.mplayerhq.hu/~diego/split.diff

The numbers are attached.  It still appears to be slower, but not that
much.

Since intermediate numbers do not appear to paint too accurate a picture
my suggestion is to go ahead with the split and start comparing when it
is finished.  Michael?

Diego