INTERAKTIVE INFORMATIONSVERTEILUNG IM DIGITALEN FERNSEHSTANDARD MHP. John-Michael Feist

Transcription

1 INTERAKTIVE INFORMATIONSVERTEILUNG IM DIGITALEN FERNSEHSTANDARD MHP John-Michael Feist

2 Technische Universität München Fakultät für Informatik Diplomarbeit INTERAKTIVE INFORMATIONSVERTEILUNG IM DIGITALEN FERNSEHSTANDARD MHP John-Michael Feist Aufgabensteller: Betreuer: Prof. Dr. Johann Schlichter Dipl.-Inform. Univ. Bernhard Kurz, TUM Dipl.-Ing. (FH) Andreas Brefort, Institut für Rundfunktechnik Abgabedatum:

3 ERKLÄRUNG Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den John-Michael Feist

4 ABSTRACT Digital Video Broadcasting enables a three to fourfold increase of television broadcasting capacities. Thus not only further programs but also additional interactive services may be offered, which allow users to enhance their current passive way of watching TV. In order to break up the popular vertical markets and loosen the strong commitment to a set-top box, network system, broadcaster and content provider, common data formats and open APIs are necessary which can be supported by all of them. MPEG-2 is a basis for transfer and compression of video, audio and additional data. DVB, a group of over 200 manufacturers, broadcasters and network providers, is the European digital TV system, which uses MPEG-2. It is enhanced with many capabilities, like service information, which enables the reception of event descriptions, or data broadcasting, which enables online services on the TV, broadband internet and the download of interactive applications. MHP, the Multimedia Home Platform, is another standard defined by DVB, which enables Java applications, so called Xlets, to be run on MHP terminals. Such an application has many possibilities to retrieve content carried by its channel. This diploma thesis deals with some of the most fundamental APIs used within MHP, which enable access to broadcast channel protocols.

5 CONTENTS 1 Introduction Motivation Task Overview The Broadcast System MPEG Coding Transport Stream, Multiplexing Demultiplexing Sections PSI sections DSM-CC U-N Download Data Carousel U-U Object Carousel Associations and mappings between the layers Summary Digital Video Broadcasting (DVB) Sections Object Carousel MHP Sections Profiles Object Carousel Summary The Target System The platform DVB decoder cards Requirements from the Specifications Tuning API Introduction John-Michael Feist Page i

6 4.2 API-Design Implementation Test Objective What has been tested and how? Results Conclusion Section Filtering API Introduction API-Design Implementation Test Objective What has been tested and how? XML XSL Transformations Application of XSLT to generate Java code Back to tests Results Conclusion DSM-CC API Introduction API-Design Low-level U-N Download Data Carousel Classes Mid-Level U-U Object Carousel Classes High-level API classes Implementation Test Objective What has been tested and how? Results Conclusion DVB MPE API Introduction API-Design John-Michael Feist Page ii

7 7.3 Implementation Test A MPEG Component API 81 A.1 Introduction A.2 API-Design A.3 Implementation B Resource Notification API 84 B.1 Introduction B.2 API-Design B.3 Implementation B.3.1 An application uses a resource B.3.2 Application releases a resource B.3.3 Another application wants to reserve a resource B.3.4 System forces a release B.4 Test B.4.1 Objective B.4.2 What has been tested and how? B.4.3 Results B.4.4 Conclusion Bibliography 96 John-Michael Feist Page iii

8 LIST OF FIGURES Number Page Figure 2-1: Overview of MPEG-2 specifications scope... 5 Figure 2-2: Transport Stream syntax diagram... 6 Figure 2-3: A small piece of a transport stream... 7 Figure 2-4: Example use of Program Specific Information Figure 2-5: DSM-CC Model Figure 2-6: Cyclic transmission of information in a data carousel Figure 2-7: Relation of Object Carousel to underlying protocols Figure 2-8: Possible Objects within a Carousel Figure 2-9: Example Object Carousel with a Stream reference to another service Figure 2-10: Encapsulation of U-U BIOP Messages in Modules from Sections Figure 3-1: The DVB-Sat card from Technotrend Figure 3-2: Interfaces between an MHP application and the MHP system Figure 3-3: MHP Broadcast Channel Protocol Stack Figure 4-1: Tuning API Design Figure 4-2: Dependencies between Java, OS and hardware Figure 5-1: Section Filtering API Design Figure 6-1: DSM-CC Section Design Figure 6-2: U-N Download Design Figure 6-3: Most important BIOP Classes and their relations Figure 6-4: DSM-CC API Design Figure 6-5: DSM-CC API Design (continued) Figure 6-6: DSM-CC Download Helper Classes Figure 6-7: UNDownload Class State Chart Figure A-1: MPEG Components API Design Figure B-1: Resource Notification API Design Figure B-2: A possible design of an API using the org.davic.resources package Figure B-3: Application uses a resource Figure B-4: Application releases a resource Figure B-5: Another application wants to reserve a resource Figure B-6: The System forces a release John-Michael Feist Page iv

9 LIST OF TABLES Number Page Table 2-1: Common section header... 8 Table 2-2: Extended section header... 8 Table 2-3: PAT without headers... 9 Table 2-4: PMT without header Table 2-5: descriptors() structure Table 2-6: common descriptor() structure Table 2-7: DSM-CC defined table_id values Table 2-8: DSM-CC U-N Message Header Table 2-9: DSM-CC defined Download messageid values Table 2-10: DSM-CC DownloadInfoIndication message without header Table 2-11: DSM-CC DownloadDataBlock message without header Table 2-12: DSM-CC DownloadServerInitiate message without header Table 2-13: MPEG-2 defined PID values Table 2-14: MPEG-2 defined table_id values Table 2-15: DVB defined table_id values Table 2-16: Further specification of transactionid Table 2-17: MHP defined table_id values Table 3-1: Hardware Limits of TT DVB card Table 6-1: Carousel parameters Table 6-2: Implementation performance Table 7-1: datagram_section without header Table 7-2: Replacement for version_number in datagram_section John-Michael Feist Page v

