tsmuxer audio delay

[stefanregen]

I have read a lot about this but I don´t understand why this issue happens when creating a BD Folder right from a m2ts file (with AC3 Audio) which of course has no delay.
Unfortunately the delay becomes more and more, otherwise this would be no problem.
After 2 hours I have 0,6 sec. delay.
(tsmuxer2.6.1.2)

I tried mutiAVCHD as well but as this program uses the same muxing engin (just a little older one...) multiAVCHD makes the same delay.

Is there any solution for this?

EDIT: source file is 1080/50p AC3 made with tsRmuxer

I just found the reason: It´s Nvidea. I muxed the same file on my Lapdop (Radeon grafic Card) without any problems. Then I deaktivated everything from Nvidea (except display drivers) on my PC and got really much better results.
Now, with only display drivers enabled the delay is just 150ms after 2 hours, which is quite accaptable as you can give some extra delay to get a mid of say 75ms at start and 75 in the end...

[Ghitulescu]

My neighbour's car didn't start this cold morning. If you tell me what's wrong with it, I will tell you what's wrong with your file :) :)

[stefanregen]

My neighbour's car didn't start this cold morning. If you tell me what's wrong with it, I will tell you what's wrong with your file :) :)
WOW, I have never thought of getting such a stupid answer!

[ggtop]

Unfortunately the delay becomes more and more

Hi,

increasing audio delay may be an indicator your source file is e.g. 24 fps whereas you mux it to as 23.976.

ggtop

[stefanregen]

Hi,

increasing audio delay may be an indicator your source file is e.g. 24 fps whereas you mux it to as 23.976.

ggtop
Source is 1080/50p
Muxer is set to not changing anything.
The file is made from 13 MP4files with AAC , joined together in Avidemux. The videocodec is unnchanged, the audiocodec I chanched to AC3. From the result I first tried to mux a BD file with tsMuxer. This results in increasing audio delay.
So I first made an m2ts file with tsRmux. Now I got a perfect m2ts file with no delay.
With this file I tried tsmuxer again and got the same increasing audio delay.

(Unfortunately I can´t use tsRmuxer`s BD output. I Need the output of tsmuxer)

[Ghitulescu]

WOW, I have never thought of getting such a stupid answer!

The answer matches the question (and the instructors say there are no stupid questions :) )

Without giving any detail of your source you won't get any non-stupid answer.

[Ghitulescu]

The file is made from 13 MP4files with AAC , joined together in Avidemux.

The delay is not progressive, to you it appear like progressive.

It is the result of audio timeline. Each individual MP4 has different lengths for audio and video, because of the different lengths of the audio and video units (the AC3 frame is not an integer (sub)multiple of the video GOP). These differences will accumulate step by step up to the end of the movie.

The only solution to this is to use a two track video editor and place each MP4 alternatively in the timeline and let them overlap a bit (one frame or the next GOP or next scene, as you like). The audio will be re-rendered accordingly.

[stefanregen]

The delay is not progressive, to you it appear like progressive.

It is the result of audio timeline. Each individual MP4 has different lengths for audio and video, because of the different lengths of the audio and video units (the AC3 frame is not an integer (sub)multiple of the video GOP). These differences will accumulate step by step up to the end of the movie.

The only solution to this is to use a two track video editor and place each MP4 alternatively in the timeline and let them overlap a bit (one frame or the next GOP or next scene, as you like). The audio will be re-rendered accordingly.
This sounds logical, but the result of the Avidemux join has no delay and if I create a m2ts file from this join with tsRmuxer there is no delay as well.
And: if I disable everything from Nvidea except displaydrivers the delay is much less (see the edit...)
And: If I use tsmuxer with my old PC with a Radeon card there is no delay as well...
That´s why I think that such a high delay (~0,6 sec) is caused by some Nvidea incompatibility issues with tsmuxer.
Anyhow your second answer is much more intresting than your first....thank´s a lot

[sneaker_ger]

tsmuxer does not use the GPU in any way.

There are video and/or audio gaps at the connection points between the 13 original mp4s. In AviDemux' output these may have been handled in a suitable container (mp4/mkv) while tsmuxer loses these information. Proper way is to get rid of all the gaps by cutting and re-encoding the audio.

[Ghitulescu]

Proper way is to get rid of all the gaps by cutting and re-encoding the audio.

This is why I suggested a video editor, for it's difficult, at least for me, to edit the audio track of a video without the video.

[sneaker_ger]

Well, there are ways of doing it without manually cutting. For example in AviSynth. If I open such an appended file with audio gaps using ffaudiosource() it will automatically fill audio gaps with silence. With a mix of video and audio gaps it is more complicated but you could use Trim(0,0) on all files and then append and encode them. ffmpeg itself can also do this but I'm too lazy to search for the command right now. As always: all roads lead to Rome.

[JeanMarc]

My situation was a little different, and this solution might not be applicable here, but might still shed some light on how tsmuxer can generate this audio delay.

I was frustrated by the same issue: a progressive audio delay that could reach 20 seconds at the end of 2 hour movie.
The files I was using seemed well synchronized, but as soon as tsmuxer or multiavchd was muxing them into m2ts, the audio sync issue would be there.

I finally found that my original file didn't have a stable frame rate. The players were able to maintain the synchronization, but not tsmuxer. Apparently, tsmuxer doesn't behave like a regular player, and loses the audio-video sync information. It muxes the video at the (inaccurate) video frame rate, and the audio at the nominal frame rate. Since they are different a delay is generated.

My solution was to change my ffmpeg encoding. I was using the -r option to set the frame rate, which apparently doesn't produce a very reliable frame rate. I changed that to use the fps filter, which sets a perfectly constant frame rate.

More generally, my advice would be to run an ffmpeg command that would set a constant frame rate with the fps filter. This has solved the problem for me.

[Emulgator]

More generally, my advice would be to run an ffmpeg command that would set a constant frame rate with the fps filter.
This has solved the problem for me.
Second that, just had an occasion where not forcing fps=25 in an x264 encode
from a Blackmagic .avi v210 capture would lead to different video/audio lengths after .mp4 muxing.
mediainfo reported 25.000fps for the capture. ffmpeg reported 250000/10053fps for the encoder input. Shoot.