[FFmpeg-devel] [RFC] move wmv2.c to its own file

[Diego Biurrun]

On Sun, Nov 04, 2007 at 02:57:18AM +0100, Michael Niedermayer wrote:
> 
> On Sun, Nov 04, 2007 at 01:55:50AM +0100, Diego Biurrun wrote:
> > On Sat, Nov 03, 2007 at 05:10:32PM +0100, Michael Niedermayer wrote:
> > > 
> > > On Sat, Nov 03, 2007 at 04:50:53PM +0100, Aurelien Jacobs wrote:
> > > > 
> > > > OK. Here is a split version of the patch.
> > > > First patch only does some renaming (adding proper prefix).
> > > > Second patch is now very simple and does the actual move of
> > > > wmv2.c in its own file.
> > > > If I get no comments about these patches I will probably apply
> > > > as is.

I don't think as-is would be such a good idea ;)

msmpeg4.c:985: error: static declaration of 'ff_mb_non_intra_vlc' follows non-static declaration
msmpeg4.h:38: error: previous declaration of 'ff_mb_non_intra_vlc' was here
msmpeg4.c:994: error: static declaration of 'ff_inter_intra_vlc' follows non-static declaration
msmpeg4.h:39: error: previous declaration of 'ff_inter_intra_vlc' was here

After removing static from the two declarations in msmpeg4.c it compiles
and seems to work.

> > > needs benchmark and is rejected if its meassureably slower
> > 
> > What needs to be benchmarked exactly?  I'll try to help.
> 
> wmv2 decoding
> 
> time mplayer -benchmark
> should do, time too as i dont trust -benchmark :)
> if these dont show a difference then the difference is too small to matter
> IMHO

The patched version appears to be faster on the machine I tested on,
K6-III 500, Debian stable, gcc 4.1.2:

unpatched:

BENCHMARKs: VC:  27.265s VO:   0.039s A:   0.000s Sys:   1.003s =   28.307s
BENCHMARK%: VC: 96.3180% VO:  0.1370% A:  0.0000% Sys:  3.5450% = 100.0000%
real    0m28.577s
user    0m27.942s
sys     0m0.500s

BENCHMARKs: VC:  27.479s VO:   0.038s A:   0.000s Sys:   0.965s =   28.482s
BENCHMARK%: VC: 96.4764% VO:  0.1347% A:  0.0000% Sys:  3.3889% = 100.0000%
real    0m28.752s
user    0m28.138s
sys     0m0.472s

BENCHMARKs: VC:  27.502s VO:   0.039s A:   0.000s Sys:   0.967s =   28.507s
BENCHMARK%: VC: 96.4736% VO:  0.1354% A:  0.0000% Sys:  3.3911% = 100.0000%
real    0m28.777s
user    0m28.114s
sys     0m0.544s


patched:

BENCHMARKs: VC:  27.314s VO:   0.037s A:   0.000s Sys:   0.944s =   28.295s
BENCHMARK%: VC: 96.5336% VO:  0.1307% A:  0.0000% Sys:  3.3357% = 100.0000%
real    0m28.565s
user    0m27.826s
sys     0m0.608s

BENCHMARKs: VC:  27.390s VO:   0.036s A:   0.000s Sys:   0.959s =   28.386s
BENCHMARK%: VC: 96.4919% VO:  0.1281% A:  0.0000% Sys:  3.3801% = 100.0000%
real    0m28.655s
user    0m27.974s
sys     0m0.540s

BENCHMARKs: VC:  27.410s VO:   0.036s A:   0.000s Sys:   0.960s =   28.406s
BENCHMARK%: VC: 96.4927% VO:  0.1280% A:  0.0000% Sys:  3.3792% = 100.0000%
real    0m28.675s
user    0m28.066s
sys     0m0.492s


There appears to be a slight speedup, at least no slowdown, so it should
be good to commit.  I ran

time mplayer -benchmark -vfm ffmpeg -nosound -vo null -quiet vandread_ep13_op_wm8_ver.wmv

four times each, discarded the first result, the other three are
above.  I stopped all daemons and other processes.  The sample I used was

http://samples.mplayerhq.hu/V-codecs/WMV8/vandread_ep13_op_wm8_ver.wmv

Is this sufficient?

Diego