diff options
author | wm4 <wm4@nowhere> | 2019-12-03 21:43:32 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-12-03 21:43:32 +0100 |
commit | e5b016b7bf75dd99545dc231f9c4d38047827c79 (patch) | |
tree | 8a0dadd9dccebbee150b9878c5b7f5c7b5365c26 /sub | |
parent | d60bbd86e35f3368fcda861099fa8e63b5bb7a7a (diff) | |
download | mpv-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')
0 files changed, 0 insertions, 0 deletions