A MHP Conform Software Implementation ofa DVB Service Information Decoder

Artur LUGMAYR (1), Chengyuan PENG (2), and Seppo KALLI (1)(1) DMI/TTKK, P.O. Box 553, Hermiankatu 3 A, FI-33101 Tampere, Finland

(2) TML/HUT, P.O. Box 5400, FI-02015 HUT, Finland

Abstract. A generic system reference model for digiTV systems, consists of a broad-cast service provider, interactive service provider, interaction network, broadcastingnetwork, several interfaces and the end-user [6]. The broadcast channel represents aunidirectional broadband broadcast channel including video, audio, and service infor-mation. A bi-directional interaction channel is established between the user and theservice provider for interaction purposes [3]. One major integral part of a DVB streamisProgram Specific Information (PSI)andDVB Service Information (DVB- SI), the firstdescribing the delivery system structure and the latter describing its multimedia con-tent. This research paper presents a fully DVB/MHP compliant SI decoder, based on aMPEG2 TS, that can be retrieved from various sources, such as a satellite receiver card,a file, or from a real-time Internet stream based on the transmission protocols RTP andUDP. Furthermore, this paper gives an overview of the MHP compliant implementationand – to conclude - performance test and usage scenarios are presented.

1 Introduction

The implementation is based on the European key standard for digiTV - theMultimedia HomePlatform (MHP)[8] as published by theEuropean Broadcasting Union (EBU)- covering mul-tiple issues, such as specification of interfaces visible to applications, integrated TV receivers,multimedia hardware, communication protocols, recommendations, feedback and interactioncontrol, broadcasting, etc. It is relying on appropriateDigital Video Broadcasting (DVB)speci-fications for digital video broadcast and associated interactive services. The MHP is applicableto all DVB defined transmission media and networks such as satellite, cable, terrestrial andmicrowave [8]. It compromises various standards, where the following are required in thescope of this research paper: 1)Digital Audio-Visual Council (DAVIC) 1.4 Specification Part9: Information Representation[5] defines various monomedia information types, includingcharacter, text, fonts, service information, audio, video, graphics, minimum tools and dynamicbehavior required by digital audio-visual systems for end-to-end interoperability across coun-tries, applications and services [5]; 2)DVB: Specification for Service Information (SI) in DVBSystems (ETS300468)[2] describing the structure of service information in DVB compli-ant systems; and 3)Generic Coding of Moving Pictures and Associated Audio: Systems[1],standardizing MPEG2 as transmission medium for audio, video, and multimedia content.

2 SI Structure and its Transmission

SI is organized in frequently sent tables (approx. every 15 ms) and contains firstly informationabout the structure of the MPEG2 stream multiplex (PSI) [1] and secondly additional contentdescriptors that are MPEG2 private section syntax conform [1] (DVB- SI) [2]. Each table isfirstly segmented into one or multiple sections of the length 1024 or 4096 bytes and afterwardssplit to be fitted into one or more TS packets of size 188 bytes each. Each section is uniquelydefined by: 1) its section number, used for reassembling the table; 2) version number, identi-fying updated versions of this table; and 3) table identifier, identifying the table to which thisparticular section belongs.

2.1 Description of SI Tables and its Decoding Process

