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

[Uoti Urpala]

On Tue, 2009-12-22 at 17:23 +0100, Reimar Döffinger wrote:
> 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.

When using hardware decoding the distinction between VC and VO values is
not really meaningful. And as explained before the status line values
would not really give any better information.

Given the other hardware decoding results I've seen about 50% load when
decoding 24 FPS 1080p h264 seems quite plausible (the variations in
hardware decoding performance between NVIDIA cards don't seem to be all
that big; filtering performance varies a lot more depending on the
general graphics performance of the card). I'd expect a performance
problem that causes very noticeable jitter to be visible in the A-V
value on the status line.

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

I think most of these can already be ruled out in this particular case.


> 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.

When using hardware decoding it's normal that most of the time used can
be reported in the VO section. And it can be reasonably high (over 50%
at least) without necessarily indicating any problem that would affect
playback.

> 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".

I'd expect any of these problems to have a visible effect on the A-V
value though, and he already said it stays stably at +-0.001.

> Another interesting value is also A-V, that one indicates (or should indicate)
> how much MPlayer thinks audio and video are apart.
> Possible cases

As he already said it's about 0 most of this isn't relevant in the
particular case here. Comments below are about general troubleshooting
using the value (and largely meant for people troubleshooting timing
issues in general rather than strictly as a reply):



> 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

When reporting any problems it's worth making a distinction between the
value staying at almost exactly 0, or staying small but jittering (by
something more than about 0.010).

The most common case where -nocorrect-pts used to help (changing overall
desync to just inaccurate timing) was when playing some (not all) mpeg
container videos that used interlaced h264 with PAFF and using -demuxer
lavf. The problem should already be fixed in git however. I'm not aware
of any remaining common cases where -nocorrect-pts would help (though
there could be some). Generally it's unlikely that either switch would
fix a major desync if A-V already stays around 0. Fixing smaller jitter
is more plausible.

If there is a clearly noticeable desync but A-V stays around 0 then most
likely the file is broken or it's an MPlayer bug. An audio output
problem is possible, but I think much rarer (though given the migration
between different audio systems it's possible this will change).

> 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.

Decoding being too slow is the most usual case; in this case checking
whether the percentages on the status line add up to more than 100% can
offer more evidence (if it occurs in a particular part of the video then
doing a seek there to reset the percentages and ignore previous values
from elsewhere can be useful).

The above-mentioned PAFF timing problem can also cause this even if
decoding speed is sufficient. In git things should work if you use
-demuxer lavf for such mpeg files (the problem can still occur if you
use the internal mpeg demuxer). If you're using svn then this will
likely result in lots of "pts value < previous" messages instead if it's
a timing problem rather than a decoding speed problem.

Video FPS being higher than display refresh rate with a VO that can't
swap frames faster than once per refresh is another possibility. If
you're playing video on something like a 24 FPS video projector then
this is a likely candidate. Also happens when changing playback speed to
fast forward videos (though if you make it fast enough then you'll
probably hit decoding speed limits too). AFAIK this affects -vo gl with
default options on all gl implementations (you can use the
':swapinterval=0' suboption to -vo gl to remove this limit and see if it
fixes the desync, but this also completely disables vsync and causes
tearing so it's not very desirable as a general solution). -vo xv may or
may not be affected (on my current NVIDIA card it is affected, but the
symptoms are somewhat different because frames end up being queued in
the X server instead of MPlayer waiting for each frame individually as
with gl). -vo vdpau is affected in svn MPlayer but in git there is
special frame sync/drop code which should avoid the problem. -vo x11 is
most likely not affected, so you can perhaps use it to test if xv is the
only other candidate on your system, but it's not recommended for normal
use because it has several other problems.

> 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.

Either of these can also be caused by a demuxing issue that makes audio
and video start from different places. If the desync occurs after
starting the video or seeking and then gradually decreases then this is
most likely the case. The behavior of MPlayer could be improved in this
area (it's something I intend to do together with an implementation of
frame-accurate seeks and backwards framestep, as those will require
special audio sync code anyway).