[RESOLVED] Asynchronous H.264/AC3 output with erroneous TS recordings when using DGDecNV

[illCP]

Hi,

I have a problem concerning erroneous TS recordings - first of all some background information:

I'm using TSDoctor to cut recordings from a yaVDR and remove streams I don't need (e.g. subtitles, additional audio streams etc.). For several reasons I reencode my recordings with x264, using the original AC3 audio stream. To automate this I wrote a PHP script that does the following:

- calling DGIndexNV (2048) for parsing/indexing the TS file and demuxing the AC3-Stream

- calling TSDoctor to parse/check it again, getting a logfile with the delay for the audio stream, which I need for muxing later (here's problem 1: The delay DGIndexNV adds to the AC3 filename is usually (not always, but most of the time) wrong, e.g. DGI says -68 ms, TSDoctor 27 ms, when testing those values later it turns out TSDoctor's value is the right one - but as I have a workaround, that's not a huge problem)

- creating an AviSynth script and building commandlines for x264 and MKVToolNix, the latter for muxing the newly created .264 video with the original AC3 file demuxed by DGI


So all I have to do is put files to a specified input folder, start a batch, wait until DGIndexNV and TSDoctor are done and start a newly created batch which will encode and mux everything, so I get reencoded MKVs in a specified output directory afterwards.

This works pretty well - unless there are errors in the stream. After an erroneous part the resulting MKV will become asynchronous.

The thing is: the initial errornous TS will play fine in MPC-HC and VLC - with a lot of artifacts and errors at the broken part of course, but synchronous afterwards. I asked in the German TSDoctor forums and got the suggestion to try Handbrake instead of my DGI-/AviSynth-/x264-combination, and indeed, the resulting H.264 AVC MKV is still synchronous after the broken part.

So other decoders seem to be able to resync audio and video just fine, or respectively deliver just the right amount of black or garbage frames to keep audio and video in sync. It looks like DGDecNV decodes a couple of frames less and/or isn't able to resync everything properly after an error in the stream. The problem is that I don't want to use anything else - DGDecNV is pretty perfect apart from this problem; the last time I checked it was the only decoder to safely use as an AviSynth source that could handle e.g. MBAFF properly.

Any suggestions on that? I could provide some test files if necessary.

Thanks in advance!


// EDIT:

Until a couple of weeks ago it helped to do a "Quick Stream Fix" on the TS file with VideoReDo - for some reason this doesn't work anymore, there were a couple of updates for VideoReDo and TSDoctor. I also tried remuxing the TS with pretty much every tool I could find (TsRemux, tsMuxeR, ffmpeg...), that didn't help either.

[admin]

here's problem 1: The delay DGIndexNV adds to the AC3 filename is usually (not always, but most of the time) wrong, e.g. DGI says -68 ms, TSDoctor 27 ms

The delay is correct if you use the AVS script to serve the video AND you use the audio as demuxed by DGIndexNV. If you modify things using some other tools, then you render that stated delay invalid. If you can demonstrate a wrong delay without any other tool doing any extra processing that changes the served video or the demuxed audio, I will be willing to look at it.

The thing is: the initial errornous TS will play fine in MPC-HC and VLC - with a lot of artifacts and errors at the broken part of course, but synchronous afterwards. I asked in the German TSDoctor forums and got the suggestion to try Handbrake instead of my DGI-/AviSynth-/x264-combination, and indeed, the resulting H.264 AVC MKV is still synchronous after the broken part.

So other decoders seem to be able to resync audio and video just fine, or respectively deliver just the right amount of black or garbage frames to keep audio and video in sync.

Players have access to the PTS timestamps at the TS container level, so they are always able to present the audio and video in sync, even after stream errors. But source filters have to demux and decode the video and present it through a script as decompressed video without any timestamps because they are lost when the video is removed from the TS container. The demuxed audio also loses its timestamps. After the demuxing you can align things properly at the start of the streams using the reported delay value, but any losses can throw things out of sync. There is nothing DGDecNV can do about this.

Until a couple of weeks ago it helped to do a "Quick Stream Fix" on the TS file with VideoReDo - for some reason this doesn't work anymore, there were a couple of updates for VideoReDo and TSDoctor.

Other than solving your capture problem so that you don't get these errors, this is your best bet, i.e., fixing the TS before processing with DGDecNV. I would try to find out why the stream fix is no longer working.

[illCP]

Thanks for the quick response!

The delay is correct if you use the AVS script to serve the video AND you use the audio as demuxed by DGIndexNV.

That's pretty much what I do. Example:

Code: Select all

"C:\path\to\DGIndex.exe" -i "X:\path\to\input.ts" -o "X:\path\to\input.dgi" -a -e -h

to create a .dgi and demux an .ac3 file.

Then I create my AviSynth script:

Code: Select all

DGSource("X:\path\to\input.dgi")

Then I encode and mux:

Code: Select all

"C:\path\to\x264.exe" --preset fast --crf 18 --sar 1:1 --threads auto --thread-input --fps 25 -o "X:\path\to\output.264" "X:\path\to\input.avs" 

Code: Select all

"C:\path\to\mkvmerge.exe" -o "X:\\path\\to\\output.mkv"  "--forced-track" "0:no" "--default-duration" "0:25p" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "X:\\path\\to\\output.264" ")" "--language" "0:eng" "--sync" "0:42" "--track-name" "0:Dolby Digital 5.1 English" "--default-track" "0:yes" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "X:\\path\\to\\input PID 1519 3_2ch 48KHz 448Kbps DELAY 42ms.ac3" ")" "--track-order" "0:0,1:0"

DGI's input is a TS cutted and "repaired" by TSDoctor, so from the moment of DGI opening it there are only AviSynth (2.6.0 modified for MT and QTGMC (http://forum.doom9.org/showthread.php?t=156028) if that's important in any way), x264 and MKVToolNix involved. That's what you mean, right?

