[opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media Center Play By?
- From: "Adam Goldberg" <adam_g@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 28 May 2008 12:58:20 -0400
> The bottom line in all of this is that the rc_descriptor is only a flag,
> and that its real function should be to alert the receiver to the
With respect, Bert, I think you're rewriting history. The rc_descriptor was
standardized in order to have a bit in the ATSC stream which indicates "do
what the FCC requires of you" and absence of which indicates "no need to do
it". It is only due to the way MPEG Transport Stream Descriptors work that
it has a length and optional data. Few have ever suggested what might go in
there, and post-BF-overturning, it is even less likely.
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Manfredi, Albert E
Sent: Wednesday, May 28, 2008 12:45 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media
Center Play By?
Craig Birkmaier wrote:
> If one were to examine the FCC ruling regarding the RE
> Descriptor they would find, as Adam correctly asserted,
> that the rules only require that the content be limited in
> redistribution - i.e. it is OK to copy the program with
> the RC Descriptor set. What the FCC was trying to require
> is that the bits be protected within the device that
> captured them, and that it not allow a copy to be made
> and distributed.
Yes, as far as that 2003 rule went. And there are some reasonable good
ways to do that in recording devices.
The bottom line in all of this is that the rc_descriptor is only a flag,
and that its real function should be to alert the receiver to the
presence of the associated redistribution control INFORMATION. In
principle, there could be up to 255 bytes of detailed instruction as to
what exact control should be exercised on redistribution of the content.
But none of that is used. The only feature exercised to date is this
binary function, rc_descriptor on/off, and 0 bytes of rc_information
("The descriptor_length may, in the future, have a value other than
0x00"). So in the absence of any legal definition, which the appeals
court threw out the window, the presence of that descriptor should mean
next to nothing, certainly with respect to time-shift recording.
> I have seen similar stories about not being able to
> record shows on a cable PVR when copy never is signaled in
> the CGMS bits.
Yes, my older Philips DVDR, when recording off the NTSC tuner, had a
terrible habit of blocking my recording sessions. The problem got
progressively worse. At the start, only NBC misused the CGMS. I wrote to
them, they said it wasn't intentional, and the problem was temporarily
solved. But then Fox and CBS started to as well, and IIRC also UPN. It
was maddening. Fortunately, I could solve the problem by recording on
that DVDR off the Accurian STB. With the ATSC input, finally I got
control back.
Fortunately, my current Philips/Funai ATSC PVR seems to behave properly.
Bert
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
