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

[Michael Niedermayer]

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:
> > > Next up on the list is moving the tables in h264data.h to a .c file that
> > > can be compiled and shared by the H.264 and SVQ3 decoder.  This requires
> > > adding an ff_ prefix to the names of the tables, removing the static
> > > keyword and then moving h264data.h to h264data.c while replacing the
> > > contents of h264data.h with appropriate extern declarations.
> > > 
> > > I have done this in my local tree, but the patch is 174kB big (and
> > > terribly boring), so I'm not sending it here.  OK to proceed (in
> > > several steps)?  
> > 
> > yes
> > 
> > > 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


> 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.

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20081129/eeed3bec/attachment.pgp>