I just verified that again - I could provide a ~230 MB sample TS cutout, TSDoctor claiming a delay of 27 ms, DGIndex -68 ms. Encoding that and muxing two files with setting mkvmerge's "sync" to 27 respectively -68 for a comparison shows that 27 ms is the right value, -68 ms is noticeably off.

There is nothing DGDecNV can do about this.

OK, thanks for the explanation.

fixing the TS before processing with DGDecNV

That's actually what I expected TSDoctor to do, but as you said it's obvioulsy just correcting timestamps and not really removing the garbage. I remember e.g. ProjectX fixing broken MPEG-2 streams by dropping the complete faulty GOP, but I don't know if that would still work as easy for H.264. I asked that in TSDoctor's forum; it would be a nice addition.

Other than that I tried pretty much every tool I could think of that handles transport streams - nothing seems to be able to fix it in a way that it's not asynchronous after encoding and muxing.

Other than solving your capture problem so that you don't get these errors

I'm mostly recording British shows from Astra 28.5E - I'm living in Germany, and a couple of months ago someone decided to broadcast all the good stuff on that satellite (mostly the BBC HD channels) on a transponder with an UK spotbeam instead of the wider ranged beam they used before. Before that I got a really good and strong signal with my 80 cm multifeed dish, now some rainclouds and a bit of wind are enough to turn everything into digital garbage. To get a decent signal again I'd need to upgrade to a dish with a bigger diameter, about 150 cm and up - apart from dishes that size being awfully expensive, I don't really have a place to attach that in a way that avoids it being ripped from the roof by the next storm.

[admin]

Please give me a link to the sample stream you mentioned.

[Aleron Ives]

I've experienced similar problems, although I wouldn't necessarily fault DGDecNV for them. When your recording has signal errors, things get complicated, as it isn't possible to reconstruct every audio frame and video frame when the stream is corrupt. As Don said, a video player can use the timestamp information to automatically correct the sync after the signal returns, but if you're decoding both the audio and video linearly, then the only thing that matters if having the correct number of audio and video frames, so that both streams have the same length. If the numbers don't match, the audio will be too early or too late, depending upon whether the decoded stream has too many or too few video frames.

