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

[Michael Niedermayer]

Hi

On Wed, Nov 07, 2007 at 12:56:35PM +0100, Diego Biurrun wrote:
> 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?

yes

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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/20071107/84061ca7/attachment.pgp>