Just one month ahead of its deadline for a final report, a special US government task force is still struggling mightily to recommend a replacement for the pay-TV industry's ill-fated CableCARD. But, as the clock ticks away, it's facing an increasingly uphill battle.
The Federal Communications Commission (FCC) 's Downloadable Security Access Technology Advisory Committee (DSTAC) has been working for the last six months to come up with recommendations in response to a mandate from the US government. The mandate says the committee must come up with proposals for a downloadable security system that is technology- and platform-neutral, and that supports competition for set-tops and other pay-TV devices by retail companies. DSTAC participants have fought fiercely over how that directive should be answered.
At the latest DSTAC gathering this week, committee members were somewhat less hostile to each other than in previous meetings. But, at the same time, several major disagreements were still evident, and the September 4 deadline for a final report from the group is rapidly approaching. (See Desperately Seeking a CableCARD Replacement .)
The agenda for the DSTAC meeting on August 4 included presentations by two working groups. One group was tasked with addressing the security elements of a downloadable content security system, while the other was set to crafting recommendations for managing third-party device platforms and television interfaces. The use of IP for streaming video within the home was common to all of the proposals presented, but different coalitions within each group had very different opinions on how to arrive at that IP-based end point.
The working group focused specifically on security put forth two proposals: one authored by Comcast Corp. (Nasdaq: CMCSA, CMCSK), and the other by Public Knowledge . The first proposal recommends the use of an HTML5 media model with Encrypted Media Extensions (EME), Media Source Extensions (MSE) and Web Crypto as an interface between services from MVPDs/OVDs and consumer electronics devices. The service providers in this case would have to make all video streams available on websites that could exist either in the provider's network or in the consumer's local cloud. Devices in the home would then access those streams via API for local IP-based distribution.
The second proposal recommends a Virtual Headend System where conditional access technology is hosted in the cloud, and then there is a link protection mechanism (such as DTCP-IP) that manages the security connection between the cloud and a consumer device. As Adam Goldberg from Public Knowledge defined it, "The MVPDs should do whatever it takes in their network to provide a link-protected interface to the home network and consumer devices."
Goldberg went on to explain that the approach might require a secondary in-home box for some providers, but not for others.
Responding to the presentations, Google (Nasdaq: GOOG)'s Milo Medin said he was a little disappointed not to find a diagram outlining the data flow in both approaches, i.e. where QAM video would be converted into IP. However, he did recognize important common ground between the proposals, noting that "there's not that much difference between [the HTML5] and the Virtual Headend approach. There's a conversion whether in an all-IP network at the headend, or locally in the home via some kind of gateway device."
The mood was relatively good-natured after the first working group's proposals were presented. Unfortunately, that good will did not extend into later discussions.
The next working group -- focused on third-party devices and user interfaces -- also presented two proposals. One, presented by Cablevision Systems Corp. (NYSE: CVC), suggests that the industry should stick to the existing video app system for delivery of MVPD and OVD services. In other words, CE companies should be able to develop their own hardware, but the television service delivered on top should come from a service provider's specific app, interface and all.
"The essence of the app-based proposal is that MVPD apps should be treated exactly like Netflix, YouTube, Amazon and other video providers writing such applications," said Paul Gliss, who is serving as the alternate for Cablevision representative Bob Clyne.
The second proposal, authored by Hauppauge Digital Inc. , recommends that the industry define three separate functional modules inside the user interface: a service discovery interface, an entitlement information interface and a content discovery/delivery interface. Each of these interfaces would be accessible to any third party for development purposes, making it possible to design new customer experiences around the traditional MVPD service.
Not surprisingly, there was significant backlash against both recommendations.
"It has nothing to do with a downloadable element, it's some sort of outlier approach that says forget everything we've been doing so far in this community as part of DSTAC," said TiVo Inc. (Nasdaq: TIVO)'s Dr. Joseph Weber in response to the app-based proposal. "[This approach] does not envision there's an independent TiVo-like device, a DVR that I can record [using] my user interface or some new competitor's interface. The only one is the app that the MVPD decides."
On the other side of the argument, Comcast's Mark Hess had choice words for the Hauppage proposal. "This means, practically, years to develop not-yet-invented standards and then to implement them," he said.
Hauppauge's Brad Love acknowledged that "further work will have to be done on this."
Hess seemed to think that was an understatement. "It's a lot of work," he responded.
The DSTAC group still had a full afternoon at that point to discuss ways of coordinating the recommendations from both working groups and to determine whether different solutions could work together. However, there was not a lot of optimism in the room that these tasks could be accomplished.
In a brief sideline discussion during the meeting, TiVo's Matthew Zinn lamented that there's "a fundamental policy question as to whether you're going to allow third-party interfaces."
Asked if he thought the committee would be able to come to any consensus in its recommendations, Zinn replied, "I don't think so."
There is now just one more DSTAC meeting, scheduled for August 28, before the group's final report is due. The FCC then has options about how to respond to the report. It could do nothing after reviewing the recommendations, put the proposals out for further comment, open up a Notice of Inquiry or even release a Notice of Proposed Rulemaking. So far, there is little indication of how the FCC will proceed.
— Mari Silbey, Senior Editor, Cable/Video, Light Reading