News:

--

Main Menu

Audio loose sync with video

Started by User007, October 27, 2023, 05:30:50 PM

Previous topic - Next topic

User007

When i open video file i always notice that audio loose sync with video, all i do is navigate the timeline with mouse, any way to fix this?

eumagga0x2a

I guess this happens only with high-resolution videos and/or those encoded with codecs which cannot be decoded in real time on this hardware, i.e. it is a performance issue.

User007

Quote from: eumagga0x2a on October 27, 2023, 07:00:49 PMI guess this happens only with high-resolution videos and/or those encoded with codecs which cannot be decoded in real time on this hardware, i.e. it is a performance issue.
It happened with 1920x1080 30fps 100Mbps video, video is running fast so i don't think its performance issue.

eumagga0x2a

If you can sync A/V for a short while by seeking, it is a performance issue.

Redlof

Bumping with a similar issue:
In my case i have a high res video (1440p) with VP9 for Video and OPUS for Audio in file properties (which is not something i encounter all too often) and it would make sense to me that for w/e reason my software/hardware can struggle to process all of that (which it does by playing the audio normally and video constantly desyncing further and further behind, with it resetting each pause and play).
However there's a difference in that when i try to download said video off of youtube with yt-dlp and have it give me a .mp4 at the end, that file is messed up and not accepted by some other editing software as well as 2.7.x versions of Avidemux playing only dark screen with a glitchy line at the bottom instead of a video.
But if i don't do any extra arguments when downloading the video and have a .webm as a result it still is lagging video behind in any 2.8.x, but 2.7.x have no issues with playing the video and audio in sync without any problems. If i have to use older versions for some weird cases like this i can do that no problem, but i don't really understand how the 2.8.x Avidemux can't do the same things the past versions do perfectly fine.
Also if i download 1080p .mp4 version of the aforementioned video through other software i get an improvement in 2.8.x, but only slight, since despite the resolution being "normal" and without VP9/OPUS it still lags the video behind, but not as badly as before, while 2.7.x still doing absolutely fine.
I don't really expect there to be a solution of any sort, plus past versions being usable already kind of is one, but if possible it'd be nice to have some comment on potential causes of this and/or why do the versions matter in this situation.

eumagga0x2a

Quote from: Redlof on December 22, 2023, 07:17:45 PMif i don't do any extra arguments when downloading the video and have a .webm as a result it still is lagging video behind in any 2.8.x, but 2.7.x have no issues with playing the video and audio in sync without any problems.

My first guess would be post-processing being enabled and therefore wasting a lot of CPU time. IIRC, post-processing was on by default but at the same time broken in 2.7.x. It was fixed later while the default setting was flipped to off, but as Avidemux obeys existing configuration, all users who started with 2.7.x (or even 2.6.x) versions and kept the old Avidemux profile with 2.8.x, inherited the old default, enabling now working but usually nonsensical post-processing. Please make sure PP is off.

In all cases, please make sure you don't use the unaccelerated "Qt" renderer, indicated as "RGB" in the main Avidemux window, unless all other renderers crash. The fastest renderer on Windows is "DXVA2".

If it is neither post-processing nor an unaccelerated renderer, please provide the YouTube-ID and the stream ID of the video to allow me to check deeper: if the video is HDR, current Avidemux versions may be able to convert decoded pictures to SDR for naturally looking colors. This procedure, called HDR tone mapping, is computationally very expensive and is performed in Avidemux exclusively on the CPU. In the 2.7.x era, this feature was simply unavailable.