Whither EBIF in an IP World?
One of the recurring topics at last week’s TV of Tomorrow conference, put on by interactive-TV beacon Tracy Swedlow, was the fate of EBIF, the method of choice for embedding a clickable thing into a TV show or advertisement.
As this column has noted before, EBIF’s power is in its reach: It was invented as a way to add more oomph to the fielded base of digital cable set-top boxes, which obsolesced almost before they were installed. Ten years ago.
EBIF (the Enhanced TV Binary Interchange Format) began as a way to let viewers click to request more information about a product, click to view more episodes of a show (also called “VOD telescoping”) and to participate in voting/polling activities.
Last year, EBIF flourished anew as a way to make a TV remote control out of an iPad, smartphone, laptop and similar gizmos in your digital garden that tend to hang out near you and your TV.
What happens, though, with an EBIF trigger nestled inside a video stream that doesn’t travel through a set-top - like the connected side of a connected TV? “Connected,” in the 2011 sense, means “to the Internet.” Input one, cable; input two, Internet. Let’s say you’re on the Internet side, watching a show. The EBIF trigger is baked into the stream. How do you see it?
There are a couple of options, panelists at last week’s TVOT noted. Option one: Convince consumer-electronics manufacturers to include an EBIF “user agent,” or UA, into their gadgets, so as to see and render the clickable thing. Consensus: Good luck with that. 25 million EBIF-enabled boxes sounds like a big number, but it’s not 100 million TV households.
Option two: Transcode the trigger into the equivalent of a Web bookmark, for the end device to go to retrieve the clickable thing. Consensus: Better, but timing issues need to work to make sure the triggers fire in sync with the underlying content. Seeing an option to “click here” for an item that left the screen 10 seconds ago doesn’t seem like a recipe for success
Another option is to put the user agent somewhere else in the network - like in the cloud. Maybe the trigger comes down as an instruction to the CE device to pop it up to the cloud, which knows which clickable thing to send back, quickly, and in sync with the show or ad that’s on the screen.
Whither EBIF in an IP world? Yes.
________________________________________
Stumped by gibberish? Visit Leslie Ellis at multichannel.com/blog or translation-please.com.
Don commented:
@Joe, yes. The whole purpose of Canoe might be to squeeze the last few dollars out of the STB, buying time for Comcast to get out of the cable business and reinvent itself as a media company.
Don commented:
@Joe, right on. Just goes to show that the true purpose of Canoe is to choke a few more dollars out of the installed base of STBs rather than help the industry advance.
Anand Shah commented:
Leslie - nice article. We at Ignite Solutions have actually identified this problem and have created a solution for this. We followed a 3rd option. Our solution seamlessly and on-the-fly translates EBIF resources, ETV signals, Triggers, 2-way requests and data-updates into HTML/Javascript. We also have a user agent that requires no plugins (i.e. based on Web standards) that manages the full EBIF lifecycle. In essence, EBIF and ETV on the IP stack with full functionality easily workable in Chrome, Safari, Mozilla and any webkit browser. We even think that this approach does more than support EBIF on IP. It enables a bound-app protocol that allows cross-platform apps and late-binding ads to work. We recently validated it at the ETV Interop at CableLabs with great success. More information can be found at http://ignitesol.com
mark commented:
Sorry to say as an ex cable operator I’m embarrassed by the industries path toward yesterdays technology… I understand migration from a capital intensive platform can be painful but the CE guys, more content available via the web and new technologies via app’s will just leave my old friends in the dust… EBIF is irrelevant
Joe commented:
As you mention there are two difficult questions in trying to extend EBIF beyond a legacy cable set-top box, neither of your options solves both of them. Problem 1: Triggers. EBIF is highly dependent on MPEG-2 system information and other non-IP technologies. As you point out the triggers are “nestled” into these formats. Recall from your own April 2010 article that EBIF is similar to ATVEF in this respect, which died in 1999. No such standard exists under IP delivery of video and you certainly don’t want to send a MPEG-2 transport stream to your iPad. Problem two: User Agent. The fundamental function of the UA is to compose graphics and text on top of the video which is best done at the point of video decode. It very difficult/expensive to do it from the ‘cloud’.