[MPlayer-users] VDPAU performance with an Asus AT3N7A-I

[Reimar Döffinger]

On Tue, Dec 22, 2009 at 01:13:16PM +0100, Richard Hartmann wrote:
> On Tue, Dec 22, 2009 at 07:51, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On Mon, Dec 21, 2009 at 11:19:50PM +0100, Richard Hartmann wrote:
> >> On Mon, Dec 21, 2009 at 23:02, Reimar Döffinger
> >> <Reimar.Doeffinger at gmx.de> wrote:
> >>
> >> > With VDPAU -benchmark numbers are rather misleading.
> >> > Try normal playback and give these numbers from the status line:
> >>
> >> As in, without threading?
> >
> > No without -benchmark, was that so unclear that nobody understood it?
> 
> Apparently yes. But we are all synced, now :)

Just to make clear: the point of that is that the VO value seemed a bit
high to me, and I wondered if that is because your GPU is indeed at around
50% load _on average_ while playing the movie (in which case it could be
your card is just too slow during playback) or if that is just due to
it waiting for vsync.
So some "easy" debugging tips for this kind of issue
(I can't promise it will apply that way to the git version, and it
might not be 100% accurate):
The first % value is the CPU usage. If that ever becomes significant (more
than maybe 20%) there might be something wrong.
The second one is VO usage. If that is rather high it usually indicates that
your monitor refresh rate is too low for the content or the GPU is too slow.
The next one is CPU usage for audio processing. That should usually stay
around a few %, more for high-samplerate audio with many channels.
It can go very high in some cases if there is a large desync and MPlayer
"stumbles over itself".
Another interesting value is also A-V, that one indicates (or should indicate)
how much MPlayer thinks audio and video are apart.
Possible cases
1) A-V is 0, but there is desync. That means usually MPlayer messes up. It might
also be that there is a big latency in the audio output, or the file is broken or so.
Options to try: -correct-pts and -nocorrect-pts
2) A-V is > 0 and it is going further up. For some reason video is playing too slow
and MPlayer can't do anything against it. Usually because decoding is too slow,
in which case -framedrop and -hardframedrop or some other options can be used,
but the results will never be really good.
3) A-V is > 0 and slowly decreasing. Could be the same as 2) but you have reached
a part of the video that is easier to decode. Or there might have been an audio decode
error in which case -mc 100 should help fix things faster.
4) A-V is < 0. Usually means there is an audio issue (possible for the previous cases
as well) or a variable-frame-rate-video can sometimes cause it, too. If not, -mc 100
should help, as might -correct-pts or -nocorrect-pts.


> > And I'm not sure if it is wise to just believe what is said on IRC.
> 
> To play devil's advocate, is it wise to just believe what is said on the
> mailing list?

No, I'd rather have people think (or in that case try) by themselves (though
I think that in general mailing lists have a better chance of giving a balanced
view than IRC since it does not have to rely on luck that you picked a time
where the right people were online).
Not because I think it's particularly likely that SVN will be better but
because I'd think it would be simple to do and would exclude a whole
bit of possible issues.

> I know what you mean, but as a relative outsider, I have
> to give advance trust to _someone_.

In this specific case no, you can just find out by yourself...