5685:unnecessary audio-delay compensation become necessary

Discuss about generic usage of MediaCoder.

Moderator: HuggiL

Post Reply
kawamoto76
Advanced
Advanced
Posts: 480
Joined: Sun Dec 14, 2008 4:52 pm
Location: JAPAN

5685:unnecessary audio-delay compensation become necessary

Post by kawamoto76 » Wed Mar 11, 2015 2:42 am

AS I reported before(viewtopic.php?f=17&t=13188 , viewtopic.php?f=28&t=11125), when I would convert .ts(mpeg2/aac) into .m2ts(H.264/ac3) with x264/ffmpeg, bad audio-delay conpensation(this is unnecessary) seemes to be applied automatically when either MC R6-5160, R6-5166, R7-5170,5172,5175, R8-5180, 5182, 5185, R9-5191, 5192 or 5196 was used.
Fortunately, this issue had been fixed at MC R5-5158.
However, above issue re-appered in MC 0.8.3.5685.

In conversion procedure, MC creates .264 and .ac3, which will be muxed with TSmuxer.
If MC starts decoding of audio and video from the top of the file, and creates .264 and .ac3 independently without considering written timecodes synclonization in both(audio and video) packets, above audio-delay compensation might become effective.
However, as to TS input which has no header information, reported "audio-delay" merely represent the PTS defference between the first audio packets and the first video packet. Actual start timing of the conversion will be serched with scanning the several beginning packets. In this stage, audio decoding start point and video decoding start point having the same time stamps will be set for A/V sync.
Then, originaly, these .264 and .ac3 do not require the "audio-delay" compensation. And reported "audio-delay" value is not with standing the each decoding start point of audio and video.
Even if the "audio-delay" compensation method may be effective as to PS type input having information header, it is not necessary for TS type input, furthermore applying the compensation will give unnecesary harmful additional audio proceeding. With build 5158 in which this compensation is not applied, we can get the output with A/V sync, however we always get audio proceeded output with all versions after R6 up to R9 in which unnesessary "audio-delay" compensation is applied.
In 0.8.3.5685, above issue re-appered.
Akira Kawamoto

stanley
Site Admin
Site Admin
Posts: 4135
Joined: Mon May 15, 2006 7:43 pm
Location: Sydney

Re: 5685:unnecessary audio-delay compensation become necessa

Post by stanley » Fri Apr 10, 2015 11:12 pm

There is an option in settings->overall->audio for disabling audio delay compensation.
When things work together, things work.

kawamoto76
Advanced
Advanced
Posts: 480
Joined: Sun Dec 14, 2008 4:52 pm
Location: JAPAN

Re: 5685:unnecessary audio-delay compensation become necessa

Post by kawamoto76 » Sat Apr 25, 2015 1:46 am

