Re: mplayer vdpau
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:
a) Player decodes N frames ahead of time, so that some number of frames can be queued in the presentation queue at all times. In other words, adequate buffering is required at all stages.
b) Player should provide a timestamp associated with each frame, indicating when to display it. This is what allows players to control which VSYNC each frame is displayed at, the duration frames are displayed, etc. (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)
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.
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.
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.