ITV Catches Fire

Interactive TV is happening. Many of us remember companies (although we can’t quite remember their names) trying mightily to convince us that interactive TV was the wave of the future at NAB conventions of around a decade ago. There are now some different approaches, and some of them are beginning to bear fruit. As an example, it would appear that ordering a pizza via interactive television is a smashing success!

The term "interactive television" means different things to different people, and potential applications are still the subject of discussions. In order to accomplish such things as e-commerce (t-commerce?) or game-playing, certain functionalities are required to be incorporated into the TV receiver or set-top box. There must be a mechanism to import data, and from it to generate active video overlays on the TV screen.

In the case of pizza-ordering, this mechanism would be some virtual buttons to be pushed via a remote control or some such device, along with some text and graphics to depict the choices available. The orderer must be able to somehow type in some text telling the virtual pizza shop where to send the pie and how payment is to be made, and there must be some kind of return channel to get that information back to the virtual pizza chef (pizza server?). There are, of course, any number of other applications for interactive TV, but the pizza example illustrates the principles.

NTSC television was not designed to accommodate interactivity as described above. It was not designed to accommodate closed captioning either, but we have managed to include captioning in NTSC quite successfully. Some of the functionality required for interactivity can be incorporated in the same way: by modulating the lines of the vertical blanking interval with digital data.

MIDDLEWARE AND PROTOCOLS

The processing of interactive applications requires a software system to decode the incoming data, process it, cause the right things to happen on the screen, process the viewer’s responses and send the responses back via the return channel. In the NTSC case, several approaches to implementing the required functionality have settled into a standard set of platform-independent "middleware" and protocols defined by the Advanced Television Enhancement Forum, known as ATVEF.

Any given receiver or set-top box has a proprietary operating system that makes it function. Platform-independent middleware sits on top of the operating system and makes it appear to the interactive application that a common receiver is being used, regardless of what the make, model or flavor of receiver really is – somewhat analogously to the way a Web browser in a computer functions.

ATVEF is a consortium of companies that has established a standard set of interactive protocols and middleware that rely on standardized components. Let’s take a look at how it works.

CONTENT PROTOCOLS

The content protocols of ATVEF are largely based on Internet standards developed by the WWW Consortium, known as W3C. HTML and related formats are used for the presentation of text, graphics, embedded video, embedded audio and other multimedia content. This is so-called declarative content. Declarative information is information that is expressed in the form of assertions, for example, text such as abc.

Another fundamental type of content is procedural content. Procedural information is information that is expressed in the form of procedures, for example, do A, then do B, then do C. A procedural application’s core entity is a specific type of active object content, for example, a Java applet, which may consist of Java code in conjunction with other multimedia content such as graphics and streaming video and audio.

An application need not be purely declarative or purely procedural. Declarative applications often make use of script, which is itself procedural in nature, and a procedural object may be embedded in a declarative application.

Conversely, a procedural object may reference declarative content such as graphics, and may itself construct and display HTML-type content. ATVEF only supports declarative content at this juncture.

ATVEF TYPES

Although there is nothing to prevent its use in DTV, ATVEF was developed for analog television systems, and it may be carried in the VBI of either NTSC or PAL signals. Two types of ATVEF transport are defined.

Transport Type A consists solely of "triggers" that cause things to happen. In NTSC, these triggers are sent in the "Text 2" portion of the EIA 608 closed-captioning signal. Only triggers are sent via the broadcast path, and content is fetched using a two-way Internet connection.

In Transport Type B, both triggers and content are sent on the broadcast path and stored in the receiver, along with announcements that inform the receiver of what content is available. The triggers of the Type A transport are slow EIA 608 triggers, while the triggers and data content of the Type B transport are the fast NABTS teletext format, and may use multiple VBI lines.

While the Type A triggers are carried in Line 21 data and may therefore be recorded on a home VCR and utilized while the program is played back, Type B content and triggers are on other VBI lines and cannot be recorded on a home VCR. The two types of transport may be mixed.

Broadcast television does not have any inherent return path, and in the ATVEF world, the return path may be an Internet connection or a telephone connection. Cable TV systems do increasingly have the capability to provide a return path.

Interactivity using the ATVEF tools is available today, and a number of television programs employ it. If you went out and bought an interactively enabled set-top box, you could be playing along with game shows, and probably interactively ordering pizzas by next football season!

The interactive middleware for the ATSC DTV system is called DASE, for the DTV Application Software Environment. The DASE standard is currently under development.

Additionally, other DTV systems of the world, such as the European DVB and the Japanese ISDB system, as well as the U.S. OpenCable standards, have their own approaches to interactivity. Next month, we will take a look at how those DTV interactivity systems are shaping up. n

Randy Hoffner is manager of technology and strategic planning at ABC, New York, N.Y. The views expressed in his column are his own, and not necessarily those of ABC. Write to him c/o TV Technology.