Audio out of sync in mp4 file that plays fine in VLC and SMPlayer

[BillBaldwin2]

Windows 7 Ultimate 64-bit. Avidemux 2.7.8.

Just what the title says. The mp4 file plays fine in VLC and SMPlayer. I open it in Avidemux and the audio runs about 1 second ahead of the video. Saving the file via Copy mode with Avidemux preserves the problem. Re-encoding the file with Avidemux preserves the problem. Any ideas how to get Avidemux to play the file with the sound synced the way my video players do and to save a clip from it that syncs properly?

Here's the clip the way Avidemux saved it using Copy mode:

https://youtu.be/Hc5Kwa2C9f4

The original video syncs perfectly.

[eumagga0x2a]

Avidemux 2.7.8 is an unsupported old release. Please install the latest available nightly build (as of this writing it is 2.8.1 r220114 from here) right away and verify that the problem persists. If it does, please provide the source video (not the output of Avidemux!) as a sample via WeTransfer, Mega, Dropbox or Google Drive.

In general, a constant A/V offset can be easily corrected using the "Shift" checkbox and selecting a positive value in order to delay audio relative to video.

[eumagga0x2a]

In case CleanTalk interferes with replying, please resort to personal messages as an emergency solution.

[BillBaldwin2]

Avidemux 2.7.8 is an unsupported old release. Please install the latest available nightly build (as of this writing it is 2.8.1 r220114 from here) right away and verify that the problem persists. If it does, please provide the source video (not the output of Avidemux!) as a sample via WeTransfer, Mega, Dropbox or Google Drive.

In general, a constant A/V offset can be easily corrected using the "Shift" checkbox and selecting a positive value in order to delay audio relative to video.

Hokey doke, thanks for the help. Now running 2.8.1 r220114. Problem confirmed. I know  I can always offset the sound and sync it up manually. That's a fussy long process for me and I'm never 100 percent sure I got it right, just close enough.

Here's the 500+ meg video if anyone really wants to look at it. (No worries if that's more work than you want to do.)

https://drive.google.com/file/d/1DJnpuUZ-JbrX7Yxj_u_oB6c7MIH8AB34/

I've successfully re-saved this video via VLC and the result is audio-synced (and also 60% of the size, so I'm not sure what settings VLC uses). When I upload VLC's version into Avidemux, the video stays synced. This is a fine if time-consuming workaround. So at this point I'm sort of just trying to figure the problem out to enhance my own understanding.

I notice that the original file has two audio tracks--one AAC and one AC3. I tried disabling each in turn and saving the video with a single audio track. Either way, the audio remains out of sync.

The original video, by the way, was created by Handbrake from a .wtv file. That was a few years ago and I'm not sure what settings I was using back them.

[eumagga0x2a]

I'm sorry, could you please provide the video per link sharing?

[BillBaldwin2]

I'm sorry, could you please provide the video per link sharing?

I'm not sure what that means. This is the link Google Drive gives me and it says "anyone on the Internet with the link can view":

https://drive.google.com/file/d/1DJnpuUZ-JbrX7Yxj_u_oB6c7MIH8AB34/view?usp=sharing

There's an option to add email addresses of those who have permission, but I don't know your email.

[eumagga0x2a]

Thank you very much, got the sample, you may take it offline. There is a huge gap in timing of 647 milliseconds between the first and the second frame which perfectly matches the necessary correction in Avidemux. Will investigate deeper at a later point.

In general, the fps of the video should have been constant 60000/1001, but Handbrake used a variable frame rate oscillating between 90000/1501 and 90000/1502 (with a few gaps) as an approximation.

[BillBaldwin2]

Thank you very much, got the sample, you may take it offline. There is a huge gap in timing of 647 milliseconds between the first and the second frame which perfectly matches the necessary correction in Avidemux. Will investigate deeper at a later point.

In general, the fps of the video should have been constant 60000/1001, but Handbrake used a variable frame rate oscillating between 90000/1501 and 90000/1502 (with a few gaps) as an approximation.

Thank you so much! So that was from back when I was using variable frame rate because I knew even less than I know now. I can see the 647 ms gap now that I know where to look. This will help me in dealing with other video that was saved in the same fashion.

