Seeking forward in iPhone video ends up seeking backwards

[low-batt]

Summary of the bug:
Seeking forward by 10 seconds in HEVC video recorded on iPhone causes playback to resume at an earlier time.

This is a regression.

This report originates from ​IINA issue #4502

Which was then reported to the mpv project in ​mpv issue #12047

User llyyr found the problem was reproducible with FFplay and identified the following commit as introducing the problem: ​commit ab77b87

A FFmpeg patch has been submitted by llyyr, who cautions this may not be the right approach to fix this: ​patch 20230923111034

With that patch I am no longer able to reproduce the seeking backwards behavior.

However if I let the video play until the end and then start seeking back and forth using the arrow keys I can sometimes trigger the following error:

FullHD30fps.mov: error while seekingKB vq=    0KB sq=    0B f=0/0  

With and without the patch that will also trigger this message:

[hevc @ 0x11ce4df20] Multiple Dolby Vision RPUs found in one AU. Skipping previous.

The file used to reproduced the problem can be downloaded 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.

How to reproduce:
Start playing the above file with FFplay and as soon as the video starts playing press the right arrow key to seek forward 10 seconds. Instead of seeking forwards, playback will resume at an earlier time.

Output was too big to add inline. I will add as an attachment.

[low-batt]

Console output

[low-batt]

Generated report

[llyyr]

I've posted the patch to the mailing list here

[Balling]

With and without the patch that will also trigger this message:

Yep. I wanted to report it in libplacebo for a long time. But was lazy.

[Balling]

I cannot reproduce. ​https://github.com/mpv-player/mpv/issues/12047

mpv.com ​https://img.photographyblog.com/reviews/apple_iphone_13/sample_images/FullHD30fps.mov --pause and press right the seeks work good.

Probably got fixed by ​https://github.com/mpv-player/mpv/pull/12457 and all the related pulls like this insane: ​https://github.com/mpv-player/mpv/pull/12304 and those ​https://github.com/mpv-player/mpv/pull/12356 ​https://github.com/mpv-player/mpv/pull/12354

[Balling]

I can reproduce ffplay ​https://img.photographyblog.com/reviews/apple_iphone_13/sample_images/FullHD30fps.mov though. Seek forwards leads to bad seek.

[low-batt]

The FFmpeg issue is a regression. If mpv is built with an old enough version of the FFmpeg libraries then mpv will not exhibit the problem.

Using ​mpv-build I built both FFmpeg and mpv from their master branches today. Playing FullHD30fps.mov and pressing right arrow still resulted in playback restarting from an earlier position.

Double check the versions of the FFmpeg libraries being used in the mpv executable that does not exhibit the problem.

low-batt@gag mpv-build (master %=)$ mpv/build/mpv --version
mpv v0.36.0-406-g49286209a0 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
 built on Sep 24 2023 15:05:33
libplacebo version: v6.337.0-rc1-1-g61c1c589
FFmpeg version: N-112171-g13a3e2a9b4
FFmpeg library versions:
   libavutil       58.25.100
   libavcodec      60.27.100
   libavformat     60.13.100
   libswscale      7.3.100
   libavfilter     9.11.100
   libswresample   4.11.100

[Balling]

Again, I can reproduce it with ffplay. I just cannot with mpv. Please update mpv to latest: ​https://github.com/zhongfly/mpv-winbuild

[low-batt]

I am unable to test with the mpv-winbuild release as I have a Mac, however the above test was run with a build made today from the very latest FFmpeg and mpv sources.

Seems like something else is causing the difference in mpv behavior. I always dislike it when behavior can't be explained. It can mean there is more to the problem than is currently known.

When testing was --no-config specified? The problem occurs with relative seeks. A mpv config file with --hr-seek=yes in it that configures exact seeks would keep the problem from reproducing.

[Balling]

I can reproduce it with mpv. You just need to download the file. It does not happen with https:

[low-batt]

Ah. My fault! In the mpv issue I provided a link to the file and then failed to make it clear that I downloaded the file and wasn't streaming. Sorry about that. Thanks for figuring out what was causing the difference in behavior.