Since DGDecNV has no way of knowing what the missing data should have been, the only way to address the problem is to check the video manually, e.g. with VirtualDub to see how many video frames AviSynth thinks it has, as well as to check the audio with something like delaycut to see how many audio frames there are. If they don't match, you have to cut segments manually until their durations in milliseconds are as close as possible. The only way to avoid this hassle is to get a bigger and better antenna (or dish in your case) so that you never have signal dropouts. Clean streams are easier to process than dirty ones.

It becomes even worse when you want to edit out commercials, as video frames and Dolby Digital audio frames do not have the same duration in milliseconds, so you have to perform a great deal of calculations in order to prevent the audio from drifting further and further out of sync with every splice.

[illCP]

Please give me a link to the sample stream you mentioned.

I uploaded it and PMed you a link and login details.

[admin]

Thanks. That stream does not appear to include any of the disruptions you mentioned. Maybe you have another stream to give me for that?

Regarding the stream you provided. It includes at the beginning audio frames of different types. Maybe it is due to bad cutting at a commercial or something. But whatever the cause, this will cause undefined behavior for decoders. For example, if we do a straight demux of the AC3 audio, then nicAC3source() will not play it properly (only silence). But if you take that audio and use DelayCut to remove two leading frames, then the resulting fixed AC3 plays correctly with nicAC3source(). Also, DelayCut notifies about the changing parameters.

So you have a problematic stream. DGDecNV correctly reports the delay based on the timestamps, but DGDecNV cannot control how decoders are going to react when they encounter the audio parameter change. I can support you in this only if you provide clean source streams, without changes of audio format.

[illCP]

It includes at the beginning audio frames of different types. Maybe it is due to bad cutting at a commercial or something.

Thanks to that information I figured out what's going on with that (well, kind of at least...):

TSDoctor has an (unfortunately not really documented) option "Add AC3 5.1 frames if necessary" - I'm not quite sure if I activated that at some point or if it's active by default. Until now I thought it was solely for fixing AC3 changes in the stream (e.g. from commercial breaks as you mentioned), but obviously it adds frames to the start of every cut, even if there are no obvious changes/problems at all. In that context I found some other people complaining that this breaks something for them.

I switched it off and tested several cuts: Now TSD and DGI always agree on the delay, so that's sorted out, thank you!

That stream does not appear to include any of the disruptions you mentioned. Maybe you have another stream to give me for that?

Just so there are no misunderstandings, I think I didn't make that clear enough: The problem with the delay happend with nearly all streams, not just faulty ones, but thanks to you that's fixed now.

As you explained there's probably no way of doing something about the sync problem with disrupted streams, however if you still want to look into one:

Until a couple of weeks ago it helped to do a "Quick Stream Fix" on the TS file with VideoReDo - for some reason this doesn't work anymore

I stand (partly) corrected: After some more testing I discovered that it will in fact still fix most errors to keep it in sync when using DGDecNV, the problem appears with just two recent recordings in particular.

I uploaded a part of one of them - the error appears at 1:05, before that everything is perfectly synced, after that there's a (slight, but annoying) delay. As mentioned Handbrake (using ffmpeg as decoder as far as I know?) does keep that in sync (using AC3 passthru).

[BarryW]

These suggestions are a bit of a bodge.

In the final encoded and muxed file (MP4 or MKV) try hitting the 'J' and 'K' keys in VLC to adjust the audio delay by +/-50ms. Also the audio delay can be adjusted in MPC-HC.

Once the position of the audio change is known (caused by missing frames) and the approximate delay needed to bring it back into sync you can use Audacity to insert blank audio where the audio went out-of-sync and re-mux this new audio file with the video and re-test. Sometimes you can use audio from previous or future frames to fill in where you've inserted the blank audio to disguise the edit. If you move audio forward in time (in Audacity) then check that the overall run-time is less than the video run-time. Each AC3 packet is worth 32ms so the audio correction is likely to be in multiples of 32ms unless the video is also damaged.

