Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
3rd October 2016, 14:40 | #1 | Link |
Registered User
Join Date: Sep 2016
Posts: 4
|
tsmuxer audio delay
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... Last edited by stefanregen; 5th October 2016 at 10:24. |
5th October 2016, 08:58 | #5 | Link | |
Registered User
Join Date: Sep 2016
Posts: 4
|
Quote:
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) |
|
5th October 2016, 11:09 | #6 | Link |
Registered User
Join Date: Mar 2009
Location: Germany
Posts: 5,769
|
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.
__________________
Born in the USB (not USA) |
5th October 2016, 11:14 | #7 | Link | |
Registered User
Join Date: Mar 2009
Location: Germany
Posts: 5,769
|
Quote:
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.
__________________
Born in the USB (not USA) |
|
5th October 2016, 12:16 | #8 | Link | |
Registered User
Join Date: Sep 2016
Posts: 4
|
Quote:
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 Last edited by stefanregen; 5th October 2016 at 12:23. |
|
5th October 2016, 13:02 | #9 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
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. |
5th October 2016, 13:28 | #11 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
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.
Last edited by sneaker_ger; 5th October 2016 at 13:32. |
6th August 2018, 15:50 | #12 | Link |
Registered User
Join Date: Aug 2006
Location: USA
Posts: 59
|
tsmuxer audio delay
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. |
16th August 2018, 00:15 | #13 | Link | |
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,545
|
Quote:
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.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|