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

[Nick Kurshev]

Hello, Brian!

On Mon, 25 Feb 2002 12:30:59 -0500 you wrote:

[snip]
> 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
> 
Sell your audio card :)

> 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).
because nobody knows which speed of your media will be in the future.
These benchmark shows ideal case when file is located in memory
and you have no other processes except kernel + mplayer
> 
> 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.
> 
This question is already discussed in mplayer-dev-eng mlist.
> 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.
I'm trying to implement it localy for now :)
> 
> b.
> 
> -- 
> Brian J. Murrell
> 
> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users
> 


Best regards! Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20020225/dd6c8518/attachment.pgp>