[RESOLVED] Bad delay values for audio demuxed from bluray with a range set

Support forum for DGDecNV
gonca
Moose Approved
Posts: 818
Joined: Sun Apr 08, 2012 6:12 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by gonca » Sat Jun 16, 2018 3:32 pm

The thd one, the first one
But it does it with any or all streams

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sat Jun 16, 2018 4:15 pm

Back from flying from tree to tree.

Something fishy going on. Investigating...

gonca
Moose Approved
Posts: 818
Joined: Sun Apr 08, 2012 6:12 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by gonca » Sat Jun 16, 2018 4:27 pm

Something fishy going on
Shouldn't that be
Something nutty going on

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sat Jun 16, 2018 4:45 pm

Something nutty going on
For sure.

I'm theorizing that the PCR is taking a jump but I have to verify it. I do have a foolproof way for you to get the right delay value but I don't want to tell you until I understand why DGIndexNV is not delivering that. :scratch: DGIndexNV assumes that the PCR is monotonic with no jumps. I do not think it is a simple sign change on the delay value.

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sun Jun 17, 2018 10:30 am

I'm going to first explain how to reliably get the correct audio delay, using gonca's case as an example. Then I am going to explain why DGIndexNV can't reliably determine it and what we might do about that.

Here is the process I followed. The main thing to note is that the detection of the delay is done by human perception and not any kind of automated heuristic. gonca, please follow this and report if you get the same results. I'm using 64 bit for everything here.

1. Using DGIndexNV demux the video and audio with the desired range. We'll ignore the reported delay in the audio file. If you need to re-encode the video, do so now and use that instead.

2. Using mkvtoolnix, mux the video and audio with delay 0 on both the video and audio tracks.

3. Load the MKV into VLC media player. Repeat play through a good section for assessing sync while using the j and k keys to adjust the sync (great feature of VLC). When you have good sync, write down the value displayed. For gonca's 00042.m2ts and the range given in his test.dgi, I obtained a value of -1550.

4. Using mkvtoolnix, again mux the video and audio with delay -1550 on the audio track. The resulting MKV will play in good sync. Note that the granularity of the VLC tweak is 50ms, so you may want to tweak it further if desired. Also, when I serve things through an Avisynth script, I also find that DelayAudio(-1.550) gives good sync.

Now, why can't DGIndexNV determine the correct value? First, be aware that this delay value reported in the filename is an old hack that derives from the days of DVD program streams (VOBs), where the things I list next were in most cases not applicable. Here are three ways things can go wrong for the delay heuristic (there may be more):

1. There can be (intentionally) missing audio. An instance of this is the case sometimes seen where there is some black video without audio at the start and then when the real content starts with both video and audio, we align the first audio PTS with the first video PTS (one of the black frames), which is wrong. Here is an example from gonca's case. Here is the beginning of the timestamp dump from the full M2TS (not the range):

Code: Select all

PCR1001 289144383 [10709 ms]
  V1011 PTS 1048560 [11650 ms]
  V1011 DTS 1044806 [11608 ms]
	[GOP started]
  V1011 PTS 1056067 [11734 ms]
  V1011 DTS 1048560 [11650 ms]
    A1100 PTS 1048560 [11650 ms]
    A1101 PTS 1048560 [11650 ms]
    A1102 PTS 1048560 [11650 ms]
    A1103 PTS 1048560 [11650 ms]
    A1104 PTS 1048560 [11650 ms]
As you can see, the first video and first audio PTSs are both 11650, so we would conclude that the delay is 0. Now here is a section later in the dump:

Code: Select all

V1011 PTS 1089851 [12109 ms]
  V1011 DTS 1078590 [11984 ms]
  V1011 PTS 1082343 [12026 ms]
PCR1001 301292097 [11158 ms]
  V1011 PTS 1086097 [12067 ms]
  V1011 PTS 1101112 [12234 ms]
  V1011 DTS 1089851 [12109 ms]
