Sync didn't keep when saved.

[Cibdetab]

I have an mp4 to resync. In VLC, a 700 ms sync audio and video almost perfectly and in Avidmux to. When I save the file, the offsync is like the original. I tried 2000 ms to see if Avidmux move something but I can't realy see a difference. I tried 20000 ms and this time, the output file is almost perfectly sync. Sure, Avidmux did the job but it's time consuming to try a value, save the file, open it with VLC and check if it is sync or not. Also, as Avidmux can't accept a value greater than 99999, I suppose that I can't sync a file with an offset greater than 3.5 s. I use Avidmux vr 2.8.1 and config are "Copy", "Copy" and "MP4Muxer". Does somebody have an idea?

[eumagga0x2a]

I have an mp4 to resync. In VLC, a 700 ms sync audio and video almost perfectly and in Avidmux to. When I save the file, the offsync is like the original.

It looks for me like a bug (or design limitation) of MP4 demuxer in VLC, at least if audio needs to be delayed relative to video. This problem doesn't exist with MKV, try to export to MKV instead of MP4.

mpv is worse: it doesn't believe that audio can start later than video and messes up everything trying to synchronize, no matter the container.

ffplay and totem (effectively gstreamer, which does all the work behind the scenes) behave correctly.

Also, as Avidmux can't accept a value greater than 99999, I suppose that I can't sync a file with an offset greater than 3.5 s.

99999 milliseconds is approx. equal 100 seconds = 1 minute and 40 seconds. But in general, something must have gone very wrong to have to deal with offsets exceeding a second.

To judge the effect of delaying audio (using positive shift values), start with a video in perfect sync. Of course, if a player doesn't support edit lists in MP4 or assumes that audio and video always start at the same time, you won't get correct results.

[Cibdetab]

I say 3.5 s because if a value of 20000 gives a 700 ms delay, I suppose that five times more (99999) will gives 3.5 s.
The beauty of Avidmux is to be able to sync audio without re-encoding the file. I can try to save in mkv to help to find the culprit but it is not a perspective.

[eumagga0x2a]

I say 3.5 s because if a value of 20000 gives a 700 ms delay, I suppose that five times more (99999) will gives 3.5 s.

This is wrong. If a player you target doesn't properly support necessary features (edit lists), you get nothing (or you need to re-encode the audio track). Else you get exactly the same delay as you had set in Avidemux.

[Cibdetab]

So why a 20000 ms value shift the audio of 700 ms on the output file?

[eumagga0x2a]

Maybe because Avidemux and VLC disagree about the start point of timestamps in the video, with Avidemux starting at zero DTS (decode timestamp) and VLC at the PTS of the first frame. Both differ if the video stream contains B-frames and can be quite substantial (700 ms are not totally implausible). It would be necessary to have a look at least at admlog.txt from loading the source and saving the output to be able to tell for sure.

Use a player with a proper support of edit lists (ffplay) to see the difference.

[Cibdetab]

I will no longer loose my time and brain to find what's the matter with this problem. I will only find the good value in VLC or Avidmux, multiply it by 28.5 and save. I tried that with few videos and it seems to work. Maybe the future will give me an answer.