[opendtv] Re: Superbowl XL(1080)I
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 7 Feb 2007 16:33:10 -0800
Ron;
I'm sure you meant PMT and not PAT, since no descriptors appear in the PAT.
Table 6.25a in A/65c shows that the RC, if present, must appear in Event
Information tables and the Program Map table.
Here's the exact language from section 6.9.12:
"For terrestrial broadcast transport, the rc_descriptor(), when transmitted,
shall be present in both
the EIT and TS_program_map_section(). For cable transport, the
rc_descriptor(), when transmitted, shall
be present in the TS_program_map_section(), and, when the EIT is carried, in
the EIT."
One can infer from the following paragraph that the primary location is the
PMT and also shall appear in the EIT-0. If valid for a future event, it
should be placed in EITs as far in advance as possible. That means changing
PMTs a bit more often than otherwise necessary, at least if one event is
subject to the RC and the following event isn't.
And, everybody thinks that making a PSIP generator is easy. Since there's
an awful lot of legacy equipment out there, sometimes the only reasonable
approach is for the PSIP generator to also generate PSI.
John
_____
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Ron Economos
Sent: Wednesday, February 07, 2007 3:58 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: Superbowl XL(1080)I
Is the RC descriptor valid if it only appears
in the PAT and not in the PSIP?
Ron
John Willkie wrote:
John;
Null packets are what encoders provide when there is no other data to send.
If the total data rate is more than 19.39 mb/sec, then you've got a problem.
There has to be a setting on the encoder or mux to specify the maximum
output bit rate and whether to furnish null packets to pad out that bit
rate, which is generally what one wants to do.
Video bps + audio bps + psip/psi bps + null packets bps = total bit rate
(assuming no packetized data streams)
I don't see any issue with bit rate in this sample. The mux rate is 19.39,
there are no CRC-32 errors, no continuity_counter errors. If there were too
many bits per second, these would signal it.
I do wonder why the image looks to be 4:3, since HD video by definition is
16:9.
Notice the redistribution control (rc) on the video?
Hth
John Willkie
EtherGuide Systems
Other related posts: