itvt

CableLabs’ ETV standard (consisting of two sets of specs: 1) the ETV Binary Interchange Format–otherwise known as ETV-BIF or EBIF–which is the content format, and 2) a signaling and trigger mechanism) is designed to enable simple interactive TV applications on the low-end 2000-series set-top boxes that have been widely deployed by US cable operators, that are unlikely to be swapped out anytime soon, and that lack the resources to run OCAP middleware. [itvt]’s Tracy Swedlow recently spoke to Don Dulchinos, the CableLabs executive in charge of both the ETV and the OCAP standardization efforts, about the current status of the ETV standard, about what has to happen before it is commercially deployed, about capabilities that may be added to the standard going forward, about the new version of OCAP (v 1.1) that CableLabs is currently developing, and more.

[itvt]: Can you tell us a little about the origin of CableLabs’ ETV standard?

Dulchinos: At CableLabs, when we were developing OCAP, we asked ourselves whether the target platform for the software should be the current generation of digital set-top boxes or a future generation. We decided to aim a little bit into the future. And so the OCAP stack requires that the set-tops it runs on have a certain minimum amount of memory and processor speed–which places it beyond the capabilities of the first generation of digital set-tops, the Motorola DCT2000 and the Scientific-Atlanta Explorer 2000.

[itvt]: When you were developing OCAP, how long did you think it would be before it was deployed?

Dulchinos: Well, we certainly didn’t think that that it would take as long as it has done. Back in 2001, we thought it would maybe be a couple of years before most set-tops out there would be capable of running it. We decided that we could live with that, but every year we kept asking ourselves the same question: "Now that we’re one, two or three years out from having developed the spec and there are still low-end boxes out there and even still being deployed out there, do we need to reconsider?" So we had that same chat every year until 2005, when we decided, "Yes. We do need to have a solution for those low-end boxes, because there are now probably still tens of millions of those boxes out there." And so that’s when CableLabs got the assignment to go ahead and develop a new standard.

[itvt]: What are the other main differences between the OCAP and ETV standards, in addition to the fact that the ETV standard enables the authoring of interactive applications for low-resource set-top boxes?

Dulchinos: Well, the OCAP environment extends the capabilities of the set-top box overall. One major difference between OCAP and the ETV standard is that OCAP was designed to enable unbound applications. What the ETV standard was primarily designed to enable is enhanced TV that is bound to a single channel–that you access as you watch that channel. OCAP, on the other hand, was designed to enable applications that are active and available no matter which channel you’re tuned to. The other major difference is that OCAP platforms also presume a DOCSIS return channel–so a very high-bandwidth return path. So, among other things, OCAP could, for example, enable the integration of broadband content from the Internet with applications on the set-top box, to make for more sophisticated applications.

[itvt]: Now you got two companies that had developed XML technologies for TV, GoldPocket and MetaTV–which is now part of TV Works, the joint middleware venture between Comcast and Cox–to get involved in the effort to develop the new ETV standard. How did that happen?

Dulchinos: It was really just standard CableLabs procedure. You decide what you want to do and then invite either a member company or vendor specialists who know the territory to become involved in writing the spec. And those two companies were obvious candidates. I should also mention that Navic Networks helped with the ETV specs.

[itvt]: Were any other companies involved?

Dulchinos: Not in the actual writing of it. It was a very small group–though three cable MSO’s were also involved: Comcast, Time Warner and Charter.

[itvt]: What’s the current development status of the ETV standard?

Dulchinos: Well, the standard and the specs are finished. Features will get added, but the basic architecture is finished, and it’s stable.

[itvt]: How long did it take to develop the standard?

Dulchinos: Not very long, because we were basically adapting existing work. We had to resolve some differences in the ways that different companies had approached the standard. But it was really only a matter of months before we came up with the new standard.

[itvt]: And the new standard is composed of two main elements, correct?

Dulchinos: Yes. There’s the main part of the standard, the ETV Binary Interchange Format–or EBIF–which is the content format or the application format, if you will. And there’s also a signaling and trigger mechanism that’s specified. And those two things together make up the ETV standard.

So, to clarify, the Binary Interchange Format or BIF is the content format, or the language in which you author the application. Signaling means the information in the program stream, through which the box knows there’s an ETV application in the stream. And triggering means the mechanism through which the box responds to users pressing the button in response to the ETV prompt on screen.

[itvt]: And the standard is ready for deployment today, correct?

Dulchinos: Yes, absolutely. Version 1.0 was finished at the end of 2005, and most of this year has been spent developing product to it. A major part of that is the user agent, which is the software code that is downloaded to existing boxes, and sits in those boxes and executes the application–it acts like a virtual machine inside the box. So TVWorks and Time Warner Cable have been working on implementing these user agents, writing the necessary code for their respective set-top boxes.

[itvt]: Are any other MSO’s developing user agents in addition to Time Warner Cable and–through TVWorks–Comcast and Cox?

Dulchinos: Not that we know of.

[itvt]: Is GoldPocket–which is now part of Tandberg Television–still involved in the process?

Dulchinos: Not currently. They’re not focused on the user-agent piece–not least, because that’s been taken in-house by the MSO’s. I think Tandberg is more interested in the end-to-end delivery of applications and in the uplink side and all that.

[itvt]: Is developing the user agents difficult?

Dulchinos: No, it’s not complicated. I think what’s basically happening is that the MSO’s have taken the development of user agents in-house because user agents are simply not a market segment that anyone believes can make up a long-term business. Besides, they’re eager to make sure that the ETV standard works properly in their environments and that it’s properly integrated with their overall navigation platform. What they’re basically doing is tweaking the performance of the application inside the set-top box. So they need to optimize their platform. However, I should make clear that they’re not adding proprietary hooks, or anything like that, to the standard itself. Because, obviously, the whole point of developing a standard like this is so that the content providers can author applications to it without having to rewrite those applications for each individual MSO. Clearly, the content providers need a single standard.

[itvt]: When you first set out to develop the ETV standard, what did you want it to do, versus what you want it to do now? Are your goals still the same, or has your vision for the standard changed over time?

Dulchinos: Well, the ultimate goals are still the same: standardization and interoperability. However, our vision of what the feature set should be has continued to evolve.

To date, we’ve had three interoperability events and we’re about to have a fourth. These are week-long lab events, where we invite the different players to come here to CableLabs’ facility and demonstrate their products’ compliance with the spec. And so we get the set-top box manufacturers, the MSO’s who are developing user agents, and the application developers to come in and test different applications on different user agents on different set-tops. That process has proven out the standard. It came as no surprise, but it was relatively straightforward to get it working–to get it to a state where the application developers could say, "I can write an application once and it does indeed run on both of those user agents, and it looks pretty good on all the different boxes."

However, over the same timeframe, additional features have been proposed and adopted. There are two main features that have been incorporated into the standard: the first is the ability to trigger an on-demand session. So if you’re watching, say, CNN’s linear channel, an icon can pop up and say something along the lines of: "You’re watching a program on the Middle East. Would you like to see a one-hour on-demand documentary about the Middle East?" And you can select–and, if appropriate, purchase–that documentary, and then be taken directly to an on-demand session. So that was one new feature–and it was really just a simple enhancement to the spec as it was. The second new feature was enabling advertising insertion. It actually had a couple of elements. One was similar in function to the on-demand feature: if you’re watching a commercial spot for a car, for example, you can get a trigger that says you can watch a long-form ad about this car, and, if you select that, it launches an on-demand session. The only real difference is that the on-demand session you launch happens to be advertising content rather than programming or editorial content. So the spec allows telescoping, as it were, into an on-demand session. The other element of the advertising piece is that it enables a more conventional request for information: you can click on an icon to confirm that, yes, you want to be sent more information on the product that’s being advertised.

[itvt]: Why do you think ETV is important, as compared to OCAP?

Dulchinos: Well, OCAP I’m always excited about because it’s such a far-ranging thing–it will really be a major leap forward to have a common platform not only for all the cable operators on their own boxes, but also on retail devices, such as television sets. So the impact of OCAP is obviously going to be greater in the long run. But in the short run, what’s interesting about ETV is that it’s a particular type of application: it’s less about having a standard platform and more about enabling some near-term revenue opportunities. So that’s pretty fun. It’s much less abstract than middleware.

[itvt]: Are you planning to add a transactional component to the ETV standard?

Dulchinos: That is an opportunity that’s definitely being explored–it’s pretty easy to see how it would be possible. The challenge would be in the backend: it would be all about standardizing business interfaces in the backend for commerce partners to plug into.

[itvt]: What are some areas where we could see some additional development of the ETV standard?

Dulchinos: One area that we’ve heard back interest in is for what people refer to as "brand extension." When we first started talking about the new standard to programmers, we found that those programmers who had cable channels that are more oriented towards re-runs and classic programming had a great deal of interest in offering interactivity around those programs, in order to keep their content fresh. At the same time, though, we would hear back from other programmers–particularly operators of premium channels–who would tell us, "Our whole point is that we spend a lot of money on programming, in order to keep the audience engaged. So we don’t want to distract them with interactivity. For us, interactivity is beside the point. However, if you’re talking about telescoping kinds of opportunities, where I can extend my brand and present a set of menu options, including on-demand, that are all related to my brand, then I’m interested." And so the on-demand feature that we just talked about is one of these brand extension-oriented features, but I think that there are probably other features pertaining to that area that are also going to eventually be part of the spec.

[itvt]: Do you have information on specific markets where operators are going to be launching the ETV standard in the near future?

Dulchinos: No. I don’t have any information on specific markets where it’s going to launch.

[itvt]: What prevents the ETV standard from being in use today?

Dulchinos: It just has to do with integration into the MSOs’ various platforms. As you know, the MSO’s have developed navigators, such as the Time Warner Digital Navigator and the GuideWorks (i.e. Comcast and Gemstar) iGuide, and they have software roadmaps for those products: they have a set of features that they want to add to them over time, and ETV happens to be just one of those features. So it just needs to take its place in the queue. Now, I don’t know what the individual operators’ priorities are that are holding them up from integrating the ETV specs with their guides, but the only thing that prevents ETV from being deployed today is those other priorities.

[itvt]: So the user agents are now more or less ready, and we’re just waiting for integration into the navigators to take place…

Dulchinos: Yes, exactly.

[itvt]: Are the operators making launching OCAP more of a priority?

Dulchinos: It’s a parallel track. OCAP deployment also has a major headend component. Getting one’s guide to run on OCAP is a major application-porting exercise. It involves a different type of work than is involved in rolling out the ETV specs.

[itvt]: What do operators need to do at the headend in order to support the ETV standard?

Dulchinos: At the headend, it’s not so complicated. Because it’s in-band, it’s simply a matter of insertion by the programmer upstream, and then just making sure that the headends can recognize that that content is there and that it gets through.

[itvt]: Is the ETV standard a band-aid, or is it something that could be used for many years to come?

Dulchinos: One of the goals for it is to be…I would call it forward-compatible. So that it nests inside of an OCAP environment just as well as it does inside of any legacy digital environment. It’s intended that, whichever of the applications that are written to it prove to be popular and profitable, developers will be able to keep making those applications, and they’ll keep running on cable operators’ platforms as those platforms get more and more robust.

[itvt]: Ensequence recently announced that its authoring software is compatible with the ETV standard. Which other authoring and publishing solutions providers have ensured that their software is ETV-compatible?

Dulchinos: emuse, Softel-USA, and TVWorks have all developed tools.

[itvt]: When will we see actual deployments of the ETV standard? And do you know when field trials are likely to begin?

Dulchinos: No comment.

[itvt]: I understand that CableLabs is now working on OCAP version 1.1. What features does it offer over and above those offered by the current version of OCAP?

Dulchinos: IP-based tuning, allowing set-tops and OCAP-ready devices in retail to access IP broadband video as well as MPEG-based video; support for mobile video and applications; and support for advanced graphics, home networking and switched broadcast; as well as more support for digital program insertion technologies. It also has better resource retention–which is about how multiple applications on a box share resources like memory or processing power.

[itvt]: When will OCAP 1.1 be launched?

Dulchinos: We hope by the end of the year.

URL: CableLabs

Originally Published: October 27, 2006 in [itvt] Issue 7.01

Click: http://www.itvt.com to subscribe to our free email newsletter, which contains all the news stories you see on this Web site, and additional breaking news and scoops, in-depth features, interviews, screenshots, videos, and other exclusive content you will not find anywhere else.