If you have multiple errors in the file then things can get complicated. If you have 2 captures of the same stream (from 2 independent capture systems) and you have the TSPE editor you could try the Frankencap method (glue 2 good bits of video together from 2 bad ones). The other option is the encode each of the good videos identically and append them together with mp4box or mkvmerge.

Broadcasters (BBC) sometimes switch from 2 channel AC3 to 6 channel AC3 on the fly. If the TS file is edited early then DGIndexNV only sees 2 channel audio at the start. You'll find that tracks 3,4,5,6 from the decoded AC3 file from DGIndexNV will be out-of-sync by about a second. Tracks 3,4,5,6 can be shifted in Audacity to bring them into sync with tracks 1 and 2.

[TCmullet]

Players have access to the PTS timestamps at the TS container level, so they are always able to present the audio and video in sync, even after stream errors. But source filters have to demux and decode the video and present it through a script as decompressed video without any timestamps because they are lost when the video is removed from the TS container. The demuxed audio also loses its timestamps. After the demuxing you can align things properly at the start of the streams using the reported delay value, but any losses can throw things out of sync. There is nothing DGDecNV can do about this.

This speaks to me as a sore spot. The last poster mentioned BBC as switching audio formats. This is not limited to the BBC. ALL TV stations seem to do this! But it probably isn't a function of the network. They simply send down the line WHATEVER audio format a sponsor's spot was made with.

I've been aware of presentation timestamps, at least to some degree, for some time. This is why I wish DG software was working directly with the multiplexed streams (like AVISource) so that the stamps can be honored and audio can stay with the right video frames "transparently". I agree that the editor (me) should take care to edit OUT all sections not containing the main audio format.

Mixed audio formats are here forever. I cannot edit them out with other tools (in some cases). I specifically wanted DGDec for the main purpose of editing out sections, albeit I was not thinking of audio format changes. Any advice??? Am struggling with a bad "format changing" program, and anticipate many more to come.

[admin]

DGDecNV is what it is. I designed it for DVD and bluray sources. Yes, it can often be used for other use cases, but in such instances as you cite, you may have to resort to 3rd-party SW, such as TS Doctor or VideoRedo, etc., to do the pre-cutting/editing. You could also consider using EAC3TO for the audio demuxing; it may be able to fix these problems IIRC. I have no plans to support dynamic audio/video formats. And I'm happy now just to provide a robust frame-accurate video decoder/server, which happens to do audio demuxing as a bonus. I'm not interested in developing any kind of player application or remuxer, and I am limited by what Avisynth supports.

[TCmullet]

Mixed audio formats are here forever. I cannot edit them out with other tools (in some cases). I specifically wanted DGDec for the main purpose of editing out sections (via AVISynth), albeit I was not thinking of audio format changes. Any advice??? Am struggling with a bad "format changing" video program, and anticipate many more to come.

There is an indirect solution, apparently and obviously identified by the makers of capture cards (Hauppauge, in this case). They provide an option to "Disable HDMI AC3 support". Me and a buddy record a lot of programs jointly for a project. He uses the PVR2 (which is USB-based) and I use the Colossus-I PCIe card (but i have PVR2 also). We both now agree that for our purposes, we do not need AC3 audio. So we always "Disable HDMI AC3 support" with the result that we are given a file (M2TS) with an audio stream in AAC THROUGHOUT it. This prevents ALL audio format changes! DGDec doesn't process AAC (though the indexing extracts it nicely), but a free AAC to WAV tool creates the wave file which wavsource() works fine with. Problem solved!

In rare cases, outside of the above implied project, I MAY change it back to NOT disable AC3. But it those cases, I carefully do editing (Avidemux) before any DGDec) to cleanly remove all commercials and their deviant audio format changes.

Thanks again for this very good tool!

[admin]

That's very interesting, TCmullet, thanks for sharing that with us. I've always used the audio RCA jacks for my audio input, which gives me AAC throughout as you mentioned, so I never ran into the AC3 format change problem with my Colossus. I wasn't using HDMI due to HDCP problems with the video when trying to record from my cable box.