Interactive video as a revenue-generating opportunity still eludes broadcasters, in some part because of limits of the existing broadcast standards. This is about to change, with the advent of various new technologies that will add interactivity in a backwards-compatible fashion.
HbbTV adds bandwidth
Hybrid Broadcast Broadband TV (HbbTV) is a Europe-originated specification based on HTML and other Web technologies, including Open IPTV Forum (OIPF), CE-HTML, DVB Application Signaling and Dynamic Adaptive Streaming over HTTP (MPEG-DASH). A similar system, called Hybridcast, is being developed in Japan. HbbTV is built around the concept of a hybrid terminal that can be connected to two networks in parallel — the broadcast network and a broadband bi-directional Internet connection through an ISP. In this manner, the HbbTV terminal can receive standard OTA broadcast content, as well as broadband-delivered linear and file-based content; application data is received by means of either network, and signaling information is delivered over-the-air.
The HbbTV spec supports the use of broadcast and broadband networks together or independently; Stream Event Triggers are used to activate applications or synchronize them with the broadcast. Two types of applications are supported: broadcast-related applications, which are signaled as part of a broadcast channel, and broadcast-independent applications, for which the current specification does not define any signaling, announcement or discovery. An updated version of the HbbTV specification was approved by the European Telecommunications Standards Institute (ETSI) in November 2012.
NRT content delivery emerging
In the United States, ATSC has endeavored to use HbbTV and OIPF functionality where possible for interactivity. The Open IPTV Forum has defined an end-to-end solution to allow any OIPF-compliant consumer device to access enriched and personalized IPTV services, either in a managed or a non-managed network, using a standardized user-to-network interface (UNI). ATSC 2.0 has now introduced the concept of nonlinear OTA file-based content, which the standard calls non-real-time (NRT) content. NRT brings numerous business opportunities to broadcast television. The simplest of these is an ancillary program service, where programmers can break out of the “multicast” paradigm and supply a huge library of programs to the viewer. This includes personalized, on-demand content, as well as supplemental information about current content, like in-depth stories and sports stats on a viewer’s favorite players. NRT also makes it possible to push content and related information to other devices in the home, by embedding special triggers in the broadcast stream.
Advertising content can be similarly augmented by additional interactive information, and can be made easier to use by incorporating demographically targeted and telescoping ad services, where an interactive overlay on a TV commercial provides extended messaging about a product or service, on demand. Other interaction opportunities include automated or user-defined bookmarking, allowing viewers to come back to a certain spot in a program, and broadcast triggers will allow automatic program recording, as well as recording a broadcast while an interactive path is being utilized.
Interactive polling and voting can provide feedback to live content production, and opted-in monitoring of active service usage can provide a new metric toward audience measurement. With many of these new services, content will need to be (re-)packaged, and entirely new content will need to be produced that is closely tied to the “traditional” content, including more extensive program guides that can integrate both the OTA and broadband content delivery paths.
NRT is currently envisioned as supporting three service categories:
- The Browse and Download service essentially provides content “ordering,” with the content to be downloaded later, similar to VOD.
- The Push service provides an ongoing automatic update of previously requested content, similar in function to an Internet RSS news feed, where the user has stored a profile or list of desired content types.
- The Portal service is similar to Internet browsing, where information “pages” and other content are downloaded, stored and available to the user, with low latency, usually in near real time.
Although the NRT content essence is produced and controlled by the broadcaster, the look and feel of both the Browse and Download service and the Push Service is totally at the discretion of the receiver manufacturer, who will typically integrate the navigation screens to be consistent with the user interface. Unlike the other two categories, the on-screen appearance of the content provided in a Portal service is defined by the declarative content itself, i.e., metadata within the content that describes its presentation.
Provisioning screen real estate is a critical issue to program producers and providers, who place a high premium on keeping viewers attached to a particular program. Although NRT services need not be associated with real-time programming, programmers who wish to keep the central content in view can shrink the broadcast window, or allow other images and windows to share screen space — all under broadcaster constraint and control.
ATSC 2.0, now headed for Candidate Standard status, will provide the following features on top of today’s NRT:
- Connections between live TV and both NRT and Internet content;
- Triggered downloadable/declarative objects (TDO);
- Personalization (preferences, demographics, interests);
- Advanced content and codec types; and
- Second-screen capabilities.
TDOs enable interactivity
A TDO is a downloadable software object created by a content creator or service provider. TDOs typically have declarative content (e.g., text, graphics, scripts and audio) that is related to the television programming that they enhance. The TDOs are sent from a service provider in the broadcast stream and stored in the DTV receiver. At a later time, one or more triggers will be sent in the broadcast stream, signaling the DTV receiver to carry out a certain action. Triggers can typically contain various instructions to the receiver, such as activation time or coordination with a second screen, as shown in Figure 1. With this functionality, content can be made available on the second screen that enhances the content on the main stream.
Figure 1. A triggered declarative object (TDO) could be used to push content to a second screen.
Receiver manufacturers will be expected to provide users with a means for identifying both NRT capability, as well as the presence of NRT content in a broadcast. Different receivers will likely provide different levels of functionality, including support for different codecs and file formats, such as AVC at different levels, AC-3, HE-AAC, DTS-HD, and so forth. For that reason, an NRT Baseline Capabilities Receiver Profile has been defined, and fixed broadcast and mobile NRT receivers must have available at least 16GB of persistent storage for downloaded NRT content. Browser profiles are another means of specifying device-particular functionality, and receivers that do not recognize certain elements, e.g. a specific media type, are expected to bypass (or hide) that content item in a graceful way.
Competing in a media-rich world
Ultimately, file-based content delivery can provide the capability to define a consumption model that is “scripted,” in which declarative content provided by the service provider establishes the “look and feel” of the user’s experience of the service. With various groups actively developing a next-generation broadcast system, interactivity is expected to become an integrated part of broadcast offerings, enabling broadcasters to better compete with the rich world of multimedia content delivery.
—Aldo Cugnini is a consultant in the digital television industry and a partner in a mobile video services company.
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.