summaryrefslogtreecommitdiffstats
path: root/player/video.c
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 /player/video.c
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.
Diffstat (limited to 'player/video.c')
-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).