[MPlayer-dev-eng] DVB-TS and ATSC-TS Differences
Nico
nsabbi at tiscali.it
Fri Jan 30 09:00:34 CET 2004
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) ?
More information about the MPlayer-dev-eng
mailing list