Thread: mplayer vdpau
View Single Post
Old 11-09-09, 11:34 PM   #1212
Registered User
Join Date: Sep 2009
Posts: 45
Default Re: mplayer vdpau

I implemented smart frame dropping/timing functionality for MPlayer's VDPAU driver to work around the frame rate limitation and avoid jitter due to unstable timing. The code is currently in a temporary branch but can be tested as follows:

First do 'git clone git://' and build as normal (following the README). Then to switch to the new timing code go to the 'mplayer' subdirectory and run 'git checkout origin/tmp_vdpau' and run make again (you can run it in the subdirectory if you did a top-level compile before; running it at the top level again works too, just recompiles more things than needed).

I'll change the build repo to use this code by default after some more testing and other changes.

Below is the log message of the main commit with more detail:

Implement vblank-aware frame timing for VDPAU

Main things added are custom frame dropping for VDPAU to work around
the display FPS limit, frame timing adjustment to avoid jitter when
video frame times keep falling near vblanks, and use of VDPAU's timing
feature to keep one future frame queued in advance.

NVIDIA's VDPAU implementation refuses to change the displayed frame
more than once per vblank. This set a limit on how much video could be
sped up, and caused problems for nearly all videos on low-FPS video
projectors (playing 24 FPS video on a 24 FPS projector would not work
reliably as MPlayer may need to slightly speed up the video for AV
sync). This commit adds a framedrop mechanism that drops some frames
so that no more than one is sent for display per vblank. The code
tries to select the dropped frames smartly, selecting the best one to
show for each vblank. Because of the timing features needed the drop
functionality currently does not work if the correct-pts option is

The code also adjusts frame timing slightly to avoid jitter. If you
for example play 24 FPS video content on a 72 FPS display then
normally a frame would be shown for 3 vblanks, but if the frame times
happen to fall near vblanks and change between just before and just
after then there could be frames alternating between 2 and 4
vblanks. The code changes frame timing by up to one quarter vblank
interval to avoid this.

The above functionality depends on having reliable vblank timing
information available. This is not directly provided by the VDPAU API,
but can be deduced from the frameflip timing information provided by
VDPAU. The code calculating this is somewhat tricky but should work
quite robustly as long as the per-frame timing information is precise.
It works without needing any separate measurement phase and can handle
changes in display FPS in the middle of playback.

After the changes in this commit MPlayer now always tries to keep one
frame queued for future display using VDPAU's internal timing
mechanism (however no more than 50 ms to the future). This should make
video playback somewhat more robust against timing inaccuracies caused
by system load.
uau is offline   Reply With Quote