mpv
mpv copied to clipboard
audio stops playing for 3-5s when using seek backward (#LEFT seek -5) with external audio track (.mka)
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.
Pretty sure this was fixed by #14399.
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
I just gave it a try myself with a webm + mka and was not able to reproduce.
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
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.
okay. yeah this is annoying as I use only external audio tracks
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.
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 ^^'
I was also seeking backwards with keybinds in my testing.
https://github.com/mpv-player/mpv/issues/10887 It was never fixed for me.
Huh, guess I'll reopen then.
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
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