The iTV Doctor Is In!: Interactive TV and "The Cloud"

Dear iTV Doctor:

I'm writing you anonymously today, because I don't want my friends to know that I really don't understand "The Cloud" as it applies to television content. In fact, I really don't understand "The Cloud" at all. I know that it basically means that I get content from out there (somewhere), but where does it all start and how does it get to me? I know that when our customers make an on-demand request, we fire up a dedicated stream from our server to their set-top box (right?). To quote Joni Mitchell, I really don't know clouds at all.

Clueless in St. Cloud


Dear Clueless:

I'm sure you are not alone in your confusion about the cloud. So to pierce the clouds with a bit of sunshine, I called on John Callahan, CTO of ActiveVideo Networks (a major proponent of Cloud TV), and Jeremy Edmonds, the company's director of technical business development. Following are excerpts from a Technical Paper that they co-authored: "Cloud Computing for Cable TV: Expanding Choice, Control & Content for a New Generation of Television Viewer."


"The language of the computing 'cloud' is typically associated with the Internet, even though the term itself pre-dates the Internet by at least two decades. Before it was the 'cloud,' computer scientists recognized the need for 'grid computing,' 'distributed processing,' and other variations on the theme of sharing a processing workload over clustered computers."

Callahan and Edmonds point out that the benefits of cloud computing apply to interactive television, as well. They note that the "TV cloud" can remove workflow gaps and bridge the application and media processing requirements between headends and set-tops. They also point out that a cloud approach enables developers of programming and advanced advertising to use familiar, Web-based development tools that are similar to, or the same as, those used to provide interactivity within a Web site (e.g., DHTML, JavaScript, etc.).

"One of the features of the Web is that it is essentially a 'cloud computing' model in the 'software as a service' sense," Callahan and Edmonds continue. "It allows the application lifecycle to be managed on a small and well-behaved domain of common devices--network servers and common client devices, i.e. PC's. The fact that PC's all have enormous computing capabilities means that media-rich applications depend on client-based media processing technologies for application execution (e.g., Flash).

"Multichannel video operators share the benefit of the Web approach and utilize network-based servers to support complicated, media-rich applications--but they cannot depend on the client to have the necessary capabilities. Unlike the ubiquity of just one or two operating systems and common API's, the multichannel video provider has dozens, if not hundreds, of client [set-top] platforms--all differing in the details of capabilities and performance."

While Callahan and Edmonds were speaking specifically about cable, the same issue exists in the consumer electronics space, where an equally diverse group of platforms requires content to be authored many times to be delivered to multiple devices. They draw an analogy between the TV scenario and the personal computing model in which it is easier to deploy Web-based applications than it is to deploy applications on PC's.

The authors note that "cable operators all have one common 'standard' in their client devices, i.e. MPEG decoders," and that this capability, when combined with server-based applications in the cloud, brings a more "Web-like" application lifecycle model to the television viewing platform. However, they recognize the value of device-based processing as well, and suggest that the best approach is to bind together the best features of cable, cloud, and client.
 
"To be fair, an entirely cloud-based approach to interactive TV isn't the right answer, either," they write, noting that doing so doesn't take advantage of client-device capabilities, like local graphics blending, and a location execution environment for overlay applications. "An easy example of this is the ability to detect embedded data 'triggers' on broadcast video streams (think 'EBIF Trigger'). This allows a local application to 'overlay' graphics on the video stream (and execute application logic) only for those viewers who choose to do so; it creates a locally interactive individual experience with a broadcast video service. There is no need for such a mechanism with unicast video streams as the viewer is already engaged in an individual, one-to-one, experience. As the bandwidth intensive video is shared (broadcast), this approach can be more efficient than unicast streams.
 
"Likewise, certain applications are almost entirely client-based. Chat and social networking applications are good examples. They typically require a user to log on and the network to maintain knowledge of their location, a.k.a., 'presence-based' applications. These applications are typically comprised of low-bandwidth text and graphics and are not associated, or bound, to a unicast video stream. Simple text and graphics can usually be processed by client devices using graphics overlay and are not directly associated to a unicast video stream (think 'chat room associated to a live sporting event').

"The ideal environment for immersive, video-linked interactivity, which infuses Web-like characteristics into TV shows and ads, is a combination of cloud computing and a traditional client-server applications architecture approach. Network servers have the processing power and resources to create media-rich, video-intensive applications. Client-side application execution can provide associated overlay applications, as well as detect embedded video triggers that can then be locally processed (on the client) to further enhance the viewer's experience by offering hyperlinks to related video or other applications."

An example cited by Callahan and Edmonds would be a TV commercial with embedded EBIF triggers that enable telescoping into an ad microsite. "The user reacts to the trigger," they point out, "initiating a local application overlay. The overlay application displays several options, including the ability to see special how-to videos. The user selects a video of interest and the local EBIF application signals a network server, which initiates a unicast video stream in concert with the local application. The user is now seamlessly viewing a linked video. This video stream is inherently personal (as it is unicast) and may contain further embedded triggers. As the server can process user requests for complex media types and encode them to client-compatible media formats in real time, the application may bring all the depth of a typical multimedia Web site application to the viewer.

"Meanwhile, a scaled version of the broadcast stream can be included in every scene, enabling the viewer to continue to view the original programming channel. Given appropriate 'TV production values,' the net effect on the viewer is no obvious 'interactive' or 'VOD' application, simply viewing a video with all the richness of the Web and the immediacy of the classic television presentation experience."

(iTV Doctor's comment: I absolutely agree with that last statement. It is increasingly obvious--and proven by the good people at Apple--that we must not let technology get in the way of the experience).

===

The iTV Doctor is *Rick Howe*, who provides interactive television consulting services to programmers and advertisers. He is the recipient of a CTAM Tami Award for retention marketing and this year was nominated to Cable Pioneers. He is also the co-author of a patent for the use of multiscreen mosaics in EPG's. Endorsed by top cable and satellite distributors, "Dr" Howe still makes house calls, and the first visit is always free. His services include product development, distribution strategy and the development of low-cost interactive applications for rapid deployment across all platforms. Have a question for the iTV Doctor? Email him at itvdoctor@itvt.com