[mythtv] AC3 + bigdvb3.5 + australia + transport.c

Mark Anderson markjanderson at mail.com
Tue Jan 11 17:15:28 EST 2005


After a number of hours starting at hex dumps and trying to learn a bit about 
mpeg/dvb protocols I have finally found the problem with transport.c, 
unfortunately I haven't been able to craft some code that actually fixes it.

The problem: The 9th byte of the mpeg2 data is the header length, in australia 
for AC3 payload this is always set to 7 bytes. The code in transport.c only 
ever puts 4 of the 7 bytes into the transformed stream. mpeg.c looks at the 
header length and makes sure it pulls out that many bytes:

The code in mpegps_read_pes_header is:

    len -= header_len;
        while (header_len > 0) {

Because transform has not put the last three bytes of the header in, mpeg.c 
pulls out the wrong bytes and everything goes downhill from there. I have 
confirmed that if transport puts the full 7 bytes in the it all works fine.

I added the following code to write_ipack in transport.c to try to fix this:

 /*write in the rest of the header as specified by p->hlength*/
        if ((p->cid == PRIVATE_STREAM1) && (p->count == 13))
                while (p->count < (p->hlength + 9))
                        p->buf[p->count++] = data[p->count - 13];

This almost does it except there are 3 additonal bytes after the four byte 
streamid/ac3_off header. If I hack mpeg.c to pull the extras out it produces 
perfect audio. The reason the extra three bytes are added due to the above 
code is that it adds the reast of the header, but since write_ipack has no 
way of telling the caller that it has used up some bytes out of its source 
buffer, the bytes are re-added in the next call to write_ipack.

Marcus, since you are much more familiar with this code, maybe you could work 
out how to get the proper header bytes added?

Mark Anderson

More information about the mythtv-dev mailing list