The Program Association Table (PAT - PID 0x00)provides the correspondence between aprogram number and the PID value of the TS packets carrying the program definition. Theprogram number is the numeric label associated with a program [1]. TheConditional AccessTable (CAT - PID 0x01)provides the association between one or more CA systems, theirstreams and any special parameters associated with them [1]. TheProgram Map Table (PMT)provides the mappings between program numbers and the program elements that compromisethem. Thus, the PMT is the complete collection of all program definitions for a simple TS [1].TheNetwork Information Table (NIT - PID 0x10)conveys information relating to the physicalorganization of the multiplexes/TSs carried via a given network and the characteristics of thenetwork itself. Through the combination of two fields in the NIT section (original network idand transport stream id) each TS can be uniquely identified [2]. TheBouquet Association Table(BAT - PID 0x11)provides information regarding bouquets, where a bouquet is a collection ofservices, which may traverse the boundaries of a network [2]. TheService Description Table(SDT - PID 0x11)is divided in sub-tables. Each sub-table of the SDT describes services thatare contained within particular TS. The services may be part of the actual TS or part of otherTSs, these being identified by means of the table id [2]. TheEvent Information Table (EIT -PID 0x12provides information in chronological order regarding the events contained withineach service [2]. TheTime and Date Table (TDT - PID 0x14)carries only the UTC-time anddate information [2]. TheTime Offset Table (TOT - PID 0x14)carries the UTC time and dateinformation and local time offsets [2]. TheRunning Status Table (RST - PID 0x13)allowsaccurate and rapid updating of the timing status of one or more events [2].

Table 1: Atomic Accessible Units and their properties processed and passed to higher layers of each parsingstage. The software modules are described in Section 3.

Atomic Unit Identifier Size Software Module

Byte Stream TS ID * HardwareTS Packets PID (13 bit) 188 byte (184 payload) FirmwareSections Section ID 1024 or 4096 bytes MiddlewareTables Table ID * Middleware

Descriptors Descriptor Tags max. 256 bytes MHP SI Access API

The first essential task at decoder side is to demultiplex PAT and CAT tables, where byutilizing this information PMTs (the services included in the TS) can be decoded. The other

tables have own PID numbers and can be decoded and assigned to each service simultaneously.The content of each table are descriptors, uniquely identified by a descriptor tag, that describeservices and events more detailed. As an example, the content descriptor provides classificationinformation for an event contained in the EIT.

2.2 Transmission of SI

Usually SI is encapsulated within a MPEG2 stream and transmitted as a whole over a broadbandnetwork to the receiver side. Enough research work has been done in this direction, but oneopened issue is how SI could be separately casted over various protocol solutions to realizeVideo on Demand (VoD) in the house television streaming solutions.

Various protocol encapsulation schemes are possible for transmitting SI over the Internet,where one or multiple atomic units can be encapsulated in the payload of each transmissionunit. This idea is based on the DVB Protocol Layer model as introduced in [6] and extendedwithin the scope of this research paper. Each transmission unit contains one or multiple sec-tions, tables, or descriptors to be transferred. Each atomic unit provides its own identificationscheme and decoding information, therefore no additional information has to be provided andencapsulated within each packet. At client side the MPEG2 defined structures can be utilizedto parse the transmitted data. To shift demultiplexing to a centralized SI decoder server, min-imizes network bandwidth utilization due to less header overhead of each transmission unit;optimises client’s performance, as the main performance of demultiplexing is done by theserver; and reduces bandwidth consumptions, as the frequency of sending SI can be reduced.Additional the client has to be provided by a certain mechanism to be able to choose andretrieve audio and video streams that also have to be transmitted separately.

TheUser Datagram Protocol (UDP), overlaying theInternet Protocol (IP), can be facil-itated to encapsulate SI in its payload with a minimum protocol mechanism. For transmissionmultiple solutions are possible: 1) encapsulation of one or more TS packets containing atomicunits of SI in UDP packets; 2) transmission of SI elementary streams to separate ports tothe client; 3) encapsulation of SI in one UDP stream and forwarding it to one port of theclient; 4) descriptor based encapsulation, where descriptors are encapsulated in UDP packetsand forwarded to one or multiple UDP ports, each retrieving different types of descriptors,on client’s side. The drawbacks of utilizing UDP as SI transmission protocol are ambiguous:no synchronization and packet loss recognition mechanism is provided, but also not neededas SI is transmitted on a high frequency basis, and even if jitter occurs within certain timeboundaries, the decoder is able to demultiplex SI within appropriate time delays.

RTP transmissions, relying on UDP and IP, provide a more adequate approach of trans-mitting SI over the Internet, as it provides payload type identification, sequence numbering,time stamping, delivery monitoring, synchronization, and including audio and video streamsin an more sophisticating manner than UDP. The transmission of a whole MPEG2 stream isalready defined in RFC 1890, therefore only RTP protocol extensions for the transmissionof SI will be considered in the scope of this section: Similar to UDP transmission aPurePayload Based Encapsulationallows to encapsulate one or more atomic units in each RTPpacket. The timing model of MPEG2 is used - therefore synchronization is problematic, asnot every atomic unit provides timing information. APayload Based Encapsulation Basedon Separate Packetizationof SI’s atomic unit streams relies on the SI structure and reducespacket dependencies and maximizes data output. At the beginning of the payload of each RTP

