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