The "audio delay" for TS file reported by Mediainfo represent the difference of PTSs of first apearred video packet and first appeared audio packets. For TS file captured from a stream, generally, it changes verious value depending on from when we atart capturing. From broadcasting demannds, video packets are always sent earlier than the corresponding(same PTS) audio packets. Therefore, we always get a TS file where audio packets are left in the biginning part, that have PTSs corresponding to cut-out(discarded) pre-going video packets. "audio delay" for TS never represents a difference between wrriten PTS values of video packets and those of audio packets defined from actual movie scean.
Assume we have a TS, there, video packet(PTS=0msec) is the top-leader of packets train, and the first appeared audio packet value is -500msec, and we would convert the TS into .m2ts(H264/ac3) under a setting(source/encoder/format = mencoder/x264/H264(video), ffmpeg/ffmpeg/ac3(audio). MC(MediaCoder) will make a .264 file for video and .ac3 file(s) for audio. After that, MC will mux .264 and .ac3(s) to give .m2ts.
If synchronized sampling of video and audio from input TS is done, resultant .264 will start at PTS=0msec, and .ac3 will start at PTS=0msec with discarding the pre-cursor packets. TSMuxer muxed product will have A/V sync.
On the other hands, if synchronized sampling were not employed, simply splitted A/V's each packets from packets train, the .264 would start from 0msec, and .ac3 would start from -500msec point. In muxed .m2ts would show a curious movie, audio is delayed 500msec than video, because the audio packet(original time= -500msec) is put on the video packet(time=0msec). It is expected that to get a product with A/V sync( to start .ac3 from 0msec), a compensation "audio delay" parameter(reported by MediaInfo) shoud be set. Sign(+-) would be determined by specificaion of used transcoding software.
In MC5712, a result is nether above case. For .264, it starts at 0msec with no problem, whereas .ac3 starts at 500msec(neither -500msec nor 0msec). I have a doubt that MC applies the unneceaary compensation when generating parameters for ffmpeg in his internal process. in addition, it is given contratictionally, whereas .ac3 never start at 500msec. Although MC5712 has such a problem, we can get A/V sync produvt .264(start=0msec) and .ac3(start=0msec) with setting (opposit sign) value(MediaInfo reported) into "audio delay" columb in "sound" Tab. Although, a result is the same as above un-synchronized sampling, the two have each different origins there "audio delay" compensation became necessary.
As descrived above, "audio delay" veries its value according to cut-out-points from the same original broad-casting stream. It is troublesome that we have to change "audio value" every time TS by TS even if a preset file is prepared. In several older versions of MC, "audio delay" compensation is not necessary(default=0msec) to get A/V sync. I hope this issue will be fixed soon.
I think, if original written PTS values on video packets and on audio pakets have a "audio delay" from some reason, "audio delay" sould be necessary to correct the miss-putted PTS. This case might be happen when we use miss-propagated input having file header where "audio delay" is written such as PS file(i.e. .mpg).
However, as to TS file, "audio delay" represents merely the time difference of each top cargo of video and that of audio in the packet train, as long as MC convers input with A/V sync, "audio delay" compensation should be unnecessary unless above mis-propagation happened on original broad-castiing stream.
Akira Kawamoto

kawamoto76
Advanced
Advanced
Posts: 480
Joined: Sun Dec 14, 2008 4:52 pm
Location: JAPAN

Re: 5685:unnecessary audio-delay compensation become necessa

Post by kawamoto76 » Sat Apr 25, 2015 4:57 pm

In far old versions of Mediacoder such as 0.7.0.4399, "audio-delay" compensation was not employed.
After some versions this compensation became capable.
I think automatic compensation using "audio-delay value of input file"(reported by MediaInfo) also became employed.

In MC-0.8.34.5712 by default,"settings" -> "over all" -> "audio" -> "use audio delay value of input file" is ON.
If defined T1 = "audio-dalay"(MediaInfo reports), T2 = user input "audio-delay"(Tab"sound" -> Columb"audio delay") , MC seems to apply audio delay compensation using (T1+T2). Therefore, when T1=(-)500msec, we can get A/V syng by setting T2=500msec((T1+T2)=0msec) to cancel unnecessarily applied automatic compensation(T1). Also, when I set "use audio delay value of input file" to OFF and the Columb input to 0msec, I can get A/V sync.

The fact I could get A/V sync with default in some older MC version, it can be thought MC's default setting of "use audio delay value of input file" was OFF.

For PS file input, default setting of "use audio delay value of input file" might be requested to ON.
However, for TS file input, default=OFF is convinient for a user.

I think this is a problem which (ON/OFF) Stanley adapts to the default .
I will be checking the default setting of "use audio delay value of input file" in future versions.
Akira Kawamoto

hhuey5
Amateur
Amateur
Posts: 18
Joined: Sun Nov 10, 2013 2:28 pm

Re: 5685:unnecessary audio-delay compensation become necessa

Post by hhuey5 » Thu Apr 30, 2015 2:59 am

@kawamoto76
I get a big headache trying to understand what bug is being reported here.
Too much detail that discards the point of the bug being reported.

As is prior to Build 5716

(1)

if the header of Audio properties reported Delay=-800ms
then I add Audio Delay = 800ms
result I get is AV in sync

which is an important trick prior to combining two AV files into one file w audio in sync

last build when this was working Build 5680

(2)
Another use of Audio Delay is when there is a need to create audio sync w video by user needs
ie:
if the header of Audio properties reported Delay=0ms then I add Audio Delay = 6000ms
then I get AV in sync for what I want it to do that has a delay of 6000ms

but the bug introduced in build 5716 cuts the audio out 6000ms too early instead of ending where it should
(this is reported in viewtopic.php?f=2&t=13461)

Given the bug in #2 it has introduced itself into #1 thereby defeating feature #1
Yes, there is a possibility of Audio cutting out 800ms too early at the end of track

I will therefore have to revert to build 5680 where I last know everything worked
I have no idea between build 5680 and 5716 as to when this new bug got started

I hope the change log of future builds will explain that this Audio Delay is fixed
Otherwise I will have to remain on Build 5680 to prevent further damages w future uses of mediacoder

This would prevent ppl that use Audio Delay from updating their builds

@kawamoto76 see please keep explanations simple

Post Reply