summaryrefslogtreecommitdiffstats
path: root/mencoder.c
diff options
context:
space:
mode:
authorUoti Urpala <uau@glyph.nonexistent.invalid>2009-11-15 04:39:22 +0200
committerUoti Urpala <uau@glyph.nonexistent.invalid>2009-11-15 12:45:58 +0200
commit201bef7ee150f9d852996b379c926ba0c47320d5 (patch)
treeb0e4e14a73b1d868b1f1a81c8ebdbaa3f0c8f8c9 /mencoder.c
parentb87ce8bc96657c0b2d9b7fc51ed4bc1661d53270 (diff)
downloadmpv-201bef7ee150f9d852996b379c926ba0c47320d5.tar.bz2
mpv-201bef7ee150f9d852996b379c926ba0c47320d5.tar.xz
Implement vsync-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 vsyncs, 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 vsync. 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 vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. 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 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. 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.
Diffstat (limited to 'mencoder.c')
-rw-r--r--mencoder.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/mencoder.c b/mencoder.c
index 7f4094f663..78c8494966 100644
--- a/mencoder.c
+++ b/mencoder.c
@@ -208,7 +208,7 @@ int vo_draw_image(struct vo *vo, struct mp_image *mpi, double pts) { abort(); }
int vo_draw_frame(struct vo *vo, uint8_t *src[]) { abort(); }
int vo_draw_slice(struct vo *vo, uint8_t *src[], int stride[], int w, int h, int x, int y) { abort(); }
void vo_draw_osd(struct vo *vo, struct osd_state *osd) { abort(); }
-void vo_flip_page(struct vo *vo) { abort(); }
+void vo_flip_page(struct vo *vo, uint32_t pts_us, int duration) { abort(); }
void vo_check_events(struct vo *vo) { abort(); }
// Needed by getch2