10 ABBREVIATIONS AND DEFINITIONS API Component DAVIC Delivery System DOM DSM-CC Application Programming Interface Definition of a set of classes and/or methods that provide specific functionality. Synonym for MPEG-2 Elementary Stream (see there) Digital Audio Video Council A non-profit organization with over 200 members from more than 25 countries including manufacturers, broadcasters, government agencies and research organizations with the aim of "promoting the success of interactive digital audio-visual applications and services by promulgating Specifications of open interfaces and protocols that maximize interoperability, not only across geographical boundaries but also across diverse applications, services and industries". The physical medium by which one or more transport streams are transmitted, e.g. satellite, cable or terrestrial system. Document Object Model A "platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents", especially for HTML and XML documents. Digital Storage Media - Command and Control A set of protocols defined by MPEG-2 that may be used to control digital storage media. DSM-CC U-N Download DSM-CC User-to-Network Download Data Carousel Specification of a protocol which allows for cyclic transmission of a data image. DSM-CC U-U OC DVB DSM-CC User-to-User Object Carousel Specifies how a set of objects building a hierarchical structure may be transmitted using the DSM-CC U-N Download Data Carousel. Digital Video Broadcasting European standard for digital video broadcasting and group of manufacturers, broadcasters and network providers. John-Michael Feist Page vi

11 DvbLocator Elementary Stream EPG ETSI HTML HTTP I/O IP JDK MHEG MHP MPEG MPEG-2 Network OC Special kind of an URL which enables the addressing of MPEG-2 transport streams, DVB services, single components, events and parts of an object carousel within a service. MPEG-2 defined format that forms a part of a service. One or more Elementary Streams (also referred to as components) together build a service, e.g. video, audio and teletext. Electronic Program Guide An application that allows an user of a MHP terminal for easy lookup of what is or will be running on which program of a transport stream. European Telecommunications Standards Institute Hyper Text Mark-up Language Hyper Text Transport Protocol Input / Output Internet Protocol Java Development Kit Multimedia Hypermedia Expert Group Multimedia Home Platform A set of specifications for a digital set-top box that defines the reception of digital TV services and applications from a broadcaster. Moving Picture Experts Group Originally a group of experts that produced the MPEG international standards for digital coding moving pictures and associated audio. Also a synonym for these standards. Refers to the standard ISO of the MPEG group. Collection of MPEG-2 Transport Streams transmitted on a single delivery system, e.g. all streams available via one satellite. Object Carousel A set of protocols that allow for a non-flow-controlled John-Michael Feist Page vii

12 repetitive download scenario of a hierarchical file structure that contains MHP applications. OMG ONC OS Program RPC Section Service SI STB TCP TS UDP UI UNO URL VM Object Management Group Open Network Computing Operating System Concatenation of one or more events of a broadcaster, e.g. a news show, entertainment show. Remote Procedure Call Syntactic structure that allows for mapping service information to transport stream packets. Sequence of programs broadcasted as part of a schedule. Service Information Digital data describing the content of transport streams including the delivery system, content, scheduling, time and date etc. (digital) set-top box A black box that allows a user to view digital TV services and run MHP applications. Transmission Control Protocol Transport Stream Protocols that allow simultaneous transmission of several programs from a broadcaster via different media (e.g. satellite, cable, terrestrial). User Datagram Protocol User Interface Universal Networked Objects Uniform Resource Locator Java Virtual Machine John-Michael Feist Page viii

13 1 Introduction 1.1 Motivation In its Digital Broadcasting Initiative Report [GOVDIB] the Government of the Federal Republic of Germany states that by the year 2000 terrestrial "analogue TV transmission networks shall no longer be set up, and existing ones shall no longer be expanded" and that by 2010 terrestrial "analogue TV transmissions are phased out". In the area of transmission via cable and satellite it was decided that digital TV and other innovative services should successively be offered by Besides a higher quality the most important advantage of the digitalisation of transmission frequencies is a three to four-fold increase of capacity and thus the reduction of transmission costs. This increase creates opportunities to transmit new innovative, and particularly multimedia, services. Within these services user-friendliness is especially important: Electronic Program Guides (EPGs) should be provided to help the user find his program. Furthermore proprietary reception systems should be avoided, while open Application Programming Interfaces (APIs) will be necessary. In Europe the digital TV transmission system is DVB (Digital Video Broadcasting, see chapter 2 The Broadcast System), which is based on MPEG-2, and digital programs have been available via cable since 1997 and via satellite since The European Launching Group consists of European broadcasters and consumer equipment manufacturers. In September 1993 they signed a Memorandum of Understanding in which the rules of "this new and challenging game of collective action" were drafted, and the DVB group was formed. Today the group consists of more than 270 organizations including broadcasters, manufacturers and network operators from over 30 countries. The Multimedia Home Platform (MHP) [TAM232] - introduced by the DVB Group - is an open API as requested by the German Government. The first official version was published on April the 17 th, In addition to the comprehensive DVB system toolbox, MHP provides a vendor, author and broadcaster neutral framework for reception and presentation of multimedia applications. It is the first step to cracking the currently existing vertical markets, that cover the whole value chain from the content, over broadcasters to receivers (e.g. Premiere, John-Michael Feist Page 1

14 1 Introduction / Task Canal+). A horizontal market facilitates different contents, applications, broadcasters, networks, and receivers. 1.2 Task In April 2000 the Institut für Rundfunktechnik (IRT) started a reference implementation of the MHP standard with the aim of enabling a regular IBM-compatible personal computer equipped with a DVB receiver card to work as a "virtual" settopbox providing the MHP enhanced broadcast profile. An implementation of the MHP standard on such a platform has many advantages, for example: Easy testing of MHP applications and the system by application developers and equipment manufacturers Porting of the implementation to different hardware and operating systems Standard-conformance The aim of this diploma thesis is the implementation of some of the fundamental APIs for the mentioned configuration. These APIs provide the connection of the broadcast to the MHP system and allow the system and applications to access the broadcast protocols. They enable the retrieval of contents provided by the broadcast including audio, video, data and applications and thus facilitate local user interactivity. 1.3 Overview Chapter 2 The Broadcast System gives a short introduction on the broadcast system beginning with MPEG-2, over DVB to MHP. Chapter 3 The Target System deals with the target platform, requirements of the specifications and the restrictions of the hardware. The following API chapters (and appendixes) are divided into four parts: an introduction to the theme and what this API is used for, the API design which shows the design from the specifications, the implementation showing the inner design and how it is implemented and finally the test part describing the way the API has been tested and the results of the tests. In chapter 4 the Tuning API is developed. It is the most fundamental API in an MHP John-Michael Feist Page 2

