Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Seek position flickers between keyframes when dragging OSC on short videos #4183
mpv version and platform
mpv git master
When dragging the seek bar on short videos, the seek bar and video position should consistently display the key frame for the active GOP at the seeked time.
It should not flicker 'randomly' between adjacent keyframes.
The seek bar and video position oscillate between the previous and the next key frame (bounding the seeked time). This oscillation cycles for each 1-pixel cursor movement between the corresponding slider positions.
Why this is an issue (imo)
I'm guessing this might be an ffmpeg seek API issue, not mpv. Feel free to close if that's the case.
As a workaround I changed "keyframes" to "exact" at this line:
But that's not a solution, as it can make seeking slower / laggy.
Are you saying the flickering back and forth is intended?
I agree it is an intended feature that mouse dragging should use fast keyframe seeking.
That is not an issue. That is a 100% intended feature.
The issue is that video position flickers rapidly between adjacent keyframes, for each 1 pixel moved by the mouse, so that the user cannot seek to a keyframe without difficulty.
"The position should consistently display the key frame for the active GOP at the seeked time."
^^ The above statement is consistent with keyframe seeking. I see my edit may have confused the issue, sorry. Again, if this is an issue with the ffmpeg seek API, I understand it's not easily fixed.
"if you're about in the middle"
^ That's not quite accurate.
The user should not have to play "catch-the-keyframe" with their mouse.
It is practically a random behavior, from the user's perspective.
A clear violation of the principle of least astonishment:
The behavior of least astonishment would be to seek to the keyframe for the current GOP (group of pictures)
No other media player, that I've ever used, has this unpredictable behavior. I'm not bashing mpv. I love mpv. That's why I'd like to find / work on a solution, and why I reported this.
Didn't expect pushback :p
@ChrisK2, some people like their cat videos.
This seems to be fixed by exclusively using
This [change] causes a %-seek "keyframes" to always seek to the keyframe prior to the seek time, i.e. to the keyframe for the seeked GOP. That is, imo, the expected behavior of a seek bar. It also eliminates the ugly oscillation.
This seems to work fine with "exact"/hrseek as well, since (if I'm reading it right) that just works by dropping frames forward.
An edge case is when a keyframes seek factor computes to EXACTLY a keyframe PTS, in which case the previous keyframe will be seeked-to. I'm not sure if adding a minor forward offset to correct this would be considered a hack, or not. But considering that a %-seek is not typically intended as an exact seek operation, this case could be overlooked imo.
I might be missing something here, as I'm not familiar with mpv source.
FYI, since the source file has changed, if you guys ever want to fix it, the source line is now 287.
It'd be a shame if this is a won't-fix. Would it be bad etiquette for me to do a pull-request for this as an outsider?