ITV Handbook: Technologies and Standards

iTV receivers have an architecture that combines that of a digital TV receiver and a personal computer (see Figure 4.1). The architecture of the receiver, often referred to as the iTV platform architecture, includes a CPU, a Real-Time Operating System (RTOS), a disk, a file system, drivers, as well as MPEG transport decoders, video decoders, and sophisticated multiplane graphics chips that support hardware alpha blending. A necessary evil is the conditional access module which enables service providers to filter out content the viewer does not subscribe to. The receiver expectations (and requirements) listed here were collected by the author as part of the effort to define ATSC DASE requirements, which included comparison with DVB MHP.

4.1.1 Upgradability

Evolution of the business environment and consumer desires may drive rapid evolution. As an example, MP3 music went from total obscurity to a nationwide rage in just one year. Imagine that a consumer bought a $1000 computer in 1999, expecting a three to five year service life and then discovered that they were locked out of MP3 capability, the hottest new feature of 2000.

iTV receivers are developing an installed base gradually, a process that might last a decade . That means there will be significant gaps in capability between next year's receivers and those of, say, 2008. There are limits to how many receiver variations can be supported by content authors in their day-to-day work. There will be pressure by advertisers and broadcasters to support the newest look and features, as is the case with broadcast video. There will also be pressures to create content quickly and at low cost. Receiver upgradability can ensure that iTV receivers are viable for the consumer expected life-span.

Because iTV receivers are far more complex than any previous generation of receivers, subtle incompatibilities arising from different implementations of the standard are likely. Unless iTV receivers can accept software upgrades, these incompatibilities will bedevil content authors for years .

To reduce the devastating effect of incompatibilities, software components could be downloaded using a broadcast transport stream, (e.g., MPEG DSM-CC carousels) or through a return channel (e.g., using an Internet connection). Broadcast downloads are performed by extracting upgrade files from a broadcasted file system (see Chapter 11). Return channel downloads, possibly over the Internet, are performed through access to a model-specific URL that provides access to model-specific upgrade files. Both means of update could enable a live-update feature, whereby receivers are automatically upgraded when an upgrade is available (similar to live-updates of antivirus software). Such capability is anticipated to be required by some standards, including OCAP.

4.1.1.1 Temporary Platform Independent Plug-Ins

Plug-ins are software components that can be downloaded into already deployed receivers and executed to enhance its functionality. Platform independent plug-ins are those utilizing some standard APIs. Transient plug-ins are those whose life-cycle is bound to the content, usually having a life-span bounded by the TV program within which they are used.

One type of temporary platform independent plug-ins are content decoders, which are software components that are capable of decoding and rendering content packaged in well-defined formats. For example, to display the content of an MPEG-4 file, or a Flash animation file, there is a need to download an MPEG-4 or a Flash content decoder. In another example, to render content written in various markup languages, such as ARIB's BML or legacy HTML, there is a need to download the appropriate content decoder for each format.

Transient downloadable content decoders are similar to Java applets commonly found on the Web. These are small programs transmitted with the content, usually embedded within markup pages. These decoders are flushed once the content that they decode is no longer of interest. Such content decoders could be automatically downloaded and launched.

4.1.1.2 Unbounded Platform Independent Plug-Ins

The life-cycle of unbounded plug-ins is not bound to content. They are downloaded, rendered persistent, and registered with the receiver to enable future use. When needed, these plug-ins could be automatically downloaded and launched. The installation and use of such plug-ins should be made with adequate protection against common security threats.

Such plug-ins could be used to implement persistent content decoders. They are valuable to broadcasters as they need not be retransmitted with the content they decode, thus saving precious bandwidth. They are valuable to receiver manufacturers as they relieve them from including with the receiver support for a wide range of content types.

The use of such plug-ins typically raises a number of issues, including the decoupling of the delivery of the plug-ins from the content, the appropriate life-cycle management of such plug-ins, and mapping of plug-ins to content types. As an example, some expect the plug-in needs of an application to be identified automatically, so as to download the appropriate plug-in seamlessly. Due to the on-demand pull nature of this operation, such a download is best done over the Internet, from publicly accessible URLs.

4.1.1.3 Middleware Upgrades

Middleware upgrades enable updating the middleware of receivers. These enable adoption of new API standards without technology upgrade implications to broadcasters, because the files containing code are opaque to broadcasting equipment. Such upgrades enable features such as localizing the input and display methods , as well as extending receivers with accessibility features.

