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
