Thread: mplayer vdpau
View Single Post
Old 09-28-09, 05:51 PM   #1200
Registered User
Join Date: Sep 2009
Posts: 45
Default Re: mplayer vdpau

Originally Posted by Stephen Warren View Post
MPlayer (and unfortunately all apps so far I believe) isn't using the VDPAU presentation queue as designed. It's intended to work like this:
I'm aware that the intended use is somewhat different; however as far as I can tell queuing frames ahead the way VDPAU designers expected it to be used would not help much with this problem.
(although VDPAU will always display each frame for at least one VSYNC by design; apps that don't want a frame to be displayed should not send it into the presentation queue)
This is the basic problem. What's the rationale for this design? Is there a hardware limitation requiring it? I can't see how this would be desirable as the default behavior if you have a choice. For the application to make the dropping decisions needed because of VSYNC rate requires it to know about VSYNC timing, information which is not readily available and would not be needed otherwise.
c) Player should look at the "first_presentation_time" result from either VdpPresentationQueueBlockUntilSurfaceIdle or VdpPresentationQueueQuerySurfaceStatus to measure any desync, and skip/repeat frames based on that.
Why would you ever need to explicitly repeat frames? Anyway skipping is the main issue here, and detecting afterwards that frames already were late and then dropping some (without explicit awareness of VSYNC rate) is not a good solution at least if the display device is low FPS. You don't want to constantly have the video some multiple of 1/24 second late.

In fact, MPlayer (and likewise all apps) is simply queueing a single frame into the presentation queue, with no timestamp (i.e. display "now"), and not using the "first_presentation_time" data at all. It's no surprise that this isn't entirely optimal.
I don't see how timestamps alone would help with the issues in this thread. You could measure the delay in flipping regardless of whether the frames were queued with a timestamp or not (just use the VDPAU time at the moment of queuing as the time to compare against); but noticing that they were delayed is not enough alone to implement a good _solution_ to the problem.

NVIDIA takes at least some of the blame for this; our MPlayer patches never implemented the correct way to use the presentation queue. However, it's equally true that it appears very difficult to get ffmpeg to work in the model VDPAU wants; I don't think the surface ownership tracking is there to support this amongst other things. I suppose this isn't much of a surprise, since VDPAU's presentation queue is a somewhat ground-breaking new concept.

Comments on the ffmpeg mailing list indicate that even if we had modified ffmpeg to support this (the changes may have been significant), the patches still would not have been accepted, since some ffmpeg maintainers don't see the presentation queue concepts as being necessary.
I think it would be possible to implement queuing frames ahead, and no FFmpeg changes would be needed. Video surfaces are allocated through the get_buffer() function in MPlayer's vd_ffmpeg.c, and MPlayer can control their reuse through that. I may implement that later. But, again, I think the queuing has little to do with the framerate problem here.

If NVIDIA is unable or unwilling to change the queue behavior to automatically drop frames which should be dropped because of timing then I hope at least a way to directly get the current VSYNC rate of the synced-to device is added to the VDPAU API. That would allow properly calculating on the application side which frames should be dropped. The application can already try getting that value through other APIs or measure it from the reported display times, but that is somewhat tedious especially when the value can plausibly change (if the user starts watching videos then that's a time when he's particularly likely to switch display modes).
uau is offline   Reply With Quote