15 1 Introduction / Overview terminal since tuning in digital video broadcasting means the selection of a valid MPEG-2 transport stream that carries some services. All other APIs directly or indirectly depend on a valid transport stream. Chapter 5 describes the implementation of the Section Filtering API, which enables a terminal to receive informations of what is on the selected stream (e.g. services and their components, applications). A special part for generating source code from section syntax specifications with XSLT is included. Chapter 6 follows the DSM-CC API which makes it possible to receive the so called object carousels on a stream carrying the applications of a service. Chapter 7 DVB MPE API deals with the possibility of having a multi-protocolencapsulation on a stream that enables the reception of IP data for example. Appendix A MPEG Component API shows how the problem domain aspects of MPEG-2 are encapsulated in a Java API. Appendix B Resource Notification API explains how a MHP terminal has to handle its resources. John-Michael Feist Page 3

16 2 The Broadcast System / MPEG-2 2 The Broadcast System This chapter gives an introduction to the different transport protocols as specified by several documents. It shall help the reader to understand the transmission system, but can only give a certain overview and is surely not complete. Besides this only the parts relevant for this thesis are included. 2.1 MPEG-2 The Moving Pictures Expert Group was originally a group of experts that developed several international standards for digitally coding and compressing audio and video data. Founded in 1988, the group produced the standards MPEG-1 (also known as ISO/IEC 11172, MP3 MPEG Audio Layer 3 is a part of it), MPEG-2 (ISO/IEC 13818) and others. Today MPEG is also used as nickname for these standards Coding The human eye is so slow that it is enough to reduce a permanently moving picture to 25 refreshes per second in order to make us believe to recognize a continuous movement (then we call it a "movie"). In analogue television all the 25 snapshots of that picture are transferred. Since most of those snapshots only differ in small pieces this is a total waste of capacity. This is what the Moving Pictures Expert Group uses besides data compression and encoding in their MPEG-2 specification [ISO ]. A today's normal TV picture would require a bandwidth of about 160 Mbit/s. By using the MPEG-2 format, a normal video picture can be reduced to approximately three to five Mbit/s (videos with a high percentage of movement like sports need up to eight Mbit/s to have the same quality). It is obvious that a digital broadcast channel has the capacity to transport multiple digital TV programs. The exact encoding and compression procedure is explained in [ISO ] for video and [ISO ] for audio. The format of the data transmitted over a digital medium may be either a transport stream or a program stream (see [ISO ]). A program stream can carry only one program consisting of multiple elementary streams, that have a common time base, over a reliable medium. Since the task is to receive broadcasted MPEG-2 programs which normally have different time bases, only the Transport Stream is explained in John-Michael Feist Page 4

17 2 The Broadcast System / MPEG-2 the following section. As shown in Figure 2-1 the audio/video specifications cover the encoding mechanisms required to reduce the size of the data, and the system specification deals with the packetizing and multiplexing of encoded data. Video Data Video Encoder Packetizer Video PES PS Program Audio Data Audio Encoder Packetizer Audio PES Mux Stream TS Transport Stream Mux Extent of A/V Specification Extent of Systems Specification Figure 2-1: Overview of MPEG-2 specifications scope Transport Stream, Multiplexing A MPEG-2 Transport Stream may carry multiple programs with independent time bases over unreliable media. It is a packet-oriented multiplexed bit stream with rates up to 60 Mbit/s. Figure 2-2 shows three packets of a transport stream and the syntax of the headers of one packet. These packets have a fixed length of 188 bytes and allow for more or less simultaneous transmission of several programs. As the data is carried in a single bit stream, which is able to carry exactly one bit at the same time, there is not a real parallel transport of the programs. Instead every program carried by a transport stream first of all has to be encoded (to reduce its size). After that all programs are divided into those very small transport stream packets and put together one after the other John-Michael Feist Page 5

18 2 The Broadcast System / MPEG-2 while mixing the components of the programs depending on their bit rates and priority so that conformant receivers are able to decode them. This process is called multiplexing. transport packet stream 188 bytes header payload header payload header payload sync byte transport error indicator payload unit start indicator transport priority PID transport scrambling control adaptation field control continuity counter adaptation field adaptation field length discontinuity indicator random access indicator elementary stream priority indicator flags 5 optional fields stuffing bytes PCR OPCR splice countdown transport private data length transport private data adaptation field extension length 8 3 flags 3 optional fields ltw_valid flag ltw offset piecewise rate splice type DTS_next_au Figure 2-2: Transport Stream syntax diagram Every transport stream packet has an unique identifier the 13 bit wide PID that associates it with an elementary stream (the fifth field in the figure). Within a transport stream these are called packetized elementary streams (PES). An elementary stream contains either video, audio or additional data which is identified by its stream type. A program (also called service) usually consists of several components, e.g. a video and some audio components and possibly additional data components, that are represented by elementary streams. Figure 2-1 not only shows the scope of the MPEG-2 specifications, it also depicts a possible data flow from uncoded video and audio sources to a transport stream. However it does not provide a very typical scenario, as normally several encoders and packetizers are used as sources for a transport stream multiplexer so that the stream carries several programs. The picture may even hide another unit, which is responsible John-Michael Feist Page 6

19 2 The Broadcast System / MPEG-2 for generating the required additional signalling data (see following section). The output of a transport stream multiplexer may look as given in Figure 2-3, which includes three programs consisting of video and audio components (packets named "V" and "A") and two additional packets (a PSI packet and a data packet, see next sections). The headers of a packet are named "H". Note that the time needed to transport these 16 packets may be less than half a millisecond. 1 packet H V1 H V1 H A1 H V1 H V1 H PSI H V2 H V2 H A2 H V2 H V2 H D3 H V3 H V3 H V3 H V3 time Figure 2-3: A small piece of a transport stream Demultiplexing Multiplexing makes it possible to broadcast several programs in one transport stream. In order to show one program to the end-user, receivers need to know about what services are on a transport stream and which components a service consists of. This is called Program Specific Information (PSI) which is carried by so called sections (see the following section). With this information a receiver is able to demultiplex a transport stream and decode some of the encoded elementary streams. Each component is associated with a PID of an elementary stream and with those values a transport stream parser may forward matching transport stream packets to the decoding units (this is called demultiplexing), which have to interpret them and be able to restore the original format (this is called decoding, e.g. for video or audio) Sections Sections are the key to identify the contents of a whole transport stream. They provide informations such as the availability of programs including their elementary streams (components), the broadcaster, the nature of the network, events and so on. A section is a form of additional data and is encapsulated in the payload of transport stream packets. It contains any data valid for its table_id, an 8 bit value used to distinguish between different types of sections. The syntax of section data is described in tables that show the fields and the structure, the number of bits and the format of each field (either uimsbf which means unsigned John-Michael Feist Page 7

20 2 The Broadcast System / MPEG-2 integer most significant bit first or bslbf which means bit string least significant bit first). Section data is transferred according to the following scheme: Every section has a common header (see Table 2-1) that contains the most important table_id, the length of the section after the common header and a syntax- and private_indicator. Syntax No. of bits Identifier table_id 8 uimsbf section_syntax_indicator 1 bslbf private_indicator 1 bslbf reserved for future use 2 bslbf section_length 12 uimsbf Table 2-1: Common section header When the section_syntax_indicator in the common header is set to '0', the data of the section immediately follows after the last header field and its size is section_length bytes. The syntax then depends on the table_id of the section. When the section_syntax_indicator is set to '1', the following bytes have the syntax as shown in Table 2-2. In this case the payload of the section only has (section_length-9) bytes and is between the last_section_number field and the CRC_32 field, which contains a 4- byte checksum of the whole section (excluding the CRC-field) based on a cyclic redundancy check. The maximum overall size of a section may not exceed 1024 bytes including all headers and the optional CRC field. Syntax No. of bits Identifier table_id_extension 16 uimsbf reserved for future use 2 bslbf version_number 5 uimsbf current_next_indicator 1 bslbf section_number 8 uimsbf last_section_number 8 uimsbf data() (section_length-9)*8 CRC_32 32 rpchof Table 2-2: Extended section header The table_id_extension may be used to divide the limited table_id further. The ex- John-Michael Feist Page 8