packet, the header of the atomic unit can be found, therefore a not too small size of atomicunit should not be considered, as it would cause too much header overhead. Synchronizationand timing is RTP based. ThePayload Based on Joint Packetizationallows the combination ofseveral SI streams to be sent to one port at the receiver’s side. An encapsulation of audio/videowould also be possible to evolve to a complete integrated in-house TV on-demand solution.

3 Implementation

The intention was to provide a complete MHP conform implementation of a SI decoder, basedon Java as programming language. To involve C++ as native interface language was inevitabledue to performance lacks of the Java programming language and as parts of the hardwareaccess functionality provided by hardware manufacturer was implemented in C or C++.

(a) Software Layer Model for DVB SI Demul-tiplexing.

(b) Flow Model of the System (SFG-SectionFilterGroup, SF-Section Filter).

Figure 1: Software Layer Model and Flow Model of the Implementation

The software implementation of the SI decoder is based on a generic software layer model(as shown in Figure 1(a)), that allows multiple configurations of sources for SI and is capableof retrieving SI in different atomic units from a network adapter, data storage, or satellitereceiver card, compromising the modules of theFirmware Layer. TheData Access Layerisresponsible for retrieval process control, latching the byte stream, decapsulation of payload,providing different stream access modes, and an appropriate - TS source hiding - unifiedsoftware interface to higher layers. The latter has the main responsibility of theLow LayerResource Access APIs, that should make the TS source invisible to higher layers and handleseveral resource management tasks. TheMiddleware Layercompromises: 1)DAVIC AnnexE/F/G Implementation[5], whose task is section access, filtering, and buffering and passingthe filtered sections to higher layers in the reference model; 2)MHP SI Access API[8]representing a MHP standard conform implementation of SI access whose main task is sectionparsing, database management, SI notification, handling SI database accesses, and concurrentupdating if its database data; and 3) theSI Serverfor forwarding data to one or multiple clients.Figure 1(b) shows the flow model of the whole implemented framework.

3.1 Data Access and Firmware Layer

A MPEG2 TS is received, buffered, and processed by this layer. Therefore the atomic unitof processing is a byte or a byte stream. The current implementation provides three different

sources for SI:

• The current implementation is based on a COCOM DVB satellite receiver adapter (CC1016)[4], that can be accessed viaNetwork Device/Driver Interface Specification (NDIS)drivers.The main features of this adapter are its easy accessibility, well-implemented SDK, pro-viding full simultaneous access to TS packets, multiple ESs, and channel bit rates up to56Mbps.

• The continuous stream of atomic units can be stored in one or multiple files and easilyaccessed by higher layers. The structure of the file is a sequential collection of atomicunits, whose header information is used for decoding purposes. As an atomic unit canonly be processed by a certain layer, the information contained in the file has to be passedto this layer, and synchronized. The current implementation mainly uses multiple files,where each file - uniquely identified by a PID number - represents a continuous sectionstream from one SI ES. This mode of SI access is mainly used for testing purposes.

• A more complex SI retrieval process is based on the SI protocol layer model as intro-duced in [6] and its extension within this research paper. Its functionality is described inSection 2.2.

TheLower Layer Resource Access APIperforms several tasks, such as initialisation andmanaging the life-cycle of sources, providing an abstract interface to higher level resources,buffering implementations, asynchronous source access, and unifying the software interfaceto higher software layers.

3.2 DAVIC Annex E/F/G Reference Implementation

One major entire part of this software module is DAVIC‘s Annex G implementation, providinginterfaces related to retrieve MPEG2 streams. As defined it contains an abstract definition ofa TS connected to a stream source. Each TS compromises different services, representing anabstraction for one or more ESs. Direct access to the pure data stream is only provided by thispart of the implementation. The current implementation is completely compliant, but extendsthe predefined APIs to be able to retrieve a TS and its ESs from multiple sources. Each ESobject contains an asynchronous section stream buffer to provide a generic threaded solutionfor accessing asynchronous I/O byte- and section streams in non-blocking manner.

DAVIC‘s Annex E standardizes a general mechanism allowing access to data held inMPEG2 private sections. This mechanism allows inter-operable access to data which is toospecialized to be supported by high level DVB-SI API or which is not actually related toMPEG defined SI [5]. The central object of the implementation is made up by the singletonSectionFilterGroup, whose main tasks is the creation of section filter, TS and ES connectionmanagement, resource management and control, and the generation of events if the state ofunderlying resources changes. Each section filter can filter sections with certain filter criterions:pure PID filtering, pure table filtering, positive mask section header filtering, and positiveand negative mask section header filtering. Changes in the status of resources and filters aredelegated via an asynchronous event mechanism to other parts of the application and allowsto respond to different processes, such as life-cycle changes of objects, signalling errors, statechanges, available sections, incomplete filtering, timeouts, and section version changes [7].Different life-cycle, buffering, and performance characteristics are provided by three different

types of section filter: 1) simple section filter provide the ability to filter one entire sectionfrom the stream; 2) table section filter allow the filtering of one entire table from the TS; 3) acontinuous stream of MPEG2 sections can be captured by a ring section filter.

DAVIC‘s Annex F is responsible for managing SI sources and ensures application robust-ness if one source should malfunction. The current implementation is fully compliant andprovides an appropriate interface to all implemented SI sources.

3.3 SI Server Implementation

The main task of the server implementation is to encapsulate data received by lower levelsin the software reference model into packets of a certain transmission protocol. The server isresponsible for initiating the filtering process, encapsulating the requested data into predefinedprotocol packets, lower layer data access, monitoring the whole process, establishing andmaintaining the session, and guaranteeing synchronization [7]. How SI can be encapsulatedin various protocol solutions is described in Section 2.2 in the scope of this research paper.The current solution supports to transmit each atomic unit (with exception of descriptors)with a UDP protocol solution. Where the forwarding of SI is completely MHP compliant, theimplementation of the server itself is not, as Java would cause to high performance losses.Therefore, only a performance optimised subset of the whole implementation is available.

3.4 MHP SI Access API

MHP Annex M [8] defines the DVB SI access APIs. It is responsible for requesting resources,filters, and data form DAVIC‘s reference implementation and parsing the essential informationfrom one or multiple sections. Its main integral part is the by every software entity accessibleSI database, representing the source of the whole set of parsed SI contained within a TSmultiplex. Table and service identifier or descriptor tags can be used as key for any databaseaccesses where two different modi are supported: continuous monitoring, and unique databaserequests.

4 Use Scenarios of DVB-SI Servers

Three major scenarios are currently tested and applicable for utilizing the SI decoder software:The SI decoder as basis for the Navigator, multi- and broadcasting SI information in a localnetwork (SI Server), and DVB-SI stream testing. Other scenarios are content personalizationbased on multimedia descriptors, performing data mining tasks, etc.

The Navigator represents a resident application on the STB to select services and applica-tions, boot loading, and storing user-profiles, for enhanced broadcasting without involving theinteraction channel. The Navigator uses the demultiplexed DVB-SI data supplied by the net-work operator or the broadcaster as its information source. There are five main functions in theNavigator Channel Info Bar, Channel Guide, Program Guide (i.e., EPG), Services, and Config-uration. All these views can be accessed via the main user interface by pushing the "Navigator"button on the remote control displays the main menu of the Navigator. The purpose of theChannel Info Bar is to show the information of the current program/event immediately. Thus,the viewer does not need to browse the newspaper or textTV. The information comes from theEIT present/following table and SDT table. The Channel Guide is used to help the viewer to

browse the present and following program/event of all the channels/services available in thebroadcasting network. It uses the data information carried in the EIT present/following. TheProgram Guide (cf. Figure 2(a)) provides one week’s program information. The Navigator hasthe ability to configure the user preferences, network connections, look and feel of the user-interface, etc.

(a) Navigator as Service Selector. (b) SI Decoder as SI Visualizer and DVB-SI Tester.

Figure 2: Screenshots of the Implemented System.

The SI server provides new areas of multimedia service applications: It can be used inon demand home-TV services for broadcasting SI over a local network. Each client wouldhave the ability to browse through the information and request the demanded video/audiostreams. This approach allows network bandwidth reduction, centralized SI decoding, andpay-per-view solutions in LAN and WAN environments. The main use scenario where the SIDecoder has been utilized within the research institute has been a SI monitor, for visualizingand transmitting SI over the Internet as seen in Figure 2(b).

5 Performance Evaluation

