summaryrefslogtreecommitdiffstats
path: root/sub/sd_lavc.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-12-03 21:43:32 +0100
committerwm4 <wm4@nowhere>2019-12-03 21:43:32 +0100
commite5b016b7bf75dd99545dc231f9c4d38047827c79 (patch)
tree8a0dadd9dccebbee150b9878c5b7f5c7b5365c26 /sub/sd_lavc.c
parentd60bbd86e35f3368fcda861099fa8e63b5bb7a7a (diff)
downloadmpv-e5b016b7bf75dd99545dc231f9c4d38047827c79.tar.bz2
mpv-e5b016b7bf75dd99545dc231f9c4d38047827c79.tar.xz
player: don't apply weird timestamp tolerance on backstep
Hr-seek has some sort of tolerance against timestamps, where it allows for up to 5ms deviation. This means it can work only for videos with up to 200 FPS framerate. There were complains about how it doesn't work with videos beyond some high fps. (1000 was mentioned, although that sounds more like it's about the limit that .mkv has.) I suspect this is because otherwise, it might be hard to hit a timestamp with --start, which specifies timestamps as integer, and thus will most likely never represent a timestamp exactly. Another part of the problem is that mpv uses 64 bit floats for timestamps, so fractional parts are never represented exactly. (Both the "tolerance" and using floats for timestamps were things introduced before my time.) Anyway, in the backstep case, we can be relatively sure that the timestamp will be exact (as in, the same unmodified value that was returned by the filter chain), so we can make an exception for that, in order to fix backstep. Untested. (For that you have users.) May help with #7208.
Diffstat (limited to 'sub/sd_lavc.c')
0 files changed, 0 insertions, 0 deletions