Thread: mplayer vdpau
View Single Post
Old 09-28-09, 06:07 PM   #1201
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: mplayer vdpau

Quote:
Originally Posted by uau View Post
This is the basic problem. What's the rationale for this design?
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.

Quote:
Originally Posted by uau View Post
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.
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.

Quote:
Originally Posted by uau View Post
Why would you ever need to explicitly repeat frames?
You don't. Frames that are displayed remain displayed until replaced.

Quote:
Originally Posted by uau View Post
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.
Even without extra information, the presentation queue should never be "some multiple of 1/24 seconds late", when used correctly. N frames should be queued into the presentation queue at all times. In order to achieve that, when the very first frame is queued, its presentation time should be set to some time in the future, to allow the buffer to build up (decoding takes a non-zero amount of time). The exact time in the future must be chosen carefully, and matched to when audio is first sent to the sound card, so that the first audio and video align (or are offset by the amount the timestamps in the content are set apart).

Quote:
Originally Posted by uau View Post
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.
That would be good news.

Quote:
Originally Posted by uau View Post
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.
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.

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. Also note that NVIDIA's VDPAU implementation does not survive mode-switches anyway.
Stephen Warren is offline   Reply With Quote