New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seeking forward 5 seconds ends up seeking backwards #12047
Comments
Do you have |
This issue is about the change in behavior of relative seeks from mpv 0.34.1 where it is working fine. As this is about the default (relative) behavior of seeks changing, the hr-seek option is not being used. With a relative seek is it expected that mpv would seek backwards when asked to seek 5 seconds forwards? Shouldn't a relative forward seek restart playback at one of the keyframes after the current position? Keyframes:
|
Can you reproduce this without the IPC server, using a keybind in |
Yes. The reason we know about this is that the default IINA key bindings tie the left and right arrow keys to seek -5/5. So this was initially noticed due to the unexpected behavior when pressing the right arrow key in IINA. |
Thanks for fixing the title. Yours is better than what I entered. If you need me to run tests or anything like that, don't hesitate to ask. The background on this is that IINA was using old versions of libraries such as libmpv (0.34.1) and the ones from FFmpeg (4) and just recently upgraded. So we are now hearing about regressions from users. Just FYI, I did not report one of these regressions to mpv because it was reproduced directly with FFmpeg and reported to that group. Hardware decoding for VP9 locks up both IINA and mpv on Intel Macs. We are working around that one for now by removing VP9 from hwdec-codecs on Intel Macs. |
I'm not particularly sure where to start, and I can't reproduce this. But I also am not using macOS, which makes it harder. |
Update, I just checked again, and I can reproduce this with the video you linked. |
I can reproduce this with the following:
and then pushing the right arrow to seek forward 5 seconds. The seek is almost immediately reverted. The issue is also reproducible with Log file: https://0x0.st/H2nu.log |
might be related #10876 |
Yes, looks like the same problem. The change from 0.34.1 that has introduced this behavior needs to be identified. |
This is a ffmpeg regression, you can reproduce the same issue with ffplay on ffmpeg-5 but not with ffplay on ffmpeg-4.4.4. Most likely same with #10876 To be specific, this is a regression between the 5.1 and 5.0 releases. I'll try to bisect further |
Reproduced for me as well using |
I bisected it to FFmpeg/FFmpeg@ab77b87 I'll see if I can figure out a fix for this, but you should report it to ffmpeg instead |
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1996e0028c..cb57c4c9ea 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9108,7 +9108,7 @@ static int mov_seek_stream(AVFormatContext *s, AVStream *st, int64_t timestamp,
{
MOVStreamContext *sc = st->priv_data;
FFStream *const sti = ffstream(st);
- int sample, time_sample, ret;
+ int sample, time_sample, ret, offset, requested_sample;
unsigned int i;
// Here we consider timestamp to be PTS, hence try to offset it so that we
@@ -9129,7 +9129,17 @@ static int mov_seek_stream(AVFormatContext *s, AVStream *st, int64_t timestamp,
if (!sample || can_seek_to_key_sample(st, sample, timestamp))
break;
- timestamp -= FFMAX(sc->min_sample_duration, 1);
+
+ offset = FFMAX(sc->min_sample_duration, 1);
+ requested_sample = av_index_search_timestamp(st, timestamp-offset, flags);
+
+ // If we can't seek to the next pts either and it's a different sample,
+ // give up trying to find a good pts to seek to, otherwise we'll end up
+ // seeking back to sample 0 on every seek.
+ if (!can_seek_to_key_sample(st, requested_sample, timestamp-offset) && sample != requested_sample)
+ break;
+
+ timestamp -= offset;
}
mov_current_sample_set(sc, sample); I'm not convinced this is the right approach but you can apply this patch to lavf to fix this. I'll see if upstream agrees this is the right fix. |
Thanks for investigating this problem! I have entered FFmpeg Ticket 10585. With the patch, if I let
Without the patch I was not able to generate that error. With both versions I can trigger this message:
I've included this information in the FFmpeg ticket. |
This is unrelated. |
Important Information
Provide following Information:
A new version of IINA has recently been released with upgraded mpv and FFmpeg libraries. This problem was reported against the new IINA version in issue iina/iina#4502
Reproduction steps
Play the linked video in the sample files section below and try seeking forward 5 seconds.
To reproduce it like I did first make sure
socat
andjq
are installed on your Mac. When invoking mpv enable the IPC interface by adding--input-ipc-server=/tmp/mpv-socket
to the command line. Then while mpv is playing the video run the attached script in another terminal window. This is what the script looks like:seek-test.sh:
The script uses the IPC interface to:
seek-test.sh.txt
Expected behavior
Actual behavior
Playback restarts at an earlier time.
Running the test script shows the
time-pos
property initially advancing by 5 seconds as expected and one second latertime-pos
reports the playback position is earlier than when theseek
command was submitted:This is how I invoked mpv:
Invoking mpv 0.36.0:
These versions exhibited the problem:
This is the output when running the stolendata 0.34.1 build:
Log file
mpv.log
Sample files
I obtained the file that exhibits the problem from here
That file is one of the samples in Photography Blog's Apple iPhone 13 Review. Other samples from that review also exhibited the problem.
The text was updated successfully, but these errors were encountered: