[opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media Center Play By?
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Thu, 29 May 2008 16:49:24 -0700 (GMT-07:00)
And, broadcasters who generate the extra bits in the rc_descriptor-- absent a
change in FCC rules and policy -- stand liable for payment of fines to the
government for airing any extra bits in the rc_descriptor, a situation that is
'lamost' unique as pertains to descriptors.
In my reading, receiver makers could implement 'featuers' around the extra bits
without amassing liability to the federal government, since the FCC lacks
authority under the Communications Act to regulate signal processing in
receivers after demodulation.
John Willkie
-----Original Message-----
>From: Adam Goldberg <adam_g@xxxxxxxxx>
>Sent: May 28, 2008 9:58 AM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media Center
>Play By?
>
>> 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.
>
----------------------------------------------------------------------
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:
