summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2015-11-13 22:46:55 +0100
committerwm4 <wm4@nowhere>2015-11-13 22:46:55 +0100
commitfad254562b09dcff4d6c95aff5982a6252b09ebb (patch)
tree4162a62b14d8b54e6bd882cc4873f8cd9c7d9fc4
parentd32c4c75ef1cf4d69474a0a0e8f8127e77910099 (diff)
downloadmpv-fad254562b09dcff4d6c95aff5982a6252b09ebb.tar.bz2
mpv-fad254562b09dcff4d6c95aff5982a6252b09ebb.tar.xz
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.
-rw-r--r--player/video.c2
1 files changed, 1 insertions, 1 deletions
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).