From 0f3dedebb4c84deaa25abbd7dcfca3f3e10ea72c Mon Sep 17 00:00:00 2001 From: wm4 Date: Fri, 13 Nov 2015 22:53:38 +0100 Subject: player: stricter framedrop threshold 80ms allowable desync was a bit too much. It'd allow for a range of 160ms, which everyone can notice. It might also be a bother to apply compensation resampling speed for that long. --- player/video.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'player/video.c') diff --git a/player/video.c b/player/video.c index adc34f4f62..f6ab3d44c9 100644 --- a/player/video.c +++ b/player/video.c @@ -1011,10 +1011,9 @@ static void handle_display_sync_frame(struct MPContext *mpctx, // Intended number of additional display frames to drop (<0) or repeat (>0) int drop_repeat = 0; - // If we are too far ahead/behind, attempt to drop/repeat frames. In - // particular, don't attempt to change speed for them. + // If we are too far ahead/behind, attempt to drop/repeat frames. // Tolerate some desync to avoid frame dropping due to jitter. - if (drop && fabs(av_diff) >= 0.080 && fabs(av_diff) / vsync >= 2) + if (drop && fabs(av_diff) >= 0.020 && fabs(av_diff) / vsync >= 1) drop_repeat = -av_diff / vsync; // round towards 0 // We can only drop all frames at most. We can repeat much more frames, -- cgit v1.2.3