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

Originally Posted by Stephen Warren View Post
If an application doesn't want a frame displayed, it should not be placed into the presentation queue. The presentation queue's job is to display what the application tells it to, not to perform frame-rate conversion.
So you basically mean it would be harder to implement? ("Not its job" shouldn't otherwise prevent having more useful functionality.)
That isn't true. The frame timing information MUST be used in *all* cases to ensure correct A/V sync. In a PC environment, the video scanout clock and audio clock are not necessarily locked to each-other in any way at all. As such, correct A/V sync can only be achieved by correlating audio clock (or delay) vs. video presentation timestamps and perhaps vs. PC system time. If that is correctly implemented, VSYNC timing should mostly just work. In cases of low scanout rate, I admit a better experience might require using other information.
I think you misinterpreted what I meant by "VSYNC timing"; basically I meant display frame rate information here. You seem to be talking about syncing with VDPAU time. Yes that would be required if you use the queuing-ahead functionality; but frame rate information is needed to make good frame frame dropping decisions (arguably even more if you have a queue, as queuing multiple frames ahead could make the timing fall behind even more before you see any feedback) and would not be necessarily required otherwise.
Even without extra information, the presentation queue should never be "some multiple of 1/24 seconds late", when used correctly.
It would be. Consider what would happen if you queue say 8 frames of 50 FPS content, and the display happens to be a 24 FPS video projector.
I don't think VDPAU needs to expose this information; unless I'm wrong, detailed mode timing information is already available via other X APIs, which MPlayer already uses.
Would this still work if for example VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE was set?
Arguments re: the frame rate changing apply equally to querying the frame rate through VDPAU or any other mechanism; even if VDPAU was extended with an API to query frame rate, VDPAU would not sent an event/callback/... to the application if the frame rate changed.
You could at least query it again occasionally or when frames are falling behind.
Also note that NVIDIA's VDPAU implementation does not survive mode-switches anyway.
So that means that timing maximum-speed frame updates at startup of preemption recovery should give reliable values. Still somewhat tedious to do though, and I doubt you want to guarantee that for future implementations (I mean you probably don't want to make it a requirement on every server-side implementation of the VDPAU API that every mode change will _have_ to trigger a preemption even if it could otherwise be avoided).
uau is offline   Reply With Quote