[MPlayer-users] Jerky/Juddery/interruptible output - COMMON ANSWER

Brian J. Murrell 724bf032f41d3c458706e618512b286a at interlinx.bc.ca
Mon Feb 25 18:48:01 CET 2002


On Mon, Feb 25, 2002 at 01:59:09PM +0300, Nick Kurshev wrote:
> Hello, Brian!

Hi Nick,

> Why do you use -vo x11 instead of xvidix?

Because on the box I had done the cvs update I have a Matrox Millenium
II and an ATI Rage II (mach64).  I tried the mach64 vidix driver but
it segfaulted.  Perhaps because my mach64 has only 4MB of ram.

> If you want slowdown execution you also may disable L1+L2 cache :)

:-)

But here is results from a PIII-600Mhz with Radeon using "-vo
vesa:vidix -benchmark -frames 5000":

vo_vesa: Using VESA mode (10) = 194 [320x240 at 0]
vo_vesa: Using DGA (physical resources: D0000000h, 02000000h)
vo_vesa: Using VIDIX
AO: [alsa5] 32000Hz Stereo Signed 16-bit (Little-Endian)
alsa-init: requested format: 32000 Hz, 2 channels, Signed 16-bit (Little-Endian)
alsa-init: 1 soundcard found, using: YMFPCI
AUDIO: 32000 Hz/2 channels/128000 bps/131072 bytes buffer/Signed 16-bit Little Endian
Start playing...
A: 153.4 V: 154.1 A-V: -0.720 ct: -0.125  4617/4617  23%  0%  2.1% 13 0 0%
AVE BENCHMARKs: VC:  36.611s VO:   0.010s A:   3.274s Sys: 113.457s = 153.353s
AVE BENCHMARK%: VC: 23.8737% VO:  0.0067% A:  2.1352% Sys: 73.9844% = 100.0000%

MAX BENCHMARKs: VC:  77.763s VO:   0.101s A:1586.511s
MAX BENCHMARK%: VC: 50.7086% VO:  0.0660% A:1034.5506% = 1085.3253%
TOTAL BENCHMARK: from 4603 frames should be dropped: 2 at least

So again, it's saying I need 109x the processor capability that I
have.  But it also says that it would drop (only) 2 frames (at least).

I understand the previous comment about buffering more than 2 frames
however.  If there are frames that are more costly than 100% processor
(of real-time) but more that are not, the more frames that can be
buffered the more chances you have to amortize the cost of the one
expensive frame over the other cheaper (in terms of CPU) frames.

But if the video cards only have 2 frames of buffer, I guess there is
not much that can be done about that.  Unless of course, perhaps
mplayer could internally build a fifo of frames that can be pushed
onto the framebuffer's memory as it displays frames and makes the
memory available.

b.

-- 
Brian J. Murrell




More information about the MPlayer-users mailing list