+100ms with almost every mp4v2 remux

[zakk]

Hi, I've done a lot of remuxing h.264 to mp4v2 these last days, and everytime I see a +100ms audio shift (I'm good at lipsync  ), which I have to correct manually. Can someone please have a look at the code and confirm ?

[AQUAR]

I usually check by playing both the original and remuxed media files at the same time.
When the displayed frames are lined up you get a sound echo if the time base is different.

After the mpv2 remux there is definitely an echo.
Using on the fly audio shift with VLC that echo is cancelled with a 0.1 sec shift.

Using VLC to determine the time value for lip sync correction is very easy (in case anyone is interested!).

[mean]

Does not happen with mp4 (lavc/ffmpeg) ?

[AQUAR]

Did some more testing:
Remuxing from MKV (with AVC & AAC) to MP42 or ISOM gives the echo that needs a .1 sec shift.
Remuxing from MP42 or ISOM to either MP4 containers maintains audio sync.

Only tried with one MKV file, as most have AC3 audio.
Small sample testing may not be representative.

@ mean
Sorry - was your reaction to be read as a statement, a question or as uncertainty wrt mp4 muxing?
Presumed you were asking if this delay also happens with mp4.

[zakk]

I hear no difference between mp4 and mp4v2, so I would say yes, same audio shift.

[AQUAR]

Still not sure about the intent of Means response.
I also found that the .1 sec audio shift is there when remuxing from MKV to MP4 or MP42.

[AQUAR]

Just an interesting tangent I came across as a result of this corrective shifting of audio relative to video.

I wanted to transcode an MKV with AVC to an MKV with Xvid with the -100ms audio delay.
MediaInfo showed 28ms delay in the source.
Accidentally typed in -1000ms, and of course the resultant audio was completely out of sync with the video.

I did not notice the -1000ms untill after looking at MediaInfo, which showed the delay to be 1mn 5s.
Strange value for the delay (ie 1mn 5s = 65000ms) and not at all consistant with the actual result.

I remuxed the transcoded video adding back a 900ms delay, and audio/video sync is good as expected.
Mediainfo now shows the delay to be 568ms.
Maybe: 28ms+568ms+900ms ~ 1500 ms = 1.5sec and reported as 1mn 5s?
Can't trust MediaInfo to report negative audio delays, as the real result should be 28ms-100ms=advancing by 72ms.

[AQUAR]

Just a few more curious observations that relate to this audio delay item.

Starting from a source without audio delay, and adding a -100 ms delay, gives a consistent result in Mediainfo of '28 ms delay'.

This 100 ms audio delay has been cropping up in lots of my media files with AVC in it.
And these media files haven't been touched by avidemux.
Maybe its a container or x264 bug?

Been correcting them with MKVToolnix as well as muxing in external sub.

[Jan Gruuthuse]

upload
- original video AVC speech 10 seconds
- avidemux handled output with -100ms delay off above video
- corrected avidemux output with MKVToolnix
so mean can compare these videos.

The delays are these caused by AC3 audio track being track 0? If so check if delay is present when played on flat screen tv/stand alone media player.

[AQUAR]

Happy to provide samples if Mean has an interest and needs them.

Its such a common experience (zak can attest!) that you can easily find test material for this audio delay.
I will check the track positioning and AC3 audio to see if it causative.

Most people will not notice a negative 0.1 sec hence it is so under reported.
When you are aware of it then you tend to look for it, and correct for it.
Because it makes a subtle difference to the visual/aural experience.

[zakk]

I usually check by playing both the original and remuxed media files at the same time.

Could you please tell me how you do that ?

[AQUAR]

Its a bit off a fiddle and relies on the fact that visual clues are easier and faster to recognise than audio clues.

You have to run two instances of a media player side by side.
One with the original source and the other with the remuxed copy.
(do it on a PC that can keep up the demand of playing 2 videos at the same time!)

Pause them at the same point and then start them both.
Then repeat momentary pause/start on the first player, until the other one catches up.
With a bit of practice you can get both video's playing in sync by closing in with single frame accuracy.
If they are in sync its very easy to tell, particularly at scene changes.

With video in sync, if you get an echo in the audio sound, then the audio has been shifted in the copy.
100 ms represents 2 to 3 video frames, so the audio echo is quite distinct.   

Of course - this approach is only to proof that the audio has been shifted.
The lip syncing to sound is more practical to fine tune these audio issues (in steps of 25 ms!).
 

[twinsun]

I also have time shift with h264/ac3 (other cases not in mind), but sometime, not all
time, and depending on the source. Twenty percent of mines have time shift.
Not a real problem for me, I am used to quickly handle this small problem (big if not
fixed).

In every cases of audio shift I have, I heard the shift directly playing with Avidemux
window, the original video to be encoded.
Of course, this video as no shift with various players
So in MY cases, the encode process is NOT involved, it's the decode one.

I just enter the time shit, mainly -200 -100 +100 +200 (in rare cases +400! +500ms!), and edit as usual.
It's approximative time obviously, since based on lip sync, indoor outdoor changes,
etc., but very satisfying as result, and very quick to fix.

[AQUAR]

The source may also include some audio shift and that may impact on the remux (ie no recoding here).
Mediainfo is pretty much incorrect in reporting negative delays, so I always play it by ear (pun intended!).
I simply add -100ms and then do lipsyncing if needed.