mpv icon indicating copy to clipboard operation
mpv copied to clipboard

audio stops playing for 3-5s when using seek backward (#LEFT seek -5) with external audio track (.mka)

Open geextahslex opened this issue 1 year ago • 13 comments

mpv Information

mpv v0.38.0-711-g67e087dc Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Aug 20 2024 00:11:31
libplacebo version: v7.349.0 (v7.349.0-5-g82bf46a-dirty)
FFmpeg version: N-116752-g507c2a577
FFmpeg library versions:
   libavcodec      61.11.100
   libavdevice     61.2.100
   libavfilter     10.2.102
   libavformat     61.5.101
   libavutil       59.34.100
   libswresample   5.2.100
   libswscale      8.2.100

Other Information

Windows version: Windows 10 22H2 Build 19045.4170)
GPU model, driver and version: intel HD Graphics 4600, driver: 20.19.15.5171
Source of mpv: https://sourceforge.net/projects/mpv-player-windows/files/
Introduced in version: v38.0

Reproduction Steps

watch video (in my case 40-50min video 1080p) with an external .mka audio track and seek backward (one time or multiple times) with default keybind #LEFT seek -5 # seek 5 seconds backward

Expected Behavior

seek works smooth like with an internal (inside the .mkv) audio track

Actual Behavior

when using seek backward. The audio will stop for 3-5 seconds (sometimes even more) and then it will play again

Log File

gpu-debug output.txt normal logfile v.38.0 output.txt v0.38.0-711-g67e087dc output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

  • [X] I tested with the latest mpv version to validate that the issue is not already fixed.
  • [X] I provided all required information including system and mpv version.
  • [X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
  • [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
  • [X] I attached the full, untruncated log file.
  • [X] I attached the backtrace in the case of a crash.

geextahslex avatar Aug 23 '24 18:08 geextahslex

Pretty sure this was fixed by #14399.

Dudemanguy avatar Aug 23 '24 18:08 Dudemanguy

yes the video stopping and speeding up was solved. But still if you seek backwards it takes about 2 seconds for the audio to work. So it still handles external audio worse than native

geextahslex avatar Aug 23 '24 18:08 geextahslex

I just gave it a try myself with a webm + mka and was not able to reproduce.

Dudemanguy avatar Aug 23 '24 20:08 Dudemanguy

how long was your video? I have this issue with episodes that are about 40-50min long 1080p I doubt that these are performance issues on my end with a 1080p file ^^' video works fine but the audio takes sometimes 3-5 seconds to kick in when going backwards

geextahslex avatar Aug 23 '24 21:08 geextahslex

Took a 2 hour movie, extracted the audio, played the movie + external audio with --audio-file and there were no problems when seeking backwards. If you think this is a problem, please open a new issue preferably with sample files that reproduce the issue. Might be AO-specific or something. I'm on ALSA.

Dudemanguy avatar Aug 23 '24 22:08 Dudemanguy

okay. yeah this is annoying as I use only external audio tracks

geextahslex avatar Aug 23 '24 22:08 geextahslex

Pretty sure this was fixed by #14399.

No, that PR enables refresh seek for some specific situations, but it does not solve this problem written in the commit message:

tracks from multiple demuxer instances are not synced in any meaningful way beyond the separate explicit seeking

There was briefly a fix for this but was removed in c10ca137a871c0cebbfa84d802e28e5eddd8705c. The problem was detailed as a comment there:

// When doing keyframe seeks (hr_seek=false) backwards (no SEEK_FORWARD), // then video can seek before the external audio track (because video seek // granularity is coarser than audio). The result would be playing video with // silence until the audio seek target is reached. Work around by blocking // the demuxer (decoders can't read) and seeking to video position later.

It is unnoticeable for forward seek because in that situation, mpv just discards the audio data before the video keyframe timestamp.

na-na-hi avatar Aug 23 '24 22:08 na-na-hi

I guess I should have mentioned that by "seek backwards" I mean the default keybind #LEFT seek -5 # seek 5 seconds backward I don't mean clicking on the timebar, that works normally ^^'

geextahslex avatar Aug 23 '24 22:08 geextahslex

I was also seeking backwards with keybinds in my testing.

Dudemanguy avatar Aug 23 '24 23:08 Dudemanguy

https://github.com/mpv-player/mpv/issues/10887 It was never fixed for me.

hooke007 avatar Aug 24 '24 04:08 hooke007

Huh, guess I'll reopen then.

Dudemanguy avatar Aug 24 '24 05:08 Dudemanguy

okay I updated the issue description and title, and took the video part out. So it's now only about audio the output logfile and mpv information are also updated

geextahslex avatar Aug 24 '24 11:08 geextahslex

same thing happening to me

mpv v0.38.0-dirty Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Jul  3 2024 05:59:22
libplacebo version: v7.349.0
FFmpeg version: n7.0.2
FFmpeg library versions:
   libavutil       59.8.100
   libavcodec      61.3.100
   libavformat     61.1.100
   libswscale      8.1.100
   libavfilter     10.1.100
   libswresample   5.1.100

running EndeavourOS on kernel version 6.9.2-arch1-1.1

leto-ux avatar Aug 27 '24 11:08 leto-ux