From fad254562b09dcff4d6c95aff5982a6252b09ebb Mon Sep 17 00:00:00 2001 From: wm4 Date: Fri, 13 Nov 2015 22:46:55 +0100 Subject: player: smooth out frame durations by averaging them Helps somewhat with muxer-rounded timestamps. There is some danger that this introduces a timestamp drift. But since they are averaged values (unlike as when using an incorrect container framerate hint), any potential drift shouldn't be too brutal, or compensate itself soon. So I won't bother yet with comparing the results with the real timestamp, unless we run into actual problems. Of course we still prefer potentially real timestamps over the approximated ones. But unless the timestamps match the container FPS, we can't know whether they are (no, checking whether the they have microsecond components would be cheating). Perhaps in future, we could let the demuxer export the timebase - if the timebase is not 1000 (or divisible by it), we know that millisecond-rounded timestamps won't happen. --- player/video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'player/video.c') diff --git a/player/video.c b/player/video.c index 398d74a643..d6140773eb 100644 --- a/player/video.c +++ b/player/video.c @@ -1058,9 +1058,9 @@ static void calculate_frame_duration(struct MPContext *mpctx) total += dur; num_dur += 1; } + double approx_duration = num_dur > 0 ? total / num_dur : duration; // Try if the demuxer frame rate fits - if so, just take it. - double approx_duration = duration; if (demux_duration > 0) { // Note that even if each timestamp is within rounding tolerance, it // could literally not add up (e.g. if demuxer FPS is rounded itself). -- cgit v1.2.3