Bad AC3 sound when converting from PS to TS

[Florisel]

Hi everybody,

I am currently writing a tool, which converts program stream to transport stream. The conversion for MPEG2 video programs with MPEG1/2 sound works good, however I am experiencing problems with the streams with AC3 sound. When converted and played back, audio decoder reports missing frames and synwords, which are probably result of some missing or incorrectly packetized audio data. I have spent a lot of time already on this issue but so far I could not find what the problem is and what to ask guru's on this forum for help.
I have uploaded to RapidShare two samples, which I work with:
- one is the original program stream file, which plays correctly
http://rapidshare.com/files/50762719/ZDF_AC3.mpg.html
- one converted transport stream file (from the previously mentioned program stream file), which plays incorrectly
http://rapidshare.com/files/50762888/ZDF_AC3.ts.html

Can someone have a look at these two files and help me to understand what the problem is?

Big thanks in advance.

[Guest]

I'd rather inspect your source code to find the error.

Have you looked at the source code of existing tools that can extract AC3 audio, such as DGIndex?

[Florisel]

neuron2,

Thanks for the info. I will look at the source code of DGIndex. I have not done it yet as I am mainly using the standard(s) to write the tool. And it has worked so far, but this AC3 sound really drives me crazy.
It is some very small aspect of how AC3 PES should be packetized into transport stream packets. The packetizing routine is the same for all types of PES - video and audio, MPEG-1, 2 and it works everywhere except for AC3 sound.

[Guest]

So you're saying that the demuxed AC3 data is OK but it goes bad when you mux it into transport? How do you know that?

[Florisel]

I have both streams - original program stream and the transport stream, which I make myself from the program stream. The program stream plays good - no interruptions, distortions, error messages in VLC. But from the transport stream only video can be played and AC3 audio produces error messages in VLC - about missing synwords and time-stamps. These errors mean that audio PES is not packetized correctly - e.g. demux takes some extra bytes or cuts the packets, but I could not find so far where the problem is.
I will look at the DGIndex to understand if there are certain details, which I do not know, on how AC3 sound is demuxed.
To add to the story - the program stream, which I use, is produced by MyTheatre program (if you know what it is). I take it from one of the filters and it comes to me in the form of program stream packs. I have also started suspecting that these packs are not good in some aspect, but could not prove it yet.

[Guest]

Can you send me a captured PES stream? I can test it and let you know if it is good (I have PES players at work). You really need to localize the problem first. As you say, it may not be your code at all.

[Florisel]

I will send the stream to you a bit later today. Thanks a lot for your help.

[Florisel]

Could not find your e-mail (sorry). Attaching the captured AC3 PES to this message.

[Guest]

I'll try it but just out of curiosity, if it is AC3 why does it have an extension MPA?

[Guest]

I just played it as AC3 PES and it's recognizable as audio but there is a lot of missing data. I suppose your PES is not being delivered properly.

[Florisel]

I do not know to be honest what type the files with PES should have and mpa was the very first thing that came to my mind :)

The file, which I have attached, contains indeed only audio program packs. I have skipped all video packs and program stream pack header. If you need them as well I can make a complete program stream (well, not really complete, because I do not have Program Stream Map. But I do not need it for my task because I have this information from other sources).

But apart from other program stream packs, are there any other data missing in the AC3 packs themselves?

[Florisel]

Fixed it!
Thanks enormously for DGIndex with the source code. I could step through Audio demuxing process with the debugger and it appeared that MyTheatre adds 4 extra bytes between PES pack header and actual pack data. I do not know what these bytes are as they are not present in the standard. Here is the memory dump of the beginning of three consequitive AC3 PES packs:
0x004CAA4E 00 00 01 bd 07 ec 80 80 05 21 00 01 81 4b 80 02 00 01 .....쀀.!...K€...
0x004CAA60 0b 77 a1 07 1c 30 43 7f 70 80 01 00 00 7e fb eb 86 0e .w¡..0C.p€...~ûë..

0x004CAA4E 00 00 01 bd 07 ec 80 80 05 21 00 01 ae 4b 80 01 04 21 .....쀀.!..®K€..!
0x004CAA60 b0 45 15 27 76 e7 bc 69 3b fd 7b ad 02 e1 ac a0 6b ab °E.'vç.i;ý{*.ᬠk«

0x004CAA4E 00 00 01 bd 07 ec 80 80 05 21 00 01 c4 cb 80 01 02 41 .....쀀.!..ÄË€..A
0x004CAA60 d4 fb ef e0 b9 35 ca 16 f3 d3 37 c9 74 6b 05 8b 42 eb Ôûïà.5Ê.óÓ7Étk..Bë

These bytes look like memory pointer or flags of some kind. Anyway, I have extended the PES pack header length by 4 bytes and the problem was fixed!

Big thanks again for your help.

[Guest]

Good detective work there! Saved me from having to look at the data, which I was planning to do today. :)

[Florisel]

Do you know by any chance what these 4 bytes mean? Do they remind you something? I have noticed that first byte is always 0x80, the second one can be either 01 or 02. The 3rd and 4th bytes have also limited number of values.
I feel just a bit uncomfortable not knowing what these bytes exactly are...

[Guest]

That's the audio substream header!

For your first frame:

80: AC3 substream ID (audio stream 0 = track 1, could be 80-87 for a DVD)

02: packet contains the beginning of two audio frames

00 01: offset from the second byte of this field to the start of the audio frame referred to by the PTS (the first one).

0b 77: AC3 sync word

You can find information about this from mpucoder.com. I believe he sometimes gives a free access to open source developers. Otherwise it is $5 to access his information, which includes detailed information on audio substream headers and other useful stuff.

[Florisel]

Right :)
Do I understand it correctly that this audio substream header is mandatory for DVD streams and not present in transport streams?
I think I can also rely that it is always 4 bytes long, can't I?

[Guest]

Yes, always present in DVD and never in transport. But also, some program streams not from DVD may omit it. For example, mpg's captured by Dvico Fusion cards omit it. That's the reason for the Force Fusion Audio option in DGIndex. I couldn't find a relaible way to detect it automatically. :(

When present it is always 4 bytes long.

[Guest]

Here's an old thread of interest:

http://forum.doom9.org/showthread.php?t=101507