by Jan van der Meer
Philips Sound and Vision
Eindhoven, The Netherlands
In the last years Internet services and Digital TV broadcast services are becoming successful on the market place. Internet services offer a Hugh variety of information, to be accessed as interactive applications on a PC. Digital TV broadcast initially focuses on distribution in the digital domain of traditional television services consisting of associated real time audio and video. To receive a Digital TV broadcast service currently a Set Top Box is required that can be connected to a TV set. In future TV sets the Digital TV decoding function may be incorporated.
Meanwhile both Internet and Digital TV technologies are evolving further. On Internet, transmission of real time media is getting supported, using the Internet Protocols. For Digital TV services, methods for data transmission are defined; these methods are largely based on MPEG-2 technology. These methods will be used to enhance the more traditional television services by interactive applications. Another use of these methods is tunnelling of Internet data. High bandwidth uni-directional gateways for IP traffic are expected to become available in MPEG based channels that can also be used for Digital TV services; see figure 1. This scenario is specifically attractive in cable network systems.
Figure 1. Tunnelling of IP data in MPEG-2 Transport Streams
As a next step products are expected that support both Digital TV broadcast services and Internet services. Such products offer the very challenging opportunity of migration of Internet and Digital TV interactive applications. The migration may take place on multiple levels :
· on content level. From an Internet application it could be referred to contents delivered within a Digital TV service, e.g. to a video or audio stream or to both. From a Digital TV application it could be referred to Internet contents, e.g. to provide additional information on issues addressed in the ongoing television program.
· on application level. Elements of one application may be distributed; parts of the application may be available on the Internet, while other parts are broadcast within a Digital TV service. As an example, an Electronic Program Guide (EPG) for Digital TV services can be used. In this example a basic EPG application is residently available in the Digital TV receiver, providing the basic functionality for users to navigate through the available TV services. This basic EPG application has the capability to link to other elements of the application. Such other element may be available at Internet, e.g. at the home page of the broadcaster, where information on current and future events is provided, with links to the Digital TV service. Further elements of the EPG application may be broadcast; they could contain more dynamic information in this example. Crucial is that mechanisms are provided that can be used to link all the elements of the application together into one umbrella application.
Products may also support other services and media. For example it may be possible to receive analog television and radio services and to access a CD-ROM. It is therefore suggested to also allow for migration towards other services and media. In this paper opportunities for such migration are discussed. First some relevant requirements for Digital TV receivers are presented.
2. Requirements for Digital TV Receivers
For Digital TV receivers a number of requirements apply that are specifically relevant for the migration of interactive applications coming across Internet or Digital TV broadcast.
· User friendly. Even Granny should be able to use the product. Granny does not understand application failures and does not understand system resources. Therefore it is not possible to ask Granny to avoid application failures by appropriate management of system resources such as Random Access Memory.
· Platform implementation independent API. The interactive applications are to be executed on a variety of products, sharing the same API, but on different platform implementations. On each of these implementations no application failures shall occur. To guarantee the absence of application failures on any platform, a model is required to which both platforms and applications have to adhere; this model has to specify the execution platform on a high abstraction level as well as the usage of platform resources by applications.
· Cost effective. In Digital TV receivers only limited resources are available to support contents; it should be possible to build first generation products with about 1 Mbit of DRAM and 2 Mbit of ROM. In the first generations of Digital TV Receivers it will not be possible to download decoding tools. Therefore in first generation Digital TV Receivers it will not be able to support the dynamics and richness of contents on the Internet. Instead, a fixed subset of Internet contents will be supported. It is expected though that future generations will be able to support a larger and more dynamic set of Internet contents.
3. Support of Internet contents in Digital TV Receivers
For interactive applications in Digital TV receivers a number of proprietary technologies have been defined and one open standard. The open standard is discussed in DAVIC, a consortium supported by over 200 companies from a.o. the broadcasting, computer, consumer electronics and telecommunication industry. DAVIC discusses standards mainly from a system point of view, while focusing on adoption of applicable standards from other bodies. As an example, DAVIC adopted standards from DVB, ATSC and Internet. An important rule for the work in DAVIC is to only define one tool for one (functional) problem, to avoid the need for functional redundancy in DAVIC compliant boxes. On the market place the momentum for adoption of DAVIC standards increases.
Currently DAVIC is the only open platform for discussing Internet support in Digital TV receivers. Therefore this paper focuses on support of Internet contents as currently discussed in DAVIC. In the DAVIC 1.2 specification, to be published in December 1996, support of Internet contents will be defined. In DAVIC, the support of Internet contents will mainly be driven by functional requirements, cost effectivity and perspectives for the future, and less by the desire to support the majority of currently existing Internet content. Note however that it is of course possible to build DAVIC compliant products that fully support Internet browsing.
The DAVIC 1.2 specification is expected to support the following content formats common with Internet :
· text. HTML 3.2 will be supported, including the use of CSS-1. DAVIC will permit the HTML page to contain URL links, thereby allowing links to HTML pages at Internet.
· graphics. As a tool for graphics PNG will probably be supported, though possibly not in its entire richness; a subset may be allowed only.
· photographic still pictures. MPEG still pictures (MPEG Video Intra pictures) will be used.
· compressed video. MPEG-2 Video is applied; note that MPEG-2 Video includes MPEG-1 Video.
· two channel compressed audio. MPEG-1 Audio is used.
· linear audio. To code linear audio AIFF-C is applied without compression.
In general compressed video and audio is represented as real-time stream media. For time base regeneration, for synchronisation and for buffer control the MPEG-2 system standard is applied in DAVIC.
The application format for DAVIC 1.2 is MHEG-5, extended with the JAVA Virtual Machine and a very restricted set of JAVA libraries. In future, a specific set of JAVA libraries for broadcasting will be defined, including support of Service Information (SI) and Conditional Access (CA), as well as a subset of the JAVA libraries used in Internet. As an abstract model of a DAVIC compliant box, a Reference Decoder Model (RDM) is defined by DAVIC. The RDM specifies usage of platform resources by applications. Each DAVIC compliant box has to meet the RDM requirements, while each DAVIC compliant application has to run on the RDM without any failure.
4. Support of Digital TV services in Internet
Currently Internet does not support references to contents transmitted in Digital TV broadcasts. Therefore it is suggested to extend the URL mechanism with the capability to refer to real-time audio and video streams or other data transmitted in Digital TV services. This mechanism should be extended further with the capability to link to analog television and radio services and to other media such as CD-ROM. Incomplete examples of possible URL links are given below :
dvb://canal-plus/original-network-id. program-id.video-id ........
In URL references to broadcast streams or events it is suggested to include the option to indicate the date and timing of the broadcast event, e.g. :
... /date/start-time/end-time/ ...... .
When referencing to audio and video data from Internet applications no specific requirements from Digital TV receivers do apply. However, if the application is also to run in Digital TV receivers, the requirements imposed on Digital TV applications are to be met, i.e. :
· only references should be made to contents supported in Digital TV receivers (other contents will be ignored in Digital TV receivers)
· the contents has to meet the constraints defined for Digital TV (e.g. on maximum picture size)
· the application has to execute on the Reference Decoder Model
There is a major opportunity for migration of Internet and Digital TV applications. To make the migration happen, it is required to define a common domain in Internet that is shared by Internet and Digital TV applications. This domain should include a light weight version of HTML with a number of content formats and should support URL links to Digital TV services and preferably also to other services and media. Each application within the common domain can be executed on a PC and on a Digital TV receiver. In order to avoid any application failure each application in this domain has to meet a number of constraints as defined for Digital TV applications.
In future it is expected that the common Internet / Digital TV domain can be enlarged, but user friendliness, and specifically the absence of failures of applications remains a major issue. For this purpose the modelling of execution platforms and usage of execution platform resources by applications needs further extension.