It appears VdpPresentationQueueGetTime does not always return a monotonic, steady (i.e. no jumps) time. This can be a bit of a problem since the API basically assumes a reliable timer. The unreliable timer causes two basic problems: 1. VdpPresentationQueueDisplay is unreliable. Since between retrieving the current vdpau time, calculating the presentation time, and calling VdpPresentationQueueDisplay the timer could jump, the function becomes essentially useless, unless you pass 0 to it. 2. The presentation time returned by VdpPresentationQueueQuerySurfaceStatus is useless. Since the timer could jump at any time, the application can't really use the first_presentation_time value for anything. At least the video players mplayer2 and mpv have trouble with this. They try to queue frames at vsync intervals, and the framedropping code is involved with it too. Jumps have been reported in the following situations: 1. Moving the window with the vdpau context to another display 2. Pausing/unpausing mpv. I'm unsure why this would happen, since pausing/unpausing is obviously not part of the vdpau API - but I don't know what triggers it. Maybe it happens when the presentation queue becomes empty? For what it's worth, I can't personally test with vdpau/Mesa. Unless there's some kind of software emulation of vdpau?
Oh, it seems the pausing issue could be caused by interaction with power management. This is what a user posted: >When polling '/sys/kernel/debug/dri/0/radeon_pm_info' you can see that this only happens when the power level switches from an UVD power level to a non-UVD power level. Pause -> 1-2 seconds -> non-UVD power level -> Play -> Stutter
That's a known issue, it's a design problem of DRI2. Essentially there is no global time you could return from VdpPresentationQueueGetTime. Instead what you return is always the an estimation based on the vsync counter and that's unfortunately per output instead of global. Additional to that I never bothered adding the difference between the last flip and the current time to the result of VdpPresentationQueueGetTime. So when you don't have a page flip the result of VdpPresentationQueueGetTime will probably stand still. *** This bug has been marked as a duplicate of bug 66384 ***
(In reply to comment #1) > Oh, it seems the pausing issue could be caused by interaction with power > management. This is what a user posted: > > >When polling '/sys/kernel/debug/dri/0/radeon_pm_info' you can see that this only happens when the power level switches from an UVD power level to a non-UVD power level. Pause -> 1-2 seconds -> non-UVD power level -> Play -> Stutter Not for me though, my HD4890 doesn't have uvd, and I just tried forcing dpm to low and high rather than auto and the pausing issue is still there with both.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.