21 2 The Broadcast System / MPEG-2 tended header allows to build tables of sections with the same table_id and table_id_extension by using the section_number field as index and the last_section_number + 1 as the number of sections a table consists of. Each section may have a version_number and current_next_indicator. These two fields enable a decoder to coordinate with changes in a transport stream. A private section has the same structure as described above, while the private_indicator field of the header is set to '1'. The special thing about it is, that the structure of the data following the common header or in between the extended header is not officially specified and that the whole section may have a maximum size of 4096 bytes. The section syntax definitions in the specifications mainly use the extended section header and therefore often speak of tables instead of sections. Two table definitions are absolutely necessary to be interpreted by decoders and are therefore explained in more detail in the following section PSI sections After having tuned to a transport stream a decoder needs to know about what services are available on that stream. Syntax No. of bits Identifier for(i=0; i<n; i++) { program_number 16 uimsbf reserved 3 bslbf if(program_number == '0') { network_pid 13 uimsbf } else { program_map_pid 13 uimsbf } } Table 2-3: PAT without headers This information is encoded in the so called program association table (PAT), a list of sections with a table_id of zero that is transported in the PID zero. It contains a mapping (see Table 2-3) of service-ids (also called program_number) to the PID of their program map table (PMT) and optionally the PID of a network information table John-Michael Feist Page 9

22 2 The Broadcast System / MPEG-2 (NIT), that describes which transport streams are available on the same media as the currently selected transport stream. The table_id_extension field in the extended header contains an ID of the transport stream (transport_stream_id). The program map table (PMT) of a service (see Table 2-4) contains the service-id (in the table_id_extension of the extended header), points to its Program Clock Reference (PCR), which carries time stamps and represents the common time base for all of the service's components, and lists the service components, that is the PIDs and stream types of the elementary streams the service consists of. Syntax No. of bits Identifier reserved 3 bslbf PCR_PID 13 uimsbf descriptors() for(i=0; i<n; i++) { stream_type 8 uimsbf reserved 3 bslbf elementary_pid 13 uimsbf descriptors() } Table 2-4: PMT without header In such tables often a structure named descriptors() occurs (shown in Table 2-5), which consists of a length field and a list of variable length descriptor structures as described in [ISO ]. These are used to describe the section content in more detail, for example in a PMT the aspect ratio of a video component, the language of an audio stream or the content of a data stream can be specified further. Syntax No. of bits Identifier reserved 4 bslbf descriptors_length 12 uimsbf for(i=0; i<n; i++) { descriptor() } Table 2-5: descriptors() structure The structure common to all descriptors is shown in Table 2-6. Like in the common section header the first byte is used to identify the type of the following data bytes. If an unknown type is received the descriptor_data is simply interpreted as an array of John-Michael Feist Page 10

23 2 The Broadcast System / MPEG-2 descriptor_length bytes. The descriptor_tag field only allows specific values, that are listed in the specifications. Syntax No. of bits Identifier descriptor_tag 8 uimsbf descriptor_length 8 uimsbf descriptor_data() Table 2-6: common descriptor() structure Figure 2-4 gives an example of how PSI is used to point to services carried in a transport stream and their components. The components themselves are elementary streams and divided into transport stream packets (see example in Figure 2-3). Services Components PAT [Program 0: NIT] Program 1: PMT1 Program 2: PMT2 Program 3: PMT3... Program n: PMTn Points to PMT1 Compon. 1: PID1 Compon. 2: PID2 PMT2 Compon. 1: PID1 Compon. 2: PID2 V1 A1 V2 PMT3 Compon. 1: PID1 Compon. 2: PID2 Compon. 3: PID3... Compon. n: PIDn A2 V3 A3 D3 Dn Figure 2-4: Example use of Program Specific Information DSM-CC Digital Storage Media (DSM) Command and Control (DSM-CC, [ISO ]) specifies a huge set of protocols which provide the control functions and operations specific to managing bit streams. These protocols may be used to support applications in both stand-alone and heterogeneous network environments. In the DSM-CC model, a stream is provided by a Server and delivered to a Client. Both the Server and the Client are considered to be Users of the DSM-CC network. DSM-CC defines a logical entity called the Session and Re- John-Michael Feist Page 11

24 2 The Broadcast System / MPEG-2 source Manager (SRM) which provides a (logically) centralized management of the DSM-CC Sessions and Resources (see Figure 2-5). As in a broadcast scenario there is no Session or Resource Manager, only the user-touser connections are applicable that is from the broadcaster seen as a server user to the settopbox seen as a client user. Furthermore only the download protocol set is used in order to download applications from the broadcaster and the communication between them is one-way only (from server to client). Connection (User to User) SERVER USER User to User NETWORK SRM* CLIENT USER User to User User to Network User to Network User to Network Connection (User to Network) Figure 2-5: DSM-CC Model All DSM-CC data is encapsulated in so called DSM-CC messages. Several message types exist for each application area. Transport in Sections When DSM-CC data needs to be transported via a transport stream, this is done using the so called DSM-CC section format. It is a specialization of the MPEG-2 private section and is described in [ISO ] Chapter 9. The extensions to a private section are that the extended header is always present, that a section_syntax_indicator of '0' indicates the replacement of the CRC-32 by a 32 bit checksum, and that only the table_ids 0x3A to 0x3E are allowed. Table 2-7 shows the mapping between the different table_id values and the content. The encapsulation of multi-protocol data is described in chapter 7 DVB MPE API. A section carrying Stream Descriptors is needed, when an application requires a kind of John-Michael Feist Page 12

