Opened 7 months ago

Last modified 7 months ago

#10585 open defect

Seeking forward in iPhone video ends up seeking backwards

Reported by: low-batt Owned by:
Priority: normal Component: avformat
Version: git-master Keywords:
Cc: low-batt Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (2)

console-output.txt (827.2 KB ) - added by low-batt 7 months ago.
Console output
ffplay-20230923-153526.log (835.5 KB ) - added by low-batt 7 months ago.
Generated report

Download all attachments as: .zip

Change History (11)

by low-batt, 7 months ago

Attachment: console-output.txt added

Console output

by low-batt, 7 months ago

Attachment: ffplay-20230923-153526.log added

Generated report

comment:1 by llyyr, 7 months ago

I've posted the patch to the mailing list here

comment:2 by Balling, 7 months ago

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.

comment:4 by Balling, 7 months ago

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

comment:5 by low-batt, 7 months ago

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

comment:6 by Balling, 7 months ago

Status: newopen

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

comment:7 by low-batt, 7 months ago

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.

comment:8 by Balling, 7 months ago

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

comment:9 by low-batt, 7 months ago

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.

Note: See TracTickets for help on using tickets.