Middleware upgrades could also be utilized to download monitor applications, which enable remote management of receivers with broadband connections. Remote receiver management and monitoring applications are often useful when consumers call service centers regarding problems with their receiver.

4.1.1.4 Persistent Platform Specific Features

Beyond platform independent plug-ins, it is possible to download platform specific components into deployed receivers. Such capability serves the following purposes:

• Bug fixes : Manufacturers could fix bugs discovered after products are deployed; this may be critical as receivers will have sophisticated operating systems. As an example, it will be possible to download and install service packs upgrading both the operating system and the native applications.

• Support evolution of standards : It is expected that iTV standards will evolve much faster than TV broadcast standards have traditionally evolved. As an example, DVB MHP has released version 1.1 soon after version 1.0 was completed.

• Render optional features standard : Features that are initially optional due to lack of content could become standard. Without persistent plug-in capability, the only upgrade method available is transient plug-ins, which need to be repeatedly broadcast, downloaded, and discarded.

Due to existing infrastructure and business models, the download of platform-specific plug-ins is likely to be viable only through a return channel (e.g., using an Internet connection). Although downloads of upgrades or plug-ins could be performed via broadcast, this would require massive national coordination of a multi- broadcaster , multi-manufacturer, multi-product, and multi-generation upgrade transport. A more reliable approach would be to use return channel communication to periodically check a manufacturer's database for upgrades. This periodic connection also gives the manufacturer an invaluable opportunity to provide targeted information to a consumer who has a proven track record of buying the manufacturer's products.

4.1.2 Remote Interactivity

Some interactive TV applications need to perform bidirectional communication with a remote server or service provider to process transactions and other types of remote services. Such interactivity enables TV-commerce and can be performed by various means. For example, T-commerce could be performed through fax-orders, modems, coupon printing, reading and writing smart-cards, and possibly performing transactions through pagers or other devices. This includes enabling iTV viewers to purchase and download music or other nonstreaming media content, rendering the content persistent, and allowing other applications to use the purchased content. Applications need to use module names to query the platform (preferably through the middleware) to determine which subset of these TV-commerce means is available, or condition its execution by the availability of a subset of these means.

It is expected that TV-commerce will be inconsistent with the existing TV broadcasting model according to which broadcasters are fully responsible for content on their channels. Due to various complexities, it is anticipated that code may be packaged and repackaged on its way from the author to the consumer using various encapsulations . Other issues arise when transactions are performed by code that is loaded from the Internet or other resources that are not controlled by broadcasters. The code loaded must not harm the receiver. Content loaded over an Internet connection should be consistent with the policies of the broadcaster making reference to that content. Therefore, the remote interactivity and transactions should be performed with adequate protection against common security threats.

4.1.3 Persistence

The term persistence in iTV refers to the ability to allow content (software code is also regarded as iTV content) to reside within an iTV receiver beyond the completion of programs, and usually to survive power-down periods. Content that is made persistent can be loaded rapidly from local storage to be used as part of live programs. It can be broadcast or downloaded once and reused numerous times.

A storage management module should be used to manage (e.g., allocate, deallocate) persistent storage space (e.g., disk space) for all data that is rendered persistent. This includes video clips, audio clips, and software applications. Two major persistence models are possible:

• Broadcaster-controlled : The life-cycle of an application (e.g., its launch and termination) is controlled by signals transmitted in some broadcast. This model enables broadcasters to preload large applications and data outside of prime time (e.g., at night). Subsequently, those applications can be brought to life by sending short signals or precursor applications used as triggers. This enables, for example, downloading a set of advertisements once per week, and replaying them a number of times without repeated retransmission.

• Viewer-controlled : The life-cycle of an application is controlled by the receiver's implementation on behalf of the viewer. This model enables viewers to purchase software delivered over-the-broadcast or through a return channel. The viewer pays to obtain a key which is used to install and register the application. Viewers may have the reasonable expectation that they can use the application any time they want, without depending on the presence of an appropriate signal in the broadcast.

These two persistence models are not mutually exclusive and could be combined. Persistent applications may have some features controlled by broadcasters, and other features controlled by the viewer. As an example, viewer-controlled applications may have embedded advertisement slots, each of which is controlled by a broadcaster. In another example, play-along game applications may have live play-along features controlled by a broadcaster, and, at the same time, have practice features that are controlled by the viewer.

4.1.4 Distributed Delivery across Multiple Networks

Interactive TV applications may be delivered using multiple networks. For example, applications divided into uniform and custom portions need to be delivered in two phases: In the first phase, the uniform portion is pushed into the iTV receiver. In the second phase, the custom portion of these applications is pulled from the Internet using a return channel. This is sometimes referred to as the push-pull model.

