[opendtv] Re: FCC CHAIRMAN PROPOSAL TO UNLOCK THE SET-TOP BOX: CREATING CHOICE & INNOVATION

  • From: Mike Tsinberg <Mike@xxxxxxxxxxxxxx>
  • To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
  • Date: Mon, 1 Feb 2016 15:49:19 +0000

What is fundamentally changed compare to Cable card initiative years ago? Up to 
now cable companies paid only lip service to “open” cable initiatives including 
establishing Cable labs but never give up control of the STB. Even when same 
hardware platform is used among competing Cable brands (Scientific Atlanta and 
now Cisco) they insist on a customized operating GUI and functionality. 
Allowing 3-d party making STB may lower hardware cost but most likely will not 
open dear to Cable companies VOD and PPV controls.



Best Regards,
Mike Tsinberg
http://keydigital.com

From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Craig Birkmaier
Sent: Monday, February 01, 2016 10:22 AM
To: OpenDTV Mail List
Subject: [opendtv] FCC CHAIRMAN PROPOSAL TO UNLOCK THE SET-TOP BOX: CREATING 
CHOICE & INNOVATION

The article Monty posted this morning contained a link to a document providing 
more details about the Set Top Box NPRM that the FCC is planning to vote on at 
the February meeting.

http://transition.fcc.gov/Daily_Releases/Daily_Business/2016/db0127/DOC-337449A1.pdf

As I expected, and discussed at some length, this is just the beginning of a 
process that could take years. It IS NOT something that could happen in months 
as Bert suggests.

First, this is just the NPRM. There will be an extended comment period before a 
potential Rule Making could be voted on. Then there is the potential for 
additional years of delay to create and implement the standards required to 
connect to the MVPD systems.

As I expected, the FCC is asking for a standard that DOES NOT require a 
hardware component to deal with DRM. But this document also notes that systems 
can continue to use different DRM solutions.

As I discussed, there are a number of elements to the proposed solution. Here 
is the key part of the Chairman's proposal:

To ensure a competitive marketplace as required by the Telecommunications Act 
of 1996, the proposal identifies three core information streams that must pass 
from MVPDs to the creators of competitive devices or apps:

·         •  Service discovery: Information about what programming is available 
to the consumer, such as the channel listing and video-on-demand lineup, and 
what is on those channels.

·         •  Entitlements: Information about what a device is allowed to do 
with content, such as recording.

·         •  Content delivery: The video programming itself.

Standards: Promoting interoperability and removing barriers to innovation

·         •  Instead of mandating a government-specific standard for these 
three information flows, which might impede innovation, the Chairman’s proposal 
recommends that they be made available to the creators of competitive devices 
and navigation solutions using any published, transparent format that conforms 
to specifications set by an independent, open standards body.

·         •  The proposal identifies five characteristics that must be met by 
an independent standards body: openness in membership, a balance of interests, 
due process, an appeals process, and consensus.
In other words, Cable Labs does not get to set this standard.  At a minimum, an 
existing standards organization that meets the above criteria will need to 
create the new standard. And in the end, it will require consensus of all the 
affected parties. As I discussed, this is very much like the DTV process with 
the advisory committee, and the ATSC acting as the "impartial" standards body.

With respect to security it states:

Security: Preventing theft and misuse

As technology has evolved, so has the market’s ability to prevent theft and 
misuse. Smart TVs, for example, currently ensure the same security for 
copyrighted material as the traditional set-top box. The proposal provides 
MVPDs flexibility in the security systems they use while putting in place some 
constraints to ensure that they do not use their security choices for 
anti-competitive purposes.

• The proposal does not propose a single mandated security system, but rather 
simply requires MVPDs to offer at least one content protection system that is 
openly licensed on reasonable and non-discriminatory terms. This will allow 
each MVPD to determine the content protection systems it deems sufficient to 
prevent theft and misuse, and will not impede the introduction of new content 
protection systems.
This is where Bert came up with the misguided notion that the DRM in HDMI is 
sufficient. All it does is prevent the recording of programming in a manner 
that the content can be pirated.

DVRs are temporary caches that are protected by the DRM system in the STB that 
is used to decode content from the MVPD. The NPRM continues to allow MVPDs to 
operate proprietary DRM systems, and license them to would be competitors.

And there is the minor issue of "reasonable and non-discriminatory licensing 
terms. We could end up with something like the ATSC standard, where the license 
fees burden the cost of the third party devices. This would certainly be much 
less than $7/mo, but would still be a lucrative revenue stream for the MVPDs 
and their DRM vendors.

The rest is open to interpretation, and will no doubt be the fodder for 
voluminous comments. All programming must be accessible, but rules for 
recording and the terms of existing licensing agreements must be honored. This 
is a huge can of worms.

There is nothing here that even requires the MVPDs to move to IP streaming. 
They can continue to use MPEG-2 and MPEG-2TS. There is a provision that MVPD 
content be available to tablets and other IP appliances, but the burden to 
enable that may well fall on the device manufacturers, as is the case today 
with MVPD STBs that transcode to h.264 and make these streams available via 
WiFi in the home.

Realistically, the desired outcome of this process would be to move beyond 
existing compression and transport standards to the Internet standards Bert 
rightfully claims already exist. In an ideal world, most of this could be 
hashed out by the "standards body" in a year or two.

Unfortunately, we do not live in an ideal world.

Regards
Craig

Other related posts: