summaryrefslogtreecommitdiffstats
path: root/video/out/vo_lavc.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-06-12 17:48:27 +0200
committerwm4 <wm4@nowhere>2013-06-13 00:54:20 +0200
commit4a5d1f2d4494688703b2f4106b8c94c86eb1ea13 (patch)
tree7e7f81b589ffe83827a8a2cfa1e7c867b7db834d /video/out/vo_lavc.c
parent6c3a4ba9f91a4073154c037f716ef4f11f0671e6 (diff)
downloadmpv-4a5d1f2d4494688703b2f4106b8c94c86eb1ea13.tar.bz2
mpv-4a5d1f2d4494688703b2f4106b8c94c86eb1ea13.tar.xz
mplayer: try to handle PTS forward jumps
Raw MPEG streams can contain PTS discontinuities. While the playback core has obvious code for handling PTS going backward, PTS going forward was as far as I can see not handled. This can be an issue with DVD playback. This wasn't caught earlier, because DVD playback was just recently switched to demux_lavf, which implies -no-correct-pts mode. This mode doesn't use PTS in the same way as the normal playback mode, and as such was too primitive to be affected by this issue. Use the following heuristic to handle PTS forward jumps: if the PTS difference between two frames is higher than 10 seconds, consider it a reset. (Also, use MSGL_WARN for the PTS discontinuity warnings.) In this particular case, the MPEG stream was going from pts=304510857 to pts=8589959849 according to ffprobe (raw timestamps), which seems a bit strange. Note that this heuristic breaks if the source video has unusually high frame times. For example Rooster_Teeth_Podcast_191.m4a, an audio file with a slide show encoded as MJPEG video track.
Diffstat (limited to 'video/out/vo_lavc.c')
0 files changed, 0 insertions, 0 deletions