Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I have a longstanding issue with video playback on Linux where if I seek multiple times forward or backward (i.e. by pressing the right or left arrow keys) the video and audio will become visibly desynced or the audio will drop out entirely.  These issues will stick around as long as the current playback session is ongoing, but stopping and restarting playback will restart at the same part of the video with the video and audio perfectly synced.  I don't do much seeking except when watching recorded TV, so I've just been using the seek/stop/start as a workaround.   I thought I reported the issue a few years back, but I can't find any threads so maybe I just forgot to report it?

With the "old" JRVR renderer the issue usually isn't a problem for the first few seeks, but if I seek more than a few times it gets farther and farther out of sync, and sometimes the audio drops out completely.  I was hoping the issue might be resolved when using the new presentation/rendering queue, but if anything the issue seems worse.  Seeking is kind of rough with the presentation queue and even two or three seeks now seems like enough get the audio visibly out of sync with the video. 

Reproduction steps:

1) Start video playback and seek forward maybe five or ten times in quick succession by pressing the right arrow key (i.e. seeking forward 3:00 to 5:00 minutes with default settings). 
2) Look for a scene with dialog and the audio from the dialog will be notably out of lipsync with the characters speaking on screen (in my testing the audio always lags behind the video, not vice versa).
3) If you press stop and then play again, playback will resume almost instantly at the same spot with perfect lipsync.

I can reproduce this on Debian Bookworm running XFCE4 or Gnome, and also on other Linux systems.  The issue doesn't seem to care about whether the files are on a local drive or accessed via CIFS (although it seems easier to get the audio to drop completely on remote files).  I'm mostly testing with DVD or Blu Ray rips to mkv, with a few mp4s thrown in, but the issue also affects TV programs recorded by JRiver in .ts format.  I haven't tested whether it's an issue with live TV playback or not.

Let me know if I can provide logs or any additional info.

[drmimosa]

I see this behavior as well, when I'm seeking MKV movies and concert videos the video and audio go out of sync.

Stopping and Starting playback resolves the sync.

[Hendrik]

Does this only happen if you seek rapidly in quick succession? If you seek once eg. by clicking on the seek bar its fine?

Is the file from local, or network?

[mwillems]

Does this only happen if you seek rapidly in quick succession? If you seek once eg. by clicking on the seek bar its fine?

I think one seek causes mild desync.  The desync seems cumulative so it's a little hard to tell with one seek.  For example, in one playback session, if I sync four or five time the sync will be visibly off.  If I then wait and sync four more times during the same playback session the sync seems even more off than it was, and if I keep syncing I'll sometimes lose the audio entirely.  It doesn't seem to make a difference whether I seek using the scrubber bar or using the keyboard/remote controls, if I seek on the scrubber bar multiple times I definitely get desync.  So that said, I think that I see mild desync after one seek, but it's hard to tell as there's only a little desync after one seek.  The problem becomes much more obvious after a few seeks.

Is the file from local, or network?

I can reproduce the issue with either local or networked files.  I think (and this is a vibe) that the problem is slightly worse with networked files, but that may just be because seeking is generally more responsive with local files.  That is, I feel like it might take a few more seeks to reproduce the issue with a local file, but I don't have a good way to measure, so it might just be a false impression.  To be clear I definitely still see the desync when seeking in local files.

[Hendrik]

I can't seem to reproduce this on Windows using the cross-platform playback engine, the only difference then being the audio output itself, which makes me wonder if thats related to that part.
Next going to update one of my NUCs for some real hardware linux testing.

[mwillems]

I can't seem to reproduce this on Windows using the cross-platform playback engine, the only difference then being the audio output itself, which makes me wonder if thats related to that part.
Next going to update one of my NUCs for some real hardware linux testing.

FWIW I also can't reproduce it on Windows.  It seems to be Linux specific (or at least not a Windows issue).

So this may be a completely irrelevant red herring, but I seem to recall that the Linux video playback engine relies on some open source libraries, so I thought I'd mention it.  There was a period of about a year or so where I saw the exact same desync on seeking problem I see in JRiver with the mpv video player as well, but with no other Linux players (i.e. VLC was fine).  mpv has since fixed itself and no longer has a desync issue, but I thought I'd mention it just in case you rely on any shared libraries with mpv; it's possible that the same underlying issue was causing it for both of you and updating the dependencies might help?  Sorry if that's a distraction/not relevant.

In case it's relevant, here's the --version for the mpv I'm running that does not show any desync issues is

Code: [Select]

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


[Hendrik]

MC33 already uses pretty much updated libraries all around, including FFmpeg 7.0. But hopefully it reproduces on an actual linux system once its done updating.

[Hendrik]

I could reproduce some level of sync issues after seeking on an actual linux box, although not quite as bad as hinted at here, but regardless i'll investigate and fix that and we'll see how it impacts this.

[Hendrik]

Turns out the audio output wasn't being flushed properly on seek, which I've implemented now. Let us know how it looks on your end once the next build rolls out.

[mwillems]

Turns out the audio output wasn't being flushed properly on seek, which I've implemented now. Let us know how it looks on your end once the next build rolls out.

Rad!  Thanks for looking into it,  I'm excited to test.

[bob]

Rad!  Thanks for looking into it,  I'm excited to test.

33.0.19 in the beta repo (or via direct DL from the forum message).
It's beta because the method of creating all windows was changed. If it's good to go I'll add it to latest.

[mwillems]

33.0.19 in the beta repo (or via direct DL from the forum message).
It's beta because the method of creating all windows was changed. If it's good to go I'll add it to latest.

Ok in preliminary testing of build 19 on two different machines, I couldn't reproduce the seek-induced desync anymore!  Even with a laptop that has a slightly flakey wifi connection, the audio was always synced, and I couldn't get the audio to drop out at all.  I only spent about 15 minutes testing, but I did some pretty aggressive seeking.  I think you got it.

There were no obvious issues with windowing that I could detect, but the playing now popup still steals focus with default settings in Gnome unfortunately.  I did find a workaround that I'll post over in the build thread.

[bob]

...
There were no obvious issues with windowing that I could detect, but the playing now popup still steals focus with default settings in Gnome unfortunately.  I did find a workaround that I'll post over in the build thread.

WRT that I may have another fix. I'll generate a beta for you to test.
In addition if you are using anything that displays a webpage during playback (like a trackinfo) disable that for testing please.

[Hendrik]

Ok in preliminary testing of build 19 on two different machines, I couldn't reproduce the seek-induced desync anymore!  Even with a laptop that has a slightly flakey wifi connection, the audio was always synced, and I couldn't get the audio to drop out at all.  I only spent about 15 minutes testing, but I did some pretty aggressive seeking.  I think you got it.

Sounds good, thanks for the rapid testing! Turned out to be an obvious and simple issue, but sometimes finding it just takes all the time!

[drmimosa]

I tested build 20 on my system and the sync issue also seems resolved. I have a lot of concert videos where small sync errors can seem very obvious, this build is a great improvement. Thank you!