[mythtv] [Experimental PATCH] BIG DVB PATCH V3.2 Released

[Tj]

Marcus Metzler wrote:

>AC3 in an MPEG stream, either trnsport or program stream, is packaged
>in private stream 1 PES packets. Those start with 0x00 0x00 0x01 0xbd
>
>There are private streams for AC3, LPCM and DTS are defined by the DVD
>specifications. They call for an additional header inside the PES
>payload (not the PES header). For AC3 it is a for byte header
>containing the AC3 id (0x80 - 0x87), the number of AC3 frames in the
>payload ( 1 byte) and a two byte pointer pointing to the first frame
>in the payload.
>  
>
Damn. It's clearer after I looked at your email and look at code again. 
I'm sorta preparing for my holiday so I can't work on this anymore (and 
I got AC3 unorthodoxically working anyway).. :( I am getting long winded 
again.. :(

One more question, if you don't mind and have the time to teach me. 
Could there a spec diff as to how AC3 audio is "packaged" in ATSC and 
DVB? Or, as I begin to realise finally, my system is somehow  f**ked up 
and designed to torture/kill me?

in libs/libavformat/mpeg.c approx line: 1461 in function 
mpegps_read_pes_header does exactly what you mentioned.

    if (startcode == 0x1bd) {
        if (len < 1)
            goto redo;
        startcode = get_byte(&s->pb);
        len--;
        if (startcode >= 0x80 && startcode <= 0xbf) {
            // audio: skip header
            if (len < 3)
                goto redo;
            get_byte(&s->pb);
            get_byte(&s->pb);
            get_byte(&s->pb);
            len -= 3;
        }
    }

For my broadcasts, what immediately comes after 0x00 0x00 0x00 0xbd is 
not 0x80. It's some arbitary number which follows no apparant pattern to 
me..

There will be a problem for me if I call "startcode = get_byte 
(&s->pb)", decrement the len var and then realised I did not get the 
range I want. because at the end of this function, I assign pstart_code 
to whatever comes after 0x00 0x00 0x00 0xbd, which appears to be random 
(not tested throughly).

Everything else in myth expects a 0x80 after 0x00 0x00 0x00 0xbd, but my 
mythbox doesn't do that, causing mythfrontend to crash as it's not 
expecting that as a startcode.

Without seeing 0x80, I can't really be sure that the private stream I'm 
handling is actually AC3 rite? How save is it to skip this block of 
code? (as I am trying to figure how to prevent audio buffer underrun 
issues when I switch channels between different codecs)

Is this a computer hardware, TV antenna issue or software issue? Is this 
a bad packet caused by a faulty/lousy antenna?

I am having clear reception in all SDTV channels.. (HDTV video is 
breaking up occasionally).


Regards.