[MPlayer-dev-eng] DVB-TS and ATSC-TS Differences

[Nico]

James Courtier-Dutton wrote:

> Greg Herlein wrote:
>
>> It's come to light in my work on transport streams this week that
>> DVB-formatted streams (prevalent in Europe and on many satellites
>> here in the US) have subtle differences from ATSC-formatted
>> streams (prevalent here in the US for digital broadcasting,
>> especially the free to air terrestial).
>>
>> Specifically, the mapping of AC3 audio is done in 'PES private
>> streams' in DVB where it's has a mandated stream type of 0x06.
>> In ATSC it has to be set to a stream type of 0x81 and is a normal
>> audio PES stream.
>>
>> Reference:
>>
>> http://www.atsc.org/standards/a_52a.pdf
>> (see pages 118-127)
>>
>> There must be other differences as well.  Does anyone know of a
>> definitive paper or document that details all these?  If not, is
>> anyone willing to help produce such a document?
>>
>> Thanks!
>>
>> Greg
>>
> I have also done a lot of research on transport streams, and you are 
> correct in your findings.
> The most annoying problem I have found it identifying the contents of 
> the private stream. As it can be AC3 audio or Subtitles/Teletext.

so in ATSC subs are encapsulated in 0xbd PES streams? I wonder why 
people have so little fantasy :(  with
all the numbers they can choose from ...

> The start of a PES pack does not always match the start of an AC3 frame.
> When using some cheap DVB cards, only the Video and Audio PID is 
> received. The DVB card filters out the PAT and PMT, so the stream 
> being played has lost descriptive information. If people have recorded 
> that stream, and saved it to hard disc, that PAT/PMT information will 
> be lost forever.


usually cheap DVB cards ( = budget cards) can dump even the whole TS if 
you want, so they filter what the application
tells them to filter; it's possible to instruct mplayer  to include PAT 
and PMT in the stream, it's not a huge work
(I was planning to do it anyway)

> The only way of sorting out this problem I have found is for the 
> demuxer to do AC3 based CRC checks to see if valid AC3 frames are 
> arriving in this PID, and only then send the frames to the AC3 
> decoder. This does require the demuxer to do AC3 specific checks, but 
> I find that it is the only reliable method for handling this.
>
> Cheers
> James
>

and if AC3 frames are broken or if they don't pass  CRC even when they 
are correct (not so uncommon in TS) ?