Problem with audio sync when re-compresssing H.264 ts files from DVB-T broadcasts

[lchiu7]

Our local broadcaster is now broadcasting H.264 video with AC-3 audio over DVB-T. I have been able to capture these with a Hauppauage HVR-900H USB2 tuner.

The captured files (.ts format) play fine. But I want to edit out commercials and compress a bit since one hour is 4.3G and even with ads out the program is still 3.7G.

I tried the following process.

1. Edited the ads out using TS Packet Editor - that seemed to work
2. Demuxed the video and audio using TS Converter
3. Used X264 to recompress the video at a lower bit rate

This all worked fine

THen I tried to use MKVMerge to put the x.264 file and demuxed AC-3 file into a MKV container. While it worked, MKVMerge complained about extraneous bytes in the AC-3 and that audio/video synchronisation would be lost. True enough, the resulting file has lost audio/video sync but the original cut file played fine.

Also tried using DGAVCIndex to demux the AC-3 and while the AC_3 audio extracts fine, the same error occurs when muxing it back. DGAVCIndex does produce a file with a name like

CSI New York HD 19a 3_2ch 384Kbps DELAY 44379ms.ac3 so I am wondering if it has detected a delay in the audio which I am supposed to take into account somewhere when muxing it back but I can't see any parameters in MKVMerge where you set a delay.

Any ideas appreciated. Thanks

Larry

[Atak_Snajpera]

Use h264tscutter. Always cut at IDR-Frames! Demux audio using eac3to or if you want to save some time use RipBot264

[lchiu7]

Thanks. I had tried that first and had no preview image so moved to TSPacket Editor. When it also had no preview figured I needed the Haali Media splitter and installed it. When the preview returned I didn't bother going back to H264TSCutter.

Went back to it - preview no appears and was able to cut the file fine. But after recompressing the file using x264 and using the extracted AC-3 audio file, still get loss of sync. But it occurs slowy over the length of the video so I can't adjust it. Will now try the eac3to tool to extract the audio.

Update:

Tried to extract the AC-3 audio using eac3to but it complains cannot determine the format of the source file cannot be detected. This is a standard ts file captured from DVB-T containing AVC video and AC-3 audio.

[Atak_Snajpera]

how did you recompress video? Via DGAVCDec or DirectShowSource?
But it occurs slowy over the length of the video so I can't adjust it. Will now try the eac3to tool to extract the audio.
I assume wrong frame rate

[lchiu7]

how did you recompress video? Via DGAVCDec or DirectShowSource?

I assume wrong frame rate

Compressing via x264 and directshow. The avisynth script has
directShowSource("CSI New York HD.ts")

I thought it might be frame rate also. But checked with Mediainfo and it shows 25fps (which is correct for broadcasts in our neck of the woods). And the avisynth script doesn't change the fps at all

[Atak_Snajpera]

try with DGAVCDec

[lchiu7]

try with DGAVCDec


I have tried that. This is the situation. If I check the original ts file with mediainfo it shows the duration as 1h3s.

If I extract the audio using various means including DGAVCDec the audio shows up as being 59m59s long. So for some reason once the audio is extracted it goes out of sync. That's really puzzling as you can imagine. I can't see how that is a frame rate issue since the original ts file plays in sync fine.

[Atak_Snajpera]

Try to demux audio via TSMuxer , TSRemux or xport

[lchiu7]

Tried them all with the same result. But tsmuxer gives the following error messages

SmartLabs tsMuxeR. Version 1.8.4(b) http://www.smlabs.net
Decoding AC3 stream (track 1): Bitrate: 384Kbps Sample Rate: 48KHz Channels: 6
AC3 bad frame detected. Resync stream.
Decoding AC3 stream (track 1): Bitrate: 384Kbps Sample Rate: 48KHz Channels: 6
AC3 bad frame detected. Resync stream.
Decoding AC3 stream (track 1): Bitrate: 384Kbps Sample Rate: 48KHz Channels: 6
AC3 bad frame detected. Resync stream.
Decoding AC3 stream (track 1): Bitrate: 384Kbps Sample Rate: 48KHz Channels: 6
...
Demux complete.
Demuxing time: 2 min 13 sec

I wonder if the original has bad audio (plays fine although) and in demuxing some of the data is thrown away which causes synchronisation to be lost

[Atak_Snajpera]

What happens if encode audio directly from .ts to AC3 and then you mux into mkv?

[lchiu7]

What happens if encode audio directly from .ts to AC3 and then you mux into mkv?

Thanks for the help. I think I have sort of solved the problem. Turns out it was with the file, not the process. I tried all the methods suggested with a different captured file and it works fine - there are no bad frames etc. And when muxed back the audio and video stay in sync.

Out of interest, how to you encode audio directly from .ts to AC3? I could never get eac3to to work so don't know what other program I can use to extract the AC-3 directly. It's clear that the tools that extract the AC-3 track (DGAVCDEC, TSRemuxer, etc.) all complain when they find errors in the extracted files and drop bad bytes. Yet the original file plays fine in sync which is strange.

[Atak_Snajpera]

DirectShowSource("vide.ts",video=false)

[lchiu7]

Wasn't sure how to use that - use DS to extract the audio but with what tool?

Anyway I think I have found the problem. Viewed an original broadcast all the way through and noticed part way through there was a burst of loud static as if the AC-3 signal got dropped and recovered. Of course after I demuxed the video file, compressed it with x264 and tried to mux it back MKVMerge encountered this static burst in the audio and rejected it, thus causing random loss of synchronisation in the output file.

Out of interest tried out Ripbot264 instead. While not quite the same level of control I did the following:

1. demuxed the audio using DGAVCindex
2. Fed the original ts file into ripbot264
3. Fed the demuxed audio into ripbot264
4. Chose MKV container and original audio

Initial tests with the same file seem to indicate that Ripbot264 doesn't not throw away any of the data in the audio track and the output mkv file appears to be still in sync.