A couple of follow-up questions if you have the time:

1. Any guesses as to why SMPlayer and VLC didn't mind the gap and played the audio in sync?

2. Is there a way to losslessly shift the audio by that 647 ms when saving a clip from this file or does that necessarily involve re-encoding the audio? (In SMPlayer I can just tell it to play the audio on 647 ms delay. But of course if I upload the video to YouTube the problem will still be there for viewers online.)

[eumagga0x2a]

1. I could imagine that these players align audio timing at the PTS (presentation timestamp) of the first frame while Avidemux probably uses DTS (decode timestamp). In this case the A/V sync problem should affect all videos with B-frames. The high PTS delay in this sample makes the issue just more noticeable.

2. The shift is lossless when in copy mode and the result exported using the MP4 muxer shows perfect sync both in Avidemux and in mpv (or in ffplay). A trick is required, unfortunately, in order to enable shift for the second audio track (AC3) too: "Audio" --> "Select Track" --> select an encoder instead of "Copy", else the audio filters button is disabled --> enable shift --> switch back to "Copy" --> OK.

I cannot test whether YouTube likes the remuxed video too, though.

[BillBaldwin2]

2. The shift is lossless when in copy mode and the result exported using the MP4 muxer shows perfect sync both in Avidemux and in mpv (or in ffplay). A trick is required, unfortunately, in order to enable shift for the second audio track (AC3) too: "Audio" --> "Select Track" --> select an encoder instead of "Copy", else the audio filters button is disabled --> enable shift --> switch back to "Copy" --> OK.

Got it! Thank you SO much for all your help.

[jimmy]

Apologies for intruding on this thread.

I may be wrong, but i always assumed using the delay feature in ADM does not make any actual change to the audio track, but only adds a flag in the container telling the play back device to shift the audio.

Thus, I never use that feature because I want the sync "bulletproof" for any play back device.

So, without needing to re-encode the audio, with your project loaded in ADM, somewhere near the start of the video, ideally at a silent point, simply add or delete the required number of frames to shift the audio. If you want to advance the audio by 647ms cut and paste about 15 frames of silence near the start of the video, or delete that many frames if you want the audio earlier.

Easy. Now just save the audio in copy mode, re-load your original project into ADM, add the modified external audio track and remux and you have your original video and modified but not re-encoded "bulletproof" audio. (To keep audio the same length, when you cut or add frames near the start, you can go near to the end of your project and cut or add silence to compensate.)

[eumagga0x2a]

I may be wrong, but i always assumed using the delay feature in ADM does not make any actual change to the audio track, but only adds a flag in the container telling the play back device to shift the audio.

The shift feature in copy mode manipulates the timing of compressed audio packets so that negative shift values (advancing audio relative to video) means that first packets are dropped until their DTS (decode timestamp) is not less than the start of the range which is exported / saved.

A positive shift like in this topic (delaying audio relative to video) increases the timing associated with each packet. It is the business of the muxer to translate this to actual structures in the file. However, edit lists – the structure to store time offsets in MP4 – are really well supported.

Thus, I never use that feature because I want the sync "bulletproof" for any play back device.

You probably should rather ensure the video doesn't contain B-frames as the resulting PTS delay was the reason for disagreement between Avidemux and video players which can allow timestamps become negative.

[jimmy]

A positive shift like in this topic (delaying audio relative to video) increases the timing associated with each packet. It is the business of the muxer to translate this to actual structures in the file. However, edit lists – the structure to store time offsets in MP4 – are really well supported.

Thanks, good to know. Sounds like my assumption was half right and half wrong.

You probably should rather ensure the video doesn't contain B-frames as the resulting PTS delay was the reason for disagreement between Avidemux and video players which can allow timestamps become negative.

Now this really confuses me. I have read this before on these forums but everything I load into ADM has B-frames and everything I encode with ADM has B-frames. Luckily, even a messy sync problem (such as starting in sync for the first 20 minutes, then out of sync for 20 minutes, then back in sync) is usually fairly easy to deal with, although, unlike the OP, I use AC3/MKV. Although, maybe the difference is my final output is always an A/V encode, never copy mode.