PCR1001 303722655 [11248 ms]
  V1011 PTS 1093605 [12151 ms]
  V1011 PTS 1097358 [12192 ms]
  V1011 PTS 1112373 [12359 ms]
  V1011 DTS 1101112 [12234 ms]
PCR1001 306152367 [11338 ms]
  V1011 PTS 1104866 [12276 ms]
  V1011 PTS 1108620 [12318 ms]
PCR1001 308582079 [11428 ms]
  V1011 PTS 1123635 [12484 ms]
  V1011 DTS 1112373 [12359 ms]
  V1011 PTS 1116127 [12401 ms]
PCR1001 311012637 [11518 ms]
  V1011 PTS 1119881 [12443 ms]
  V1011 PTS 1134896 [12609 ms]
  V1011 DTS 1123635 [12484 ms]
PCR1001 313443195 [11609 ms]
  V1011 PTS 1127388 [12526 ms]
    A1100 PTS 1077360 [11970 ms]
We are getting a bunch of video without any audio frames. This can happen because there really is no audio (as in the black frame case) or just because it is muxed without expected alignment (the audio is there but appears later in the stream; that's not a problem because of player buffering).

2. The timestamps can arbitrarily reset anywhere in the stream. That means the sync calculation can change and if we only do it at the start of the stream it may not be valid later in the stream.

3. The stream may have interpolated timestamps, i.e., there is not a transmitted PTS for every video frame. That means that when we see an audio PTS, the last video PTS we saw may be from many frames previously, instead of the last one before our audio PTS.

Now, what do we do about all this? My suggestion is to just ditch delay reporting in the filename for transport streams. We can keep it for program streams because they are usually VOBs where the heuristic is much more effective (although I would be happy to ditch it for everything). And of course add some good explanation in the user manual (or a new document) that explains how to achieve good audio sync for various use cases.

Your thoughts about this will be appreciated.

gonca
Moose Approved
Posts: 818
Joined: Sun Apr 08, 2012 6:12 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by gonca » Sun Jun 17, 2018 10:45 am

If I may, another approach
Index and demux from very beginning (start 0)
Do what has to be done (in my case encode)
Remux
Then use MKVToolNix to trim the beginning part
Only needs one quick index (on encoded file, which is quick) to obtain start point for range.

I am good with letting go of delay reporting for transport streams

P.S.
Delay reporting works great for MKV since that is one "big" file, no surprises

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sun Jun 17, 2018 10:50 am

Yes, that can be an alternative as long as you know that your file begins with 0 delay. Not everything does.

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sun Jun 17, 2018 10:59 am

gonca wrote:
Sun Jun 17, 2018 10:45 am
Delay reporting works great for MKV since that is one "big" file, no surprises
Yes, but it's valid only if the MKV file is in sync.

I'm probably going to ditch delay reporting for everything. I want people to use perceptual alignment, not a hacky heuristic with possibly invalid assumptions and prerequisites. Then I can't be blamed for audio desyncs. ;)

gonca
Moose Approved
Posts: 818
Joined: Sun Apr 08, 2012 6:12 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by gonca » Sun Jun 17, 2018 11:01 am

Good point
But at the beginning delay reporting is good, no range to bring up the weird stuff
Maybe leave delay reporting in with a note about it in the docs
EDIT
Just read your last post
Yeah, why shoot yourself in the foot?
Last edited by gonca on Sun Jun 17, 2018 11:02 am, edited 1 time in total.

User avatar
admin
Site Admin
Posts: 4408
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin » Sun Jun 17, 2018 11:02 am

Some files do not start with 0 delay! For example, off-air TS captures, or just trimmed TS files.

Someone will have to make a strong case to get me to keep any delay reporting at all. In the modern world there are just too many ways to go wrong with the old DVD-era heuristic. And what developer wouldn't want to simplify his code?

Post Reply