25 2 The Broadcast System / MPEG-2 synchronization with the stream it comes from. A Stream Descriptors structure looks like the normal descriptors shown above, but only certain descriptor types defined in chapter 8 of the DSM-CC specification may be included. One of these descriptors signals StreamEvents, which can be used by broadcasters in order to trigger their applications running on a Settopbox. table_id DSMCC Section Type 0x3A Multi-protocol encapsulated data 0x3B U-N Messages, except Download Data Messages 0x3C Download Data Messages 0x3D Stream Descriptors 0x3E Private data Table 2-7: DSM-CC defined table_id values When using the table_id 0x3E the structure of the payload of the section is user defined and it is called a DSM-CC private section. The two remaining table_id values are required for downloading as described in the following section. U-N Download Data Carousel Chapter 7 of the DSM-CC specification explains how data or software can be downloaded from a server (here a broadcast server) using the User-to-Network Download protocol. A data broadcast is a one-way communication and requires a kind of cyclic transmission of the content, since the medium is not 100% reliable. Thus only the Data Carousel scenario is applicable and described here. In order to carry a complete image of the data or software that should be downloaded to clients, this image is divided into modules and each module into several blocks. All blocks of all modules in one image have the same size, except for the last block of each module which may be smaller, and one block must not contain data from more than one module. The messages used by a download are divided into control and data messages (see Figure 2-6: control messages are represented by ellipses and data messages by rectangles). The control messages carry informations about the download process which includes a list of modules, an image or part of an image consists of. A single data message contains one data block of one module. John-Michael Feist Page 13

26 2 The Broadcast System / MPEG-2 M8-0 M8-1 M8-2 M8-3 M3-2 M3-1 M3-0 M2-0 block_size cycle_time M2: file1 M2_size M3: file2 M3_size M8: file3 M8_size M8-4 M8-5 M8-6 M8-7 M8-8 download data message (MX-Y): DownloadDataBlock () X = module_id Y = block_number download control message: DownloadServerInitiate () and DownloadInfoIndication () Figure 2-6: Cyclic transmission of information in a data carousel The example shows the partition of a data image consisting of three files each carried in one module, which are divided into up to 9 blocks (depending on the size of each module). The control messages here are only sent once per cycle. Syntax Bytes protocoldiscriminator 1 dsmcctype 1 messageid 2 transactionid 4 reserved 1 adaptationlength 1 messagelength 2 for(adaptationlength>0) { dsmccadaptationheader() } Table 2-8: DSM-CC U-N Message Header Both, control and data messages are divided into a header and their payload. Table 2-8 shows the common header syntax. John-Michael Feist Page 14

27 2 The Broadcast System / MPEG-2 The most important fields in the header are the dsmcctype, which specifies the type of the message (here: 0x03 for a Download Message), the messageid (see following table) and the transactionid, which associates control and data messages. Table 2-9 shows the relevant messageids for the Download Data Carousel scenario. Message Name DownloadInfoIndication DownloadDataBlock DownloadServerInitiate messageid Description: Server... 0x1002 provides download parameters 0x1003 sends one download data block 0x1006 requests initiation of a download Table 2-9: DSM-CC defined Download messageid values The transactionid is normally used to correlate messages between a client and the server. In the broadcast scenario the message flow is one-way only and thus the transactionid has a different meaning. Here it is used as a versioning mechanism and shall be constant as long as the message contents remain unchanged. When the contents change, the transactionid field shall be incremented modulo the transaction number range. The first two bits of this field represent the transactionid originator. In this scenario these shall be set to the value 0x02, indicating that the broadcaster (server) assigns the id. The remaining transaction number covers 30 bits. Table 2-10 shows the syntax of the DownloadInfoIndication message. The most important fields are the downloadid, which is used to uniquely identify a download process, the blocksize which denotes the "normal" size of the blocks within the modules (except the last block of each module which normally is smaller), the number of modules and a list of modules including their id, size and version. Each module and the DII message itself may have additional data (in the moduleinfo and privatedata fields) with contents specified by higher level protocols. The DownloadDataBlock message as shown in Table 2-11 contains the data of one block of a module and thus the number of the block within a given module number and version. Note that the header of a data block message contains the downloadid instead of the transactionid listed in the table above. It shall have the same value as the downloadid field in the module s DII message. John-Michael Feist Page 15

28 2 The Broadcast System / MPEG-2 Syntax Bytes downloadid 4 blocksize 2 windowsize 1 ackperiod 1 tcdownloadwindow 4 tcdownloadscenario 4 compatibilitydescriptor() numberofmodules 2 for(i=0;i< numberofmodules;i++) { moduleid 2 modulesize 4 moduleversion 1 moduleinfolength 1 for(i=0;i< moduleinfolength;i++) { moduleinfobyte 1 } } privatedatalength 2 for(i=0;i< privatedatalength;i++) { privatedatabyte 1 } Table 2-10: DSM-CC DownloadInfoIndication message without header Syntax Bytes moduleid 2 moduleversion 1 reserved 1 blocknumber 2 for(i=0;i<n;i++) { blockdatabyte 1 } Table 2-11: DSM-CC DownloadDataBlock message without header Table 2-12 shows the syntax of the DownloadServerInitiate message. This message is used to indicate the start of a download process to a client by providing the location of the DownloadInfoIndication messages. Its usage is optional as in the broadcast sce- John-Michael Feist Page 16