All performance evaluations have been performed based on a DVB compliant MPEG2 down-stream at 38M bps, signal strength of 49.2%, signal/noise ratio of 9.6 dB, a symbol frequencyof 27500000 Hz, and the following bit rates (that might have changed slightly during thetesting process) for each PID: PID 0x00 - 6K bps, PID 0x01 - 5K bps, PID 0x10 - 7K bps,PID 0x11 - 13.2K bps, PID 0x12 - 47.6K bps, PID 0x14 - 2.9K bps, in sum 81.7K bps. RSTand TOT tables were not multiplexed in the stream. All tests showed no buffer overflows orany inconsistencies during the whole delivery, decoding, and parsing process. This is due toadequate buffer sizes (at server side around 400 TS packets, and 250 decoded sections; at clientside 100 decoded sections and additional 100K byte stream buffer), discreet resource shar-ing, asynchronous event handling, and a robust implementation. Three different performanceevaluations have been applied to the currently implemented framework: 1) The performanceevaluation of the SI server showed that Java was fast enough to perform streaming of allservice information to 5 clients on a Intel Pentium II/300MHz (Windows98) platform with a

CPU usage of 10%-12%. The reason for this is an optimised implementation of the decodingprocess, which is not involving all software layers of the software reference model, low-bit-rates, and a Java native interface implementation to pure C/C++ code; 2) The performanceevaluation of the SI decoder, where SI encapsulated in sections was retrieved by a UDP clientover a LAN environment showed that a pure Java implementation of the software referencemodel is not capable to decode SI in an appropriate manner. The CPU usage was over 16% ona Pentium III/500MHz (Windows2000) platform, where 54% was consumed by the DAVICAPI implementation, 29% by Firmware, Data Access and MHP SI Access API, and 17% bythe application including the user-interface and statistics implementation. SI could be decodedand parsed in appropriate manner, but the overall CPU usage is not applicable for real-timeuse of Java for performing the whole SI decoding processes. A server side demutliplexingand forwarding the demultiplexed data seems to be a more adequate approach; 3) feedingthe Navigator over a WAN environment by utilizing UDP as transmission protocol showed amemory consumption at Navigator’s side of up to 107 KB and appropriate parsing behaviour,when the most of the parsing was done on server side. Further results can be obtained from [7].

6 Conclusion and Future Work

A Java based implementation on the server side, involving a Java native interface to C/C++code, seems to be adequate to process low-bit rate decoding and forwarding SI to one ormultiple clients. For a complete Java based client solution, it is inevitable to perform majorintegral parts of the SI demultiplexing and parsing at server side. Therefore a RTP basedencapsulation based on the three encapsulation schemes promises a more robust, and scalablesolution for SI transmissions than a simple UDP connection. Such solutions also provide TVon demand structures to save overall bandwidth consumption. Therefore a part of our futurework will focus on optimal SI transmissions by utilizing RTP as transmission protocol asextension to RFC 1890 that describes how a MPEG2 stream can be encapsulated within RTP.

References

[1] ISO/IEC 13818-1. Generic Coding of Moving Pictures and Associated Audio: Systems. InternationalOrganisation for Standardisation, November 1994. Recommendation H.222.0.

[2] ETS 300 468.DVB: Specification for Service Information (SI) in DVB systems. European Telecommunica-tions Standards Institute, January 1997.

[3] ETS 300 802.DVB: Network-Independend Protocols for DVB Interactive Systems. European Telecommu-nications Standards Institute, November 1997.

[4] COCOM. COCOM-S CC1016: DVB Satellite Receiver CC1016 - Product Data Sheet; DVB-S Eval-uation Kit CC1016 - Manual; CC1016 DVB Satellite Data Receiver Developers Toolkit - Manual.http://www.cocom.dk.

[5] Digital Audio-Visual Council.DAVIC 1.4 Specification Part 9: Information Representation. DAVIC - DigitalAudio-Visual Council, 1998.

[6] Artur R. Lugmayr and Seppo Kalli. Transmission of dvb service information via internet. InNext GenerationNetworks - Networks and Services for the Information Society, October 2000. 5th IFIP TC6 InternationalSymposium, INTERWORKING 2000, Bergen, Norway, October 2000.

[7] C. Peng, A. R. Lugmayr, and P. Vuorimaa. A digital television navigator. 2001. accepted.

[8] TS101812.DVB: Multimedia Home Platform Specification 1.0. European Broadcasting Union, 2000. Vers.1.1.1.