[opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media Center Play By?
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Mon, 26 May 2008 10:58:01 -0700 (GMT-07:00)
Oops. Sorry, but our discussions might have caused some confusion.
The "broadcast flag" as referenced by the FCC is the rc_descriptor in ATSC A/65.
The rc_descriptor as permitted by the FCC is a two-byte descriptor. First byte
is the descriptor_tag, followed by a zero. As a logical construct, it is
either present, or not. A/65 says that when present, it signals "technological
control of redistribution is signalled." That isn't signalled when the
rc_descriptor is missing.
How an implementer interprets it is up to the implementer. That's the nub of
the discussions here on the topic.
"CopyAlways", "CopyOnce" and "CopyNever" are settings permitted within the XDS
data field that is permitted within (at the very least) CEA-608 [analog]
captions.
The MS team leader said in a blog post some years back that the rc_descriptor,
in MCE is treated as CGMS "CopyOnce". If the recent problems are truly caused
by the rc_descriptor, it would appear that presence of the rc_descriptor has
come to mean, in MCE, "CopyNever."
I usually don't refer to the broadcast flag, because some people conflate that
with CGMS or the rc_descriptor, without establishing distinction. I tend to
always refer to the rc_descriptor.
In context, I know that Adam uses broadcast flag to mean rc_descriptor. He's
also 'kinda' familiar with XDS data and CGMS. The last time I even looked into
this was more than a year back when SMPTE D27 had a shot at the latest rewrites
of CEA-708 and CEA-608.
The FCC isn't wishy-washy about what the rc_descriptor means. ATSC A/65 is
incorporated by reference in FCC rules, so the presence of the rc_descriptor in
is simply: "The descriptor’s existence within the ATSC stream shall mean:
“technological control of consumer redistribution is signaled."
The FCC wanted that to use that language to assert control over what receiving
devices could do with the content. They lost on that point, since they have no
jurisdiction beyond the RF section of receiving devices. However, the meaning
is "rather" clear.
Adam thinks that removing the rc_descriptor on the receive side doesn't involve
section 1201 of the copyright Act. Since there are no court decisions on
point, I can't agree with him at this point. I should also note that engineers
tend to see the world in more of a binary fashion than do legal eagles.
And, this discussion is almost spurious -- without talking about the foolish
conspiracy talk -- because nobody here has talked about having a transport
stream capture of the broadcasts in question, nor have we fed them back into
MCE/Vista boxes (and other transport streams) to discern just what bits cause
the problem, or if the issue lies elsewhere.
<lecture>
The take-away from this is to be in full compliance with all ATSC standards, or
you risk these types of issues coming up again and again. The standards define
the interface between receiver and transmitter. If the transmission isn't in
compliance, different receivers will react differently.
</lecture>
John Willkie
-----Original Message-----
>From: Craig Birkmaier <craig@xxxxxxxxx>
>Sent: May 25, 2008 3:47 AM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Microsoft's Masters: Whose Rules Does Your Media
>Center Play By?
>
>At 2:35 AM -0400 5/25/08, Albert Manfredi wrote:
>>Richard C. Ramsden wrote:
>>
>>> Microsoft is in an odd position. Technically respecting the
>>> "broadcast flag" is illegal.
>>
>>It's not illegal, and what's more, "respecting" it is an undefined concept.
>>
>>The courts decided that the FCC was overstepping its bounds in its
>>2003 ruling about how this flag was to be implemented in receivers,
>>but that doesn't mean that manufacturers can't interpret the field
>>to mean anything their fevered minds can come up with.
>>
>>I agree with Tom. Microsoft is pandering to the media moguls,
>>assigning a meaning to that flag that neither the ATSC nor the FCC
>>had *EVER* envisioned.
>
>They assigned the exact meaning to the redistribution control flag as
>defined by the ATSC. In this case NBC set the flag to "copy never."
>
>>The ATSC calls it a "redistribution control" flag, then gets all
>>wishy washy about what that means. The FCC had tried to be more
>>precise, but the courts didn't like that.
>>
>>Microsoft took it upon itself to pretend the flag means "copy
>>never." Completely out of the blue.
>
>Not out of the blue. They just honored NBCs intent.
>
>>
>>I find it unethical for manufactuers to sell products that are NOT
>>in the best interest of their customers (within legal limits, of
>>course). I don't know how anyone can stand by and watch this sort of
>>collusion between industries going on and not become irate.
>
>Feel free to feel rate.
>
>When enough people get fed up with being treated this way the media
>moguls will have no choice but to give the customer what they want
>WITHOUT the crap. But more likely they will keep giving us crap...
>
>Regards
>Craig
>
>
>----------------------------------------------------------------------
>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:
