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

[Brian J. Murrell]

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

Hi Nick,

> 
> 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 :)

I see that in "MAX BENCHMARK%" Audio is accounted for 1034.5506% of
the CPU, but that does not compute with me.  "AVE BENCHMARK" only
shows Audio at 2.1352%.  What can explain this huge difference?

I guess what it looks like to me is that "MAX BENCHMARK" is not really
that useful.  It is extrapolating the most difficult to decompress
frame(s) across every frame of the video and figuring out how much CPU
would be needed for that stream.

But that is not real life.  The whole point of multimedia
(de-)compression is the gamble on there being "easy" parts and
"difficult" parts, but on average, the whole stream is more easy parts
than difficult.  If every single frame were difficult to decompress,
then there is no point in compressing it.

It's neat to look at 1085% and understand that (loosely speaking)
averaged over the whole steam, with a good algorithm, my processor is
producing the work of 10 processors of it's size without the algorithm
but beyond that "wow" factor, the number is useless.

Again, unless I am mis-interpreting the results.

> because nobody knows which speed of your media will be in the future.

But that doesn't matter.  Of course everybody understands that with a
change in media, so will there be a change in processing requirements.
But the point is what is the MAX BENCHMARK telling me right now about
the video I am playing now?  I can't glean anything useful out of it.

> These benchmark shows ideal case when file is located in memory
> and you have no other processes except kernel + mplayer

Ideal is that I need about 10x the cpu I have to play my video?  The
visual results do not seem to reflect that.  As much as I complain
about judder, I would not expect to have to increase my processor to
8000Mhz to fix that.

> This question is already discussed in mplayer-dev-eng mlist.

I read it.  If the variance of CPU needed is great between different
types of frames, I will vote on the side of buffering ahead.
Averaging a contrained resource across a greatly varying load usually
results in an impressive result.

> I'm trying to implement it localy for now :)

Please keep me informed.  I think this idea has lots of merit.

I was dismayed by your comment:

1. As I already said - ATI's card don't have vertical synchroniszation async event
(as matrox) finely - I don't have doumentation for that.
2. So wait_vsync causes unnecessary delays, but buffer switching
without them causes juderring.

So the a/v sync on the Radeon card is still not as good as the G400?
Is the difference having to sit and wait until a v/sync signal comes
from the Radeon and then mplayer doing buffer switch vs. giving
buffers to g400 and instructing it to switch on v/sync so that it
happens asynchronously to mplayer?

I am about to put my g400 back into my pvr.  :-)  I just wish I could
get a decent set of fb.modes for 59.94Hz refresh on it.

b.

-- 
Brian J. Murrell