[opendtv] FW: Re: Superbowl XL(1080)I
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 8 Feb 2007 11:32:29 -0800
It's a complicated question.
First, the rc_descriptor / broadcast flag, thanks to the appeals court
ruling, has no legal weight. Instead of locking redistribution in stb or
rcvr hardware, it merely signals that the content is not to be
redistributed.
The question is whether WCBS asserts the rc, and whether cable asserts rc
regardless of what the broadcaster does.
A/65 does specify that if EITs are carried by the cable system, that the rc
must be in the PMT and the EIT. Without seeing the descriptors in the EIT,
I can't go much further.
There is no legal requirement that the 1394 output be encrypted, so I'd
refine the question to be whether cable companies can restrict
redistribution control when broadcasters do not. I suspect not, but that
would require me to review the cable rules (which I need to do anyway for a
posting I've been pondering on my PSIP list.)
John Willkie
EtherGuide Systems
_____
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Ron Economos
Sent: Thursday, February 08, 2007 4:11 AM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: Superbowl XL(1080)I
Thanks John. And yes, I meant PMT. I believe if John
Meehan looks at the EIT's in his WCBS stream, he
will not find any rc_descriptors.
The reason I bring this up, is that it's come to
my attention (as a IEEE1394 developer) that
certain cable STB's with 1394 output now have
redistribution control implemented. That is, if
the STB detects the rc_descriptor in the PMT
only, it will encrypt it's 1394 output of that stream.
Aside from just being silly (since the same stream
can be captured in the clear with an ATSC capture
card or even a QAM capture card connected to the
cable), I wonder if this is legal?
Ron
John Willkie wrote:
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:
- » [opendtv] FW: Re: Superbowl XL(1080)I