29 2 The Broadcast System / MPEG-2 nario, where the messages are transported via sections, normally the DII messages are on the same elementary stream as the DSI message. Syntax Bytes ServerId 20 compatibilitydescriptor() PrivateDataLength 2 for(i=0;i<privatedatalength;i++) { PrivateDataByte 1 } Table 2-12: DSM-CC DownloadServerInitiate message without header The serverid of the DSI message contains the servers NSAP address and the private- Data field may again be used by a higher level protocol in order to specify further parameters. U-U Object Carousel When a broadcaster wants to give clients access to a set of objects such as files, directories and stream references, the appropriate format is an User-to-User Object Carousel. It is a set of messages that define the contents (like file data or directory structure) and additional attributes (e.g. version of a file). Figure 2-7 shows the relation of an U-U Object Carousel defined by Chapters 11 and 5 of the DSM-CC specification to the underlying Download Data Carousel on top of a lower level protocol. API U-U Object Carousel Download Data Carousel DSM-CC Sections Broadcast Network Figure 2-7: Relation of Object Carousel to underlying protocols The lower layer protocol here are sections carried in a transport stream (the "Broadcast John-Michael Feist Page 17

30 2 The Broadcast System / MPEG-2 Network") as described in the previous section. The specification of the messages that carry the object carousel is compatible to the Object Request Broker framework as defined by CORBA [CORBA] and defines the Broadcast Inter-ORB Protocol (BIOP) which enables references to objects located on a MPEG-2 transport stream. Within the context of object carousels the so called Service Domain represents all objects included in one carousel. It has a globally unique identifier, the NSAP address, which is used to distinguish between several object carousels. This address uniquely identifies a broadcast network by the triple transport_stream_id, original_network_id and service_id and a carousel, which has to be unique within a broadcast network, by its carouselid. Objects within a Service Domain are referenced by Interoperable Object References (IOR) as defined by CORBA. A BIOP defined IOR holds either a BIOP ProfileBody, when referencing an object within the same carousel, or a LiteOptionsProfileBody for objects located on a different carousel. The latter contains a DSM ServiceLocation component, which includes the full NSAP address of the other carousel and the path name of the object within that carousel (DSM is a shorthand for Digital Storage Media and like BIOP depicts a package name in this context). The BIOP ProfileBody contains two mandatory LiteComponents, a BIOP ObjectLocation and a DSM ConnBinder. An ObjectLocation uniquely locates an object within a broadcast network by providing a carousel ID (which is unique within a broadcast network), a module ID (unique within a carousel) and an object key (unique within a module). A ConnBinder contains a list of so called Taps that provide references to a particular network connection by a TapUse value, an associationtag and tap specific values. One TapUse value, that is allowed within the ConnBinder, is the BIOP_DELIVERY_PARA_USE. This Tap indicates the connection of the DIIs that provide the delivery parameters for the module containing the object the IOR points at. An association tag points out one service component. When the PMT of the service carrying the object carousel contains a deferred_association_tag descriptor matching the association tag in question, the descriptor points out another service which includes that tag. Otherwise the LSB of the association tag holds the component tag within the service and thus locates the elementary stream carrying the data. In order to get the contents of a Service Domain, an entry point is needed. This is the root directory and it is signalled by a Service Gateway which has the same structure as a Directory. The Service Gateway Location is provided by the IOR in the Ser- John-Michael Feist Page 18

31 2 The Broadcast System / MPEG-2 vicegatewayinfo structure carried in the private data field of an U-N DownloadServer- Initiate message. The relations between the possible objects included in a carousel are shown in Figure 2-8. A Directory contains a list of Bindings which hold an IOR and thus point to an object, which is either a Stream, StreamEvent, File or Directory. The StreamEvent extends a Stream and both include a list of Taps that point to either one elementary stream, a whole transport stream, a connection that provides stream events or others. Note that the Tap mentioned in the paragraph above is not shown in the diagram, because it is not applicable to the list of Taps included by a Stream or StreamEvent object. Figure 2-8: Possible Objects within a Carousel Figure 2-9 shows an example Object Carousel including Stream and StreamEvent message, which may point to components of the service carrying the carousel (including components carrying DSM-CC StreamEvents) or to a whole other service. Not that the colours indicate the module in which a group of objects is carried (compare to Figure 2-6). John-Michael Feist Page 19

32 2 The Broadcast System / MPEG-2 File Directory ServiceGateway root File Directory Directory File Object Carousel of Service A File Directory Directory File Stream (reference) Stream+Events (references) File StreamEvents Service A Audio, Video and Data Components Service B Figure 2-9: Example Object Carousel with a Stream reference to another service Figure 2-10 depicts the encapsulation of U-U Object Carousel BIOP messages in a U- N Download Data Carousel module, the module s partition into Data Blocks and the transfer of the blocks in DSM-CC sections. One section carries exactly one data block, several data blocks build a module and one module in turn may contain several BIOP messages. It holds however exactly one message, when the message exceeds a specific size limit. Object Carousel: BIOP messages Download Data Carousel : Message Headers and SubHeaders Obj-1 (Directory) Obj-2 (File) Module-1 Obj-3 (ServiceGateway) Modules and Blocks Download DataBlock Headers Block-1 Block-2 Block-3 Block-4 Block-5 DSM-CC Sections Section-1 Section-2 Section-3 Section-4 Section-5 Section Headers Figure 2-10: Encapsulation of U-U BIOP Messages in Modules from Sections The BIOP Messages have a common Header and SubHeader, which hold an objectkey (related to a BIOP ObjectLocation), an objectkind which is used to distinguish be- John-Michael Feist Page 20

33 2 The Broadcast System / MPEG-2 tween different message bodies and an objectinfo with attributes of the object (depending on the kind). The body of a BIOP Message depends on the objectkind field, which may have the following values: "dir" or "DSM::Directory" The payload contains a list of Bindings which hold a name, type (either a file or a directory) and an IOR of the referenced object. "fil" or "DSM::File" The payload contains the raw data of the file in bytes. "str" or "DSM::Stream" A list of Taps pointing to one transport stream or multiple elementary streams within one transport stream are carried by the payload. "srg" or "DSM::ServiceGateway" The message payload contains the same structure as a Directory message, but this one points out the gateway of the Service Domain, i.e. the root directory of the carousel. Associations and mappings between the layers As shown in the previous sections, the acquisition of an object carousel happens through a set of three layers (protocols) each depending on the lower one. Between these layers certain associations are given: Object Carousel: BIOP Messages Transported in Download Data Carousel Modules, where the carouselid equals the DDB/DII downloadid, the moduleid equals the DDB/DII moduleid. The DII transactionid equals the transactionid in Taps with a use of BIOP_DELIVERY_PARA_USE (e.g. in the DSI message). Download Data Carousel: Modules divided into blocks Transported in DSM-CC Sections (DSI, DII, DDB) on the PIDs specified in DSI/DIIs (by associationtags) with specific table_ids. The DII moduleversion equals the DDB moduleversion. DSM-CC Sections: Transported in transport stream packets with a common PID and two possible table_ids. John-Michael Feist Page 21

34 2 The Broadcast System / MPEG Summary As the whole decoding process is normally done by a hardware unit, the most important informations required to retrieve a section out of a transport stream are the packet and table identifier values. Value Description 0x0000 Program Association Table 0x0001 Conditional Access Table 0x0002-0x000F reserved 0x0010-0x1FFE available for ES, PMT, NIT, private 0x1FFF Null packet Table 2-13: MPEG-2 defined PID values Table 2-13 shows the PID values and ranges which are defined by MPEG-2. The valid range for elementary streams, program map, network information and private sections is 0x0010 to 0x1FFE. Value Description 0x00 PAT 0x01 CAT (conditional access) 0x02 PMT 0x03-0x39 reserved 0x3A DSM-CC MPE 0x3B DSM-CC U-N except Download Data 0x3C DSM-CC U-N Download Data 0x3D DSM-CC Stream Descriptors 0x3E DSM-CC private sections 0x3F reserved 0x40-0xFE user private 0xFF forbidden Table 2-14: MPEG-2 defined table_id values Table 2-14 shows the table_id values and ranges for sections defined by MPEG-2. The user private table_ids are not defined by MPEG-2 and may be used by other specifications. John-Michael Feist Page 22

35 2 The Broadcast System / Digital Video Broadcasting (DVB) 2.2 Digital Video Broadcasting (DVB) DVB is the digital TV system used in Europe and is based on MPEG-2 (see previous section). DVB defines some constraints and enhancements on the underlying MPEG-2 system (see [ETR154] and [EN300468]), these include: MPEG-2 Transport streams are used for satellite, cable and terrestrial networks Service Information is based on MPEG-2 PSI Conditional access is possible The service information is strongly enhanced compared to MPEG-2 PSI. The following section shows more details Sections Table 2-15 lists the DVB defined table_id values that are in the range of MPEG-2 user private. The tables provide informations about the physical organization of the transport streams (NIT), bouquet allocation (BAT, groups services to so called "bouquets"), service description (SDT), events contained in a service (EIT), time and date (TDT), local time offset (TOT), running status of events (RST) and other less interesting information. Besides these tables 38 descriptors are defined in addition to the MPEG-2 defined ones. These are explained in [EN300468]. John-Michael Feist Page 23

36 2 The Broadcast System / Digital Video Broadcasting (DVB) Value Description Fixed PID 0x40 NIT actual network (network information) 0x0010 0x41 NIT other network 0x0010 0x42 SDT actual TS (service description) 0x0011 0x43-0x45 Reserved 0x46 SDT other TS 0x0011 0x47-0x49 Reserved 0x4A BAT (bouquet association) 0x0011 0x4B-0x4D Reserved 0x4E EIT actual TS, present/following (event info.) 0x0012 0x4F EIT other TS, present/following 0x0012 0x50-0x5F EIT actual TS, schedule 0x0012 0x60-0x6F EIT other TS, schedule 0x0012 0x70 TDT (time and date) 0x0014 0x71 RST (running status of events) 0x0013 0x72 ST (stuffing) 0x73 TOT (time offset) 0x0014 0x74-0x7D Reserved 0x7E DIT (discontinuity) 0x001E 0x7F SIT (selection information) 0x001F 0x80-0xFE user defined Table 2-15: DVB defined table_id values Object Carousel Periodic broadcasting of DSM-CC User-to-User objects (see section above) is enabled by the DVB Object Carousel that depends on the DSM-CC Object Carousel, Download Data Carousel and transport of Download Data messages in DSM-CC sections. In addition signalling of an object carousel by including special descriptors in the PMT of a service is defined (see [TR101202]). The transactionid of U-N Download messages is further specified according to the following Table Whenever an object has to be changed on the server (broadcaster) side, the module containing it has to be updated. Thus the version of the module has to be increased, which is reflected in the module list in its DII message, which also has to be updated. Whenever a DII changes its content, the version and updated parts of its transactionid have to be increased. John-Michael Feist Page 24

37 2 The Broadcast System / MHP Thus, a receiver that wants to get informed of changes in an object carousel, actively has to listen for the DII messages the carousel includes. Bits Value Sub-field Description 0 Userdefined 1-15 Userdefined Userdefined Bit 30: 0 Bit 31: 1 Updated flag This must be toggled every time the control message is updated Identification This must and can only be all zeros for the Download- ServerInitiate message. All other control messages must have one or more non-zero bit(s). Version Originator This must be incremented/changed every time the control message is updated. Defined by DSM-CC as 0x02 if the transactionid has been assigned by the network - in a broadcast scenario this is implicit. Table 2-16: Further specification of transactionid The moduleinfo field of the DownloadInfoIndication message contains a BIOP ModuleInfo structure. This structure allows the specification of the connection on which the module is transported by including Tap with the BIOP_OBJECT_USE value. The ModuleInfo also includes a list of descriptors which may contain a compressed_module descriptor. Such a descriptor signals the compression of a module to a receiver. 2.3 MHP The specification of MHP [TAM232] has been set up by DVB and depends on the DVB broadcasting system as explained in the previous section. MHP extends a terminal with the possibility to receive and present applications independent of the author, vendor or broadcaster by including and defining several data and API specifications. The API specifications include important parts of DAVIC [DAVICp9], an organization which already finished its work on specifications for interactive digital audiovisual applications. These APIs provide an abstraction of transport streams and their services, mechanisms to handle scarce resources and allow access to a wide range of DVB and MPEG defined broadcast protocols and their encapsulated data (e.g. sections). Furthermore DVB has specified a huge set of APIs for the management of applica- John-Michael Feist Page 25

38 2 The Broadcast System / MHP tions, their download and triggering via DSM-CC, interactivity via return channels, security, service information, user preferences and user interface issues. MHP restricts and enhances the DVB system in many aspects. Especially the download of applications in object carousels and the signalling in sections and descriptors are described here. Note that the DVB members permanently find mistakes or at least sections that may be misunderstood in the MHP specifications. These issues are maintained in a corrigenda database [TAM610], which currently spans more than 2000 items. About a quarter of them have been rejected, another quarter are still open and over 1000 items have been accepted or already implemented in further versions of the MHP specification Sections MHP defines an additional section shown in Table 2-17 and descriptors that may occur within this section only. Value 0x74 Description AIT Table 2-17: MHP defined table_id values The application information section (AIT) lists DVB-J (Java) and DVB-HTML applications which are carried by a service and may be available to the user. For each application a unique identifier, a control code (including autostart, present, destroy and kill), the applications profiles (see next section), its visibility, priority, location (identifying the component that carries the DSI), name and optionally the file name of its icon are provided Profiles By now the application areas of an MHP terminal are split up into three profiles at different levels with the following features (currently only level one of each profile is defined): John-Michael Feist Page 26

39 2 The Broadcast System / MHP Enhanced Profile 1: Broadcasted downloadable applications may enable local interactivity. Interactive Profile 1: Enhanced profile with interactive services that require a return channel. Internet Profile 1: Internet and broadcasted services (does not automatically include the enhanced or interactive profile) Object Carousel The download of an application by a MHP terminal is based on the DVB object carousel specification (see section above). Such a carousel needs to be signalled correctly in the PMT of a service by including a data_broadcast_id_descriptor with an ID of 0x00F0 (MHP Object Carousel) in the descriptor loop of an elementary stream containing the DSI message. An application that shall be started from an object carousel needs a transport_protocol_descriptor in its AIT, which refers to a component_tag pointing to such an elementary stream. Exactly one carousel_id_descriptor shall be included in the descriptor loop of such a stream, and thus one elementary stream may carry only one object carousel. However an object carousel may be distributed over several elementary streams, that do not need to be within the same service, by using the concept of Taps (introduced by DSM-CC) used in object references (including the Service Gateway Info). In order to mount a carousel, first of all the DSI has to be acquired and interpreted. It points to a service component carrying the DII with the parameters necessary to download the module containing the ServiceGateway object. Optionally a carousel_id_descriptor may support the so called "enhanced boot mechanism" by providing all the information found in the DSI and DII messages necessary to locate the ServiceGateway. Using this mechanism the acquisition of the ServiceGateway is faster than with the standard DSI/DII mode, because theses steps can then be skipped. The serverid value in DSI messages is not used in a MHP object carousel, as the servers address shall not be available to the receiver. The ModuleInfo field within a DII message may contain additional descriptors that are used for prefetching and caching of that module. Three different levels of caching are defined. The BIOP FileMessage and a Binding of type file in a Directory- or ServiceGateway- John-Michael Feist Page 27

40 2 The Broadcast System / MHP Message allow the inclusion of attributes like the file size and its content type, which are necessary for DVB-HTML applications Summary Besides the broadcasting specific data aspects described above, MHP provides a huge set of application programming interfaces which may or have to be used by a MHP terminal or applications broadcasted in a MPEG-2 transport stream in order to manage applications, handle scarce resources, switch between streams, access parts of a transport stream via sections, display user interfaces and handle user input. The most fundamental APIs that provide access to transport protocols are described later. John-Michael Feist Page 28

41 3 The Target System / The platform 3 The Target System This chapter deals with the restrictions and features of the target system, the currently available DVB receiver cards with their capabilities and limitations, as well as with requirements from the specifications. 3.1 The platform The target platform for this project is a today's standard IBM-compatible personal computer with Microsoft Windows NT 4.0 as the primary operating system. In a second step Microsoft Windows 98 SE and optionally Linux shall be supported. This platform was chosen because it is one of the most common Java development systems used today and is expected to be the favourite of developers of MHP applications. Reference Implementation Guidelines Java is the programming language in the MHP environment. In order to reach a highly platform independent implementation, it was decided that every functionality which may be provided by a Java implementation shall be developed in Java. In order to keep the resulting classes as secure as possible, no API-defined Java class shall be modified in its signature, that is no public or protected method (including constructors) or variable may be added. Additionally new classes that are not officially part of an API but have to reside in an API s package, shall have a name starting with "IRT", so that they can be easily distinguished from API classes. Additional classes that may reside in a different location shall be placed in the package "de.irt.mhp" or a sub-package. Thus it is possible to assure, that an application may not call methods beside the ones defined in an API. When the implementation of an API allows adjustable items these shall be configurable in property files, so that they can be easily changed without recompiling the classes. Therefore global system-wide properties are available through methods in the central class "de.irt.mhp.settopbox" which reads these properties from the file "MHP.system.prop" located in the class path. John-Michael Feist Page 29

42 3 The Target System / DVB decoder cards For development and test of the different APIs the following configuration has been used: Intel Pentium II 350 MHz 128 MB RAM SCSI Hard discs Siemens DVB-s card attached to a local satellite network providing access to the Astra satellites on 19.2 east orbital position. For testing purpose the DVB-T card from Technotrend has also been used for a short duration. Windows NT 4, Service Pack 5 Microsoft Visual C Service Pack 3 (native compiler) Sun JDK (Java compiler and runtime environment) Borland JBuilder 3.5/4.0 (Java IDE) TogetherSoft Together 4.2 (Java case tool for UML design) 3.2 DVB decoder cards Figure 3-1 shows a picture of the DVB-s card distributed by Siemens (see [SIDVB], [SIDVBMan]), Hauppauge, Galaxis and other resellers. This card is one of those manufactured by Technotrend each with the same architecture as will be described later. This diploma thesis only supports cards out of the Technotrend DVB series as other cards were either not available at project launch or too expensive. The most important chip on this card is a digital signal processor (DSP), the Texas Instruments TMS320AV7110 (see [TMS320]), which incorporates a MPEG-2 video decoder, a MPEG-1 audio decoder, a NTSC/ PAL video encoder, an on screen display (OSD) controller and many other features. It has an embedded ARM CPU and high speed data interfaces for communication with other peripherals. This chip is also used in the Nokia Mediamaster, a Settopbox for digital television. John-Michael Feist Page 30

43 3 The Target System / DVB decoder cards Figure 3-1: The DVB-Sat card from Technotrend For the PC platform access to the signal processor is provided through a multimedia PCI-Bridge, the Philips SAA7146A (see [SAA7146]), which is the central unit for any driver of the operating system to access the DSP or one of the other chips on the card via an I 2 C-Interface and/or a high speed bus. It has also the possibility to scale the video input from the DSP and directly write the content to the frame buffer device of the PC through DMA (direct memory access). Besides the DSP, two Mbit of DRAM, the PCI-Bridge, and some less interesting chips, the card holds a tuner which is responsible for driving the attached receiving equipment and a frontend that does the demodulation, forward error correction and analogue to digital conversion. On the satellite card the tuner is a Mitel SP5659 and the frontend is a ViSTA VES1893 Satellite Channel Receiver (see [VES1893]). In the meanwhile cards with such a design are also available for terrestrial and cable reception and normally only differ in the tuner and frontend chips and some surrounding discrete components. Because of the hardware design shown above, most of the drivers (see [TTDVBDrv], [SIDVBDrv], [LinuxTV]) have a centralized architecture as every status change in the DSP has to be sent through the bridge. Windows drivers for this family of DVB cards are available from Technotrend John-Michael Feist Page 31