mirror of https://github.com/mpv-player/mpv
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.
This commit is contained in:
parent
d60bbd86e3
commit
e5b016b7bf
|
@ -457,6 +457,7 @@ static int video_output_image(struct MPContext *mpctx)
|
|||
struct vo_chain *vo_c = mpctx->vo_chain;
|
||||
bool hrseek = false;
|
||||
double hrseek_pts = mpctx->hrseek_pts;
|
||||
double tolerance = mpctx->hrseek_backstep ? 0 : .005;
|
||||
if (mpctx->video_status == STATUS_SYNCING) {
|
||||
hrseek = mpctx->hrseek_active;
|
||||
// playback_pts is normally only set when audio and video have started
|
||||
|
@ -505,7 +506,7 @@ static int video_output_image(struct MPContext *mpctx)
|
|||
mp_pin_out_unread(vo_c->filter->f->pins[1], frame);
|
||||
img = NULL;
|
||||
r = VD_EOF;
|
||||
} else if (hrseek && (img->pts < hrseek_pts - .005 ||
|
||||
} else if (hrseek && (img->pts < hrseek_pts - tolerance ||
|
||||
mpctx->hrseek_lastframe))
|
||||
{
|
||||
/* just skip - but save in case it was the last frame */
|
||||
|
|
Loading…
Reference in New Issue