Receiver implementations and the applications they execute need to locate and retrieve resources on a best-effort basis from multiple delivery systems such as multiple broadcast channels and a return channel. For example, a markup application could make references to images that some broadcasters may wish to include in their transport stream to improve QoS. The receiver needs to automatically detect which files (that the application needs) can be retrieved from the broadcast and which files need to be retrieved from the return channel (see Figure 4.2; the arrows labeled reference indicate reference URIs). If a file appears in the broadcast before it is retrieved from the return channel, then the receiver should stop waiting for, and ignore the response of, the completion of the file access request through the return channel. The retrieval route needs to be determined transparently without the need for coordination with the content author, and requires decoupling of transport configuration from the application layer. Specifically, this means that names of files should not depend on the method by which they are accessible. Because file downloads may require long periods of time, receivers should track which file is acquired from where.

The utility of multiroute download is the ability to utilize each transport medium for the task for which it is most appropriate. As an example, content applications may be partitioned into common and custom portions. Common portions could be delivered via uniform broadcasts, offering almost instantaneous simultaneous download and subsequent access. Customized portions (which are different for each viewer) could be pulled over the return channel, possibly from the Internet, offering each individual a personal custom code (e.g., account information). A great pressure is expected to develop personal applications that contain customization hooks that enable referring to objects that could be delivered over the return channel.

4.1.5 Time Sensitive Presentation of Content

Interactive TV applications need to synchronize the presentation of content with various transport and program events. These events may occur as content arrives in the broadcast channel or through the return channel. Events may also occur during the execution of an application as a result of user input of unexpected circumstances, namely exceptions.

Time sensitive presentation of content includes the capability to control insertion of advertisements without allowing their removal and to enable execution of applications delivered through delayed retransmission such that the assumptions made by the application author hold. As explained later, this requirement can be satisfied using synchronized triggers, Synchronized Multimedia Integration Language (SMIL), and Java Media Framework (JMF).

4.1.6 Multiple Applications

iTV content is authored and packaged in applications. Interactive TV receivers are expected to support the concurrent execution of multiple applications. Specifically, they need to allow some applications to run in the background while other applications are interacting with the viewer. Often this could be achieved by multi-threading alone, but typically, multiple processes are used. The implications, however, are the need to minimally support an input focus model, limited resource management, event dispatching, and inter-application communications. A viewer input focus manager should ensure that applications interacting with the viewer (e.g., collecting order or payment information) are not interrupted by other applications (e.g., advertisements).

Generic resource management should ensure that applications are informed about availability of resources and do not interfere with each other. Use of resources, such as graphic display and return-channel bandwidth, should be carefully managed. Typically, data written by one application should neither be modifiable nor accessible to other applications without appropriate security precautions . Therefore, inter-application communications is important to allow reuse of content produced by affiliated authors while avoiding repackaging application boundaries.

An event dispatching model should ensure that the appropriate applications receive the events, and that no applications are starved preventing them from processing the events they should receive. Challenges exist when background and foreground applications are running concurrently.

4.1.7 Sophisticated Graphics

The home entertainment market is different from the PC-based market in that there is an expectation for well-designed synchronized graphics and animation resulting in very high-quality viewer experiences. Receivers and standards should be designed with high-quality graphic integration in mind. This includes sophisticated effects tightly synchronized with audio, video, animation, and animated transitions.

One technical aspect distinguishing iTV graphics from traditional computer graphics is the graphic display model, which consists of several separate planes, each having its own pixel format (see later discussion on the display model). As an example, the pixel format of the video, namely the width and height of each pixel as well as the total number of pixels in each direction, is different from the pixel format of the graphics produced by an application. Further, the relative location of the video plane and the application graphics plane is configurable.

High-quality 3D graphics present yet another challenge as there is likely to be strong demand to utilize recent advances in 3D animation (e.g., embedded in movies) as part of iTV programs. The difference between graphics achieved by replaying videos of 3D animation (e.g., in PIXAR movies), and graphics achieved through sophisticated 3D hardware and software (e.g., in games ), is real-time scene rendering customization. The more the receiver can do the better personalized the scene (and story) is. Modern game machines already deliver real-time interactive 3D renderings of scenes that track the viewer's actions. However, the quality of animation observed by computer-based 3D animation movies made off-line is still far beyond what will be practical to provide in real-time games. iTV programs relying on 3D animations should reside somewhere in between low-quality animation of real-time games and high-quality animation of off-line movies.