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

[James Courtier-Dutton]

Nico wrote:
> 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)

I was think more for people who have just recorded from the DVB directly
to their hard disc, and failed to include the PAT and PMT PIDs.
It happens a lot at the moment.

> 
>> 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) ?
> 
CRC in AC3 is not optional. It has to be there and be correct, or else
the decoder will not play it. A hardware AC3 decoder will mute if it
receives an AC3 frame without a valid CRC.
Any software AC3 decoder should do the same.

I have never seen a correct AC3 frame that does not have a valid CRC.

Cheers
James