[MPlayer-users] mplayer win32 issue

[Paul-Kenji Cahier]

Well
I agree it's working very well, but i'm very disappointed that it uses
so much cpu on a PIV 2.4Ghz. The strange part is that it works very
well on my PIII 750mghz, much better than other player.... so there is
really sthing strange. I dont think -benchmark numbers are wrong.

Oh and the vid looks perfectly smooth

-dr gives this a lot:
get_buffer() failed (stride changed).005  147/147   7%  1%  1.2% 0 0 0%
Error while decoding frame!
get_buffer() failed (stride changed).005  149/149   7%  1%  1.2% 0 0 0%
Error while decoding frame!
get_buffer() failed (stride changed).004  151/151   7%  1%  1.2% 0 0 0%
Error while decoding frame!
get_buffer() failed (stride changed).004  153/153   7%  1%  1.2% 0 0 0%
Error while decoding frame!
get_buffer() failed (stride changed).005  155/155   7%  1%  1.2% 0 0 0%
Error while decoding frame!
get_buffer() failed (stride changed).005  157/157   7%  1%  1.2% 0 0 0%



It's not a process priority since it's the only app running



> What is exact you problem?
> Normal playback takes 50% instead of 30%?
> Then be happy!
I am happy with it but it's a bit annoying to see mplayer use 3 times
more cpu than graphedit(which uses the fucking slow direct show
rendering of microsoft). Also if i use mplayer on my PIV linux box the
cpu usage is 5 times smaller than under win that's why i'm
wondering...



The  next results are about a vid with MP3 audio, SBC video(the prob
of over cpu usage is still there):
<14:05:58> DeathWolf at lafiel:~/mplayer Benchmarks/mplayer-mingw32-dev-CVS-031013$
           ./mplayer.exe -dr -quiet -benchmark
              ../\[dRips\]_Hajime_no_Ippo_Opening_SBC_Sample_MP3_1000_Frames.avi
BENCHMARKs: VC:   3.754s VO:   0.718s A:   0.383s Sys:  37.303s =   42.158s
BENCHMARK%: VC:  8.9046% VO:  1.7031% A:  0.9085% Sys: 88.4838% = 100.0000%

<14:19:47> DeathWolf at lafiel:~/mplayer Benchmarks/mplayer-mingw32-dev-CVS-031013$
           ./mplayer.exe -autosync 100 -dr -quiet -benchmark
              ../\[dRips\]_Hajime_no_Ippo_Opening_SBC_Sample_MP3_1000_Frames.avi
BENCHMARKs: VC:   3.849s VO:   0.199s A:   0.317s Sys:  37.116s =   41.481s
BENCHMARK%: VC:  9.2789% VO:  0.4797% A:  0.7642% Sys: 89.4771% = 100.0000%

<14:20:57> DeathWolf at lafiel:~/mplayer Benchmarks/mplayer-mingw32-dev-CVS-031013$
./mplayer.exe -quiet -benchmark ../\[dRips\]_Hajime_no_Ippo_Opening_SBC_Sample_MP3_1000_Frames.avi
BENCHMARKs: VC:   3.667s VO:   0.214s A:   0.377s Sys:  37.227s =   41.485s
BENCHMARK%: VC:  8.8393% VO:  0.5158% A:  0.9088% Sys: 89.7360% = 100.0000%

<14:36:08> DeathWolf at lafiel:~/mplayer Benchmarks/mplayer-mingw32-dev-CVS-031013$
           ./mplayer.exe -quiet -nosound -vo null -benchmark
              ../\[dRips\]_Hajime_no_Ippo_Opening_SBC_Sample_MP3_1000_Frames.avi
BENCHMARKs: VC:   3.114s VO:   0.000s A:   0.000s Sys:   0.137s =    3.251s
BENCHMARK%: VC: 95.7859% VO:  0.0000% A:  0.0000% Sys:  4.2141% = 100.0000%

<14:36:18> DeathWolf at lafiel:~/mplayer Benchmarks/mplayer-mingw32-dev-CVS-031013$
           ./mplayer.exe -quiet -ao null -vo null -benchmark
              ../\[dRips\]_Hajime_no_Ippo_Opening_SBC_Sample_MP3_1000_Frames.avi
BENCHMARKs: VC:   2.986s VO:   0.007s A:   0.031s Sys:  38.352s =   41.376s
BENCHMARK%: VC:  7.2167% VO:  0.0169% A:  0.0749% Sys: 92.6914% = 100.0000%


Either there is sthing really wrong in the sound handling part(not the
decoding or the output), or it's a timer prob, or i really dunno
Any way i could see if that is the prob?
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
>> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
>> okay
>> after even more tests i discovered this:
>>
>> when running -nosound -benchmark everything is running at full
>> speed(it renders the 40s clip in 10s)
>>
>> the problems happend as soon as i dont use these two options
>>
>>
>>
>> -nosound without -benchmark will eat up cpu,
>> and -benchmark combined to any other option(exept -nosound) will still
>> be as cpu consumming....

> -nosound will disable sound decoding/demuxing. This means there is no timing
> involved.
> The player will render as many frames as the cpu allows. With -ao null it
> will try to
> render only for example 25 frames per second to keep sync.

> What is exact you problem?
> Normal playback takes 50% instead of 30%?
> Then be happy!
> I know it is faster for me because the other players do a lot of
> framedroping where
> mplayer can play the video without problems. If you really want to see the
> power
> of mplayer get a low end system with about 300-500 or even 200 Mhz.
> Ok, it would be interesting to know where the problem is exactly or if there
> is a problem at all.
> I doubt it is a timer problem, the timer uses the same Sleep function as
> everything else on windows
> Maybe the numbers given by -benchmark are wrong, I don't know how they are
> calculated.
> Maybe windows gives us a bad process priority because we are a console app.
> What OS
> are you using?
> If the video does not look smooth try -autosync 100. It is also a good idea
> to use -dr for
> direct rendering. This will render b frames directly to video ram and may
> give at least some
> speedup. Also try to use other videos with different (audio) codec. I would
> be interested in
> benchmarks with those because I don't know what windows uses for decoding
> ac3 in your tests.

>  Sascha

> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users