[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h
Mon Dec 1 11:25:59 CET 2008
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
I redid the benchmarks with the ugly but complete split I have in my
The numbers are attached. It still appears to be slower, but not that
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?
More information about the ffmpeg-devel