Vakgroep Informatietechnologie

Faculteit Ingenieurswetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Onderzoeksgroep Wireless & Cable

Directeur: Prof. Dr. Ir. L. MARTENS

Analyse en Ontwerp van een Applicatie voor

Videoconferencing en Live Event Broadcasting

door

Kristof DEMEYERE

Promotor: Prof. Dr. Ir. L. MARTENS

Scriptiebegeleiders: Ir. T. DERYCKERE & Lic. M. IDE

Scriptie ingediend tot het behalen van de academische graad van

burgerlijk elektrotechnisch ingenieur

Academiejaar 2005–2006

Voorwoord

Hierbij wil ik mijn promotor Prof. Dr. Ir. L. Martens en begeleiders Ir. T. Deryckere en Lic. M. Ide

bedanken voor hun begeleiding bij het maken van deze scriptie. Ik wil ook graag oprechte dank

betuigen aan mijn ouders, broers en begeleiders voor het nalezen van deze scriptie.

Kristof Demeyere, mei 2006

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van

de scriptie te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen

van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk

te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Kristof Demeyere, mei 2006

Analyse en Ontwerp van een Applicatie voorVideoconferencing en Live Event Broadcasting

door Kristof DEMEYERE

Scriptie ingediend tot het behalen van de academische graad vanburgerlijk elektrotechnisch ingenieur

Academiejaar 2005–2006

Promotor: Prof. Dr. Ir. L. MARTENSScriptiebegeleiders: Ir. T. DERYCKERE & Lic. M. IDEFaculteit IngenieurswetenschappenUniversiteit Gent

Vakgroep InformatietechnologieVoorzitter: Prof. Dr. Ir. P. LAGASSEOnderzoeksgroep Wireless & CableDirecteur: Prof. Dr. Ir. L. MARTENS

Samenvatting

In het eerste hoofdstuk worden live event broadcasting en videoconferencing nader verklaarden worden voor beide diensten toepassingsmogelijkheden aangehaald. Het tweede hoofdstukgeeft een korte introductie tot DVB, iDTV en MHP. De introductie van live event broadcastingen videoconferencing op het MHP–platform stelt enkele problemen die in het derde hoofdstukworden geschetst. Voor elk probleem wordt ook een oplossing voorgesteld. Het vierde hoofdstukbehandelt de ontworpen architecturen in detail. Hoofdstuk vijf is gewijd aan de implementatievan de functionaliteit die beide architecturen gemeenschappelijk hebben. De implementatie vande architectuur voor live event broadcasting is het onderwerp van de hoofdstukken zes en zeven.In hoofdstuk zes wordt het servergedeelte van de architectuur besproken en hoofdstuk zevengeeft een overzicht van de ontworpen MHP–applicatie. Tot slot wordt in hoofdstuk acht deconclusie gepresenteerd.

Trefwoorden

Live Event Broadcasting, Videoconferencing, DVB, iDTV, MHP, Podcasting, Vodcasting

Analysis and Development of an Application forVideoconferencing and Live Event Broadcasting

Kristof Demeyere

Supervisor(s): Prof. Dr. Ir. L. Martens, Ir. T. Deryckere & Lic. M. Ide

Abstract— Interactive Digital Television (iDTV) is about to completelychange the user experience of television in the living room. In my opinion,the iDTV infrastructure lends itself perfectly to support live event broad-casting and videoconferencing, both enhanced with interactive applications.These services have a vast application domain which includes plain video-conferencing but also video surveillance, T-learning and T-health. This ar-ticle discusses different architectures and shows an implementation for theMultimedia Home Platform.

Keywords— MHP, iDTV, Live event broadcasting, Videoconferencing,Podcasting, Vodcasting

I. INTRODUCTION

A. Interactive Digital Television (iDTV)

iDTV is gradually replacing his analogue predecessor whomeveryone has been so familiar with for a long time. iDTV not

only offers superior image and sound quality but also enablesthe user to interact with the broadcast programs. The magicbox that unlocks the wealth of new services is the set–top box(STB). The STB is capable of decoding the broadcast digitalvideo signal and provides local as well as global interactivity.

B. Multimedia Home Platform (MHP)

MHP is the first common open middleware platform being de-ployed at large scale in set-top boxes. It provides the applicationdeveloper with a number of API’s suitable to develop a varietyof applications irrespective of the underlying hardware of theSTB. Applications developed for this Multimedia Home Plat-form will be interoperable with different MHP implementationsresulting in a horizontal market. Most of today’s STB’s labeledMHP compliant, currently implement MHP specification 1.0.2or 1.1.2 [4].

C. Live Event Broadcasting & Videoconferencing

With both services audiovisual content, as requested by theuser, has to be delivered to the STB. This audiovisual contentcan range from the video from a participant in a conference toa specific camera angle video stream resulting from the captureof a live event. In general this audiovisual stream will originatefrom a packet-switched network. Looking at a typical STB thereare two ways to receive audiovisual content: the return channeland the broadcast channel. Given the flexibility by which eachuser should be able to start a video conference or select a liveevent to watch, it seems preferable to use the return channel.Videoconferencing also requires that each participant is able tocapture his own video and audio stream in order to transmit thismedia to other participants.

II. MHP SPECIFICATION LIMITATIONS & STBCAPABILITIES

The MHP specifications provide a rich set of features forthe application developer to use but lacks support of specificfunctionality required to implement live event broadcastingand videoconferencing. Although the application developer isbounded by the features provided by the API, it is also worth tak-ing into consideration the capabilities of current set-top boxes.

A. Return Channel

The return channel is the path through which the STB cancommunicate with the outside world. The MHP specificationdefines a set of interaction protocols for this return channel ac-cessible to MHP applications. To stream live video to the STBit is preferable to use UDP over IP both of which are included inthe return channel protocolstack. However, when it comes downto using this return channel to receive content such as video oraudio, there are limitations. Delivering streaming media throughthe return channel is currently not supported by MHP [4]. Re-search was done to try to work around this restriction but noneof the attempts succeeded.

It is interesting to note that some STB manufacturers are in-corporating delivery of media over IP in the STB design, leadingto the so called IP STB, or are extending current STB’s with spe-cial ASIC modules. Other STB vendors have announced STB’sprovided with the functionality to receive two signals throughtwo separate tuners. One tuner will be used to receive the broad-cast MPEG-2 MPTS which contains digital television, while theother one will be used to receive the DOCSIS downstream [2].These dual feed set–top boxes, will be able to play media contentdelivered through DOCSIS by using the same MPEG-2 decoderas used to process the broadcast. These cases illustrate the mi-gration to IP Television. The MHP standard can be improved byenabling playback of audiovisual content delivered through thereturn channel. This improvement would take the MHP standardcloser to IPTV and MHP for IPTV has been proposed [9].

As the return channel is not available for live media deliv-ery, I propose an alternative by transferring the streaming me-dia coming from a packet-switched network into the broadcast.This requires however that this content is correctly signalled inthe broadcast and the STB is informed where to look for thatspecific content. For this end, a dynamic allocation system wasdeveloped that enables reservation of channels in the broadcastwhich can be used to transport live streaming media.

B. Peripherals

In the current MHP specifications there is no mention of otherdevices for the user to interact with but remote control and key-board. STB’s now available on the market have only a limitedamount of support for peripherals like keyboards and units withvideo camera support are rare. For videoconferencing captur-ing live audio and video is of course a required feature. Al-though there is currently no support for such capture devices,it can be expected that future MHP specifications and set-topboxes will support numerous peripherals amongst which for ex-ample a camera. In case the MHP supports capture peripherals,some decisions will have to be made to ensure interoperability.First of all, the MHP specification can dictate general supportfor capture devices like a USB webcam or demand support fora specific camera and microphone functionality. Secondly a for-mat for transmission of the captured audio and video has to bedecided. Depending on the chosen format the cost of an STBunit can substantially increase.

The absence of a capture device can be solved by using in-telligent peripherals incorporated in a home network togetherwith the STB. The incorporation into the home network couldrange from basic IP connectivity to full integration into an exist-ing home network using OSGI or UPnP. Some scenarios basedon MHP and OSGI describing the interaction between digitalTV receivers and home networks have been illustrated [11].The Open Cable Application Platform (OCAP) already providesan extension for home networking [3]. Inside the DVB MHPgroup, the MHP Home Networking (MHP-HN) group is ad-dressing this topic amongst others. The solution I have chosenis based on incorporating the STB in the home network sim-ply by connecting it to the residential gateway. The solution forthe capture of live video and audio uses custom capture soft-ware running on a host equipped with a webcam. The STB candiscover and configure such capture software by broadcastingspecific predefined messages on the home network. It should benoted that it is also possible to use an ethernetcam to capturevideo and audio, but due to the price of such cameras they arenot found suitable for low cost applications such as videocon-ferencing.

III. ARCHITECTURE FOR LIVE EVENT BROADCASTING

The architecture for live event broadcasting is based on Pod-casting. Podcasting is a popular way to advertise audio content.Podcasting consists of creating audio content, placing it on aserver host and publishing the presence of the content by usingpodcast feeds which are an extension of RSS feeds. With thesame principle, one can advertise video content, also known asVodcasting. By applying certain changes to Vodcasting as suchthat it can be used to publish live events, it forms the base forthe developed architecture. Using both the modified Vodcastingprinciple and the allocation system for placing live streamingmedia in the broadcast described above, results in a dynamicsystem which can be used for many new services includingsurveillance, T–Health and T–Learning [8]. The combination ofVodcasting and live event broadcasting seems a promising ap-proach to extend the tradional broadcasting and enable users to

publish personalized content. Moreover, the architecture lendsitself perfectly to be used for VOD.

IV. ARCHITECTURE FOR VIDEOCONFERENCING

There are several possible architectures for videoconferenc-ing. A P2P architecture such as the one used for Skype [1] isnot possible with MHP due to the lack of support for delivery ofstreaming media through the return channel. Videoconferencingcan also be realised through a publish/subscribe system as pro-posed in [6]. The developed architecture for videoconferencinghowever is based on that of VoIP. In VoIP, the description ofthe session relies on the SDP [7] and the initialisation uses theSIP [10]. SIP will also be used in the third generation wirelessnetworks. By using an MHP compliant STB as SIP endpointa video call between a handheld mobile phone and a televisionset seems plausible. In the current prototype the delay betweencapture with camera and microphone and presentation on thetelevision screen is too high to make a comfortable videoconfer-ence. Nevertheless it should be possible to reduce that delay bytuning the system.

V. CONCLUSIONS

Providing new video services like live event broadcasting andvideo conferencing for the Multimedia Home Platform cannotonly improve the user experience of iDTV but has also the pos-sibility of introducing new business models that can help theiDTV development. The here presented architectures, enablesthese new services by bringing the flexibility of an IP networkand the high bandwidth of a DVB broadcast network together.

REFERENCES

[1] BASET, S. & SCHULZRINNE, H. (2004). An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. USA, New York, Department of Com-puter Science, Columbia University.

[2] BUGAJSKI, M. (2004). Convergence of Video in the Last Mile:MPEG2-TS and DOCSIS, Technical Paper for Jornadas 2004 Conference.http://www.arrisi.com/products solutions/applications/white papers/Convergence Video Last Mile.pdf.

[3] CableLabs (2005). OpenCable Application Platform Specification OCAPHome Networking Extension. Doc.: OCAP-HNEXT1.0.

[4] European Telecommunications Standards Institute (ETSI) (2002). DigitalVideo Broadcasting (DVB); Multimedia Home Platform (MHP) Specifica-tion 1.0.2. Doc.nr.: TS 101812 v1.2.1 (2002-06).

[5] European Telecommunications Standards Institute (ETSI) (2003). DigitalVideo Broadcasting (DVB); Multimedia Home Platform (MHP) Specifica-tion 1.1.1. Doc.nr.: TS 101812 v1.2.1 (2003-06).

[6] FOX, G., WU, W., UYAR, A. & BULUT, H. (2004). Design and Implemen-tation of Audio/Video Collaboration System Based on Publish/subscribeEvent Middleware. USA, New York, Department of Electrical Engineeringand Computer Science, Syracuse University.

[7] HANDLEY, M., & JACOBSON, V. (1998). SDP: Session Description Pro-tocol. http://www.ietf.org/rfc/rfc2327.txt.

[8] LYTRAS, M., LOUGOS, C., CHOZOS, P. & POULOUDI, A. (2003) Inter-active Television and E-Learning Convergence: Examining the Potential ofT-Learning. Greece, Athens, Department of Management Science & Tech-nology, Athens University of Economics and Business.

[9] PIESING, J. (2006). Roadmap for MHP and Related Technologies. Pre-sented at DVB World 2006 - The Challenge of Choice, Dublin, March 2,2006.

[10] ROSENBERG, J., SCHULZRINNE, H., CAMARRILLO, G., JOHN-STON, A., PETERSON, J., SPARKS, R., et al. (2002). SIP: Session Ini-tiation Protocol. http://www.ietf.org/rfc/rfc3261.txt.

[11] TKACHENKO, D., & KORNET, N. (2004). Convergence of iDTV andHome Network Platforms. Russia, St.Petersburg, Radio Engineering andTelecommunications Department, St.Petersburg State Polytechnic Univer-sity.

INHOUDSOPGAVE i

Inhoudsopgave

1 Live Event Broadcasting & Videoconferencing 1

1.1 Live Event Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Videoconferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 DVB, iDTV & MHP 6

2.1 DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 MPEG–2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 MPEG–2 Video & Audio Specification . . . . . . . . . . . . . . . . . . . . 8

2.2.2 MPEG–2 Systems Specification . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.3 MPEG–2 Extensions for DSM–CC . . . . . . . . . . . . . . . . . . . . . . 17

2.2.4 MPEG–2 Profiles & Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 iDTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Multimedia Home Platform (MHP) . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1 DVB–J Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2 Applicatiemodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.3 Applicatiesignalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.4 Grafisch Model in MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.5 MHP–Profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

INHOUDSOPGAVE ii

3 Live Event Broadcasting & Videoconferencing voor MHP 25

3.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Ontvangen van Videostroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 MHP Exploratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 STB Voorzieningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.3 IP2DVBGateway & IP2DVBScheduler . . . . . . . . . . . . . . . . . . . . 32

3.3 Opname van Videostroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1 MHP Exploratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.2 STB Voorzieningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.3 Capture–Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Architecturen voor Live Event Broadcasting & Videoconferencing 37

4.1 Live Event Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 Architectuur Exploratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.2 Podcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.3 Ontworpen Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Videoconferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.1 Architectuur Exploratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 Session Description Protocol (SDP) . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.4 Ontworpen Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Verdeeldheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 IP2DVBGateway & VLC 53

5.1 IP2DVBGateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.2 Werking IP2DVBGateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.3 Implementatie IP2DVBGateway . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.4 Aanspreken vanuit Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.5 Extensies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 VLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

INHOUDSOPGAVE iii

5.2.2 VLC Commandolijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.3 Aanspreken vanuit Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.4 Extensies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.1 Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.2 VLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.3 Maatregelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Implementatie Live Event Broadcasting Architectuur 74

6.1 IP2DVBScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2 Streamer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3.1 LiveEventServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.3.2 SchedulerFacadeSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3.3 EntityBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7 Implementatie MHP–Applicatie voor Live Event Broadcasting 83

7.1 Overzicht MHP–Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2 Events & Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.2 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3 Main & Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.4 HTTP–Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.5 Aggregator–Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.6 GUI–Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.6.1 Componenten & Weergaves . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.6.2 Scherm Modelvorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.6.3 HomeScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.6.4 BrowserScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.6.5 PlayerScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.6.6 HelpScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.6.7 ExitScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8 Conclusie 96

Lijst van afkortingen iv

A Podcast & Vodcast Feeds 98

A.1 Podcast Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.2 Aangepaste Vodcast Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

B Discover Configure Command Protocol 101

C Klassendiagramma’s 103

C.1 HomeScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.2 BrowserScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.3 PlayerScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.4 HelpScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.5 ExitScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

D Momentopnames Gebruikersinterface 106

D.1 HomeScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

D.2 BrowserScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

D.3 PlayerScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

D.4 HelpScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Lijst van afkortingen v

Lijst van afkortingen

AES Audio Engineering Society

AIT Application Information Table

ASIC Application Specific Integrated Circuit

AWT Abstract Window Toolkit

CAT Conditional Access Table

CBR Constant Bit Rate

CM Cable Modem

CPU Central Processing Unit

DAB Digital Audio Broadcasting

DAVIC Digital Audio–Visual Council

DCCP Discover Configure Command Protocol

DCT Discrete Cosine Transform

DHCP Dynamic Host Configuration Protocol

DiffServ Differentiated Services

DOCSIS Data Over Cable Service Interface Specification

DSM–CC Digital Storage Media – Command and Control

DTS Decoding Time Stamp

DVB Digital Video Broadcasting

Lijst van afkortingen vi

DVB SI DVB Service Information

DVB–ASI Digital Video Broadcast – Asynchronous Serial Interface

DVB–C Digital Video Broadcasting Cable

DVB–S Digital Video Broadcasting Satellite

DVB–T Digital Video Broadcasting Terrestrial

EB Entity Bean

EBU European Broadcasting Union

EIT Event Information Table

EPG Elektronic Program Guide

ES Elementary Stream

FIFO First In, First Out

GIF Graphics Interchange Format

GOP Group of Pictures

GPRS General Packet Radio Service

GPU Graphics Processing Unit

GUI Graphical User Interface

HAVi Home Audio Video interoperability

HFC Hybrid Fiber Coax

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

iDTV Interactive Digital Television

IETF Internet Engineering Task Force

IntServ Integrated Services

Lijst van afkortingen vii

IP Internet Protocol

IPTV IP Television

ISO International Standards Organisation

ITU International Telecommunication Union

J2EE Java 2 Enterprise Edition

JAS Java Stream Assembly

Java RMI Java Remote Method Invocation

JMF Java Media Framework

JPEG Joint Photographic Experts Group

JVM Java Virtual Machine

MHP Multimedia Home Platform

MHP–HN MHP–Home Networking

MP3 MPEG–1 Layer 3

MPEG Moving Pictures Experts Group

MPTS Multi Program Transport Stream

NIT Network Information Table

OCAP OpenCable Applications Platform

ONID Original Network Identifier

ONU Optical Node Unit

OSGI Opern Services Gateway Initiative

P2P Peer to Peer

PAT Program Assocation Table

PCR Program Clock Reference

Lijst van afkortingen viii

PES Packetised Elementary Stream

PID Packet Identifier

PMT Program Map Table

PNG Portable Network Graphics

PS Program Stream

PSI Program Specific Information

PSTN Public Switched Telephone Network

PTS Presentation Time Stamp

QAM Quadrature Amplitude Modulation

QoS Quality of Service

RAM Random Access Memory

RF Radio Frequency

RSS Really Simple Syndication

RSVP Resource Reservation Protocol

SB Session Bean

SDP Session Description Protocol

SDT Service Description Table

SID Service Identifier

SIP Session Initiation Protocol

SMS Short Message Service

SNR Signal to Noise Ratio

SPTS Single Program Transport Stream

STB Set–Top Box

Lijst van afkortingen ix

TCP Transmission Control Protocol

TLS Transmission Layer Security

TS Transport Stream

TSID Transport Stream Identifier

UDP User Datagram Protocol

UPnP Universal Plug and Play

URL Uniform Resource Locator

USB Universal Serial Bus

VBR Variable Bit Rate

VLC VideoLAN Client

VOD Video On Demand

VoIP Voice over IP

WFQ Weighted Fair Queuing

XML Extensible Markup Language

LIVE EVENT BROADCASTING & VIDEOCONFERENCING 1

Hoofdstuk 1

Live Event Broadcasting &

Videoconferencing

1.1 Live Event Broadcasting

1.1.1 Inleiding

Het medium televisie is reeds lang ingeburgerd. Televisie combineert gebruikersgemak met toe-

gankelijkheid en het is dan ook niet verwonderlijk dat televisie niet alleen gebruikt wordt om

informatie te verspreiden, zoals het dagelijks nieuws, maar ook voor entertainment. Een ge-

beuren wordt opgenomen in de televisiestudio en verwerkt tot een programma dat gebroadcast

wordt. Er is een grote varieteit aan televisiekanalen en televisieprogramma’s. Broadcasting vindt

echter slechts in een beperkt aantal gevallen plaats terwijl het gebeuren zich afspeelt. Toch heeft

het live–aspect een zekere meerwaarde voor de kijkers.

De huidige live-uitzendingen kunnen interactiever worden gemaakt. Meestal zijn verschillende

camerastandpunten beschikbaar maar wordt in de televisiestudio beslist welk standpunt wordt

uitgezonden. Het lijkt eenvoudig om de keuze aan de kijker over te laten en verschillende came-

rastandpunten voor het publiek ter beschikking te stellen. Bij het uitzenden van bijvoorbeeld

een sportevenement kan dit principe eenvoudig worden toegepast. Live event broadcasting wordt

in deze scriptie echter ruimer genomen dan tradionele broadcasting. Er wordt gepoogd te breken

met het patroon waarbij aan elk televiekanaal een tijdslijn met programma’s is verbonden en

er voor de kijker beslist wordt wat er op de beeldbuis komt. Gebruikers zullen zelf ook voor

content kunnen zorgen wat het televisie kijken grondig zal veranderen.

1.1 Live Event Broadcasting 2

Podcasting is een recente internettrend die gebruikers toelaat audio–opnames op het internet

te plaatsen en ter beschikking te stellen van andere gebruikers1. De populariteit van Podcas-

ting is groot en toont aan dat gebruikers interesse hebben om gepersonaliseerde content aan te

bieden. De enorme populariteit van Blogging2 lijkt dit alleen maar te beamen. De beide voor-

beelden zijn echter specifiek voor het PC–platform. Nu digitale televisie wordt geıntroduceerd,

lijkt het dan ook het ideale moment om de brug te maken tussen televisie en sommige van deze

populaire internettechnologieen. Aan de hand van een gewijzigde vorm van Podcasting zullen

gebruikers zelf live–uitzendingen kunnen aanbieden die te bekijken zijn op de televisie.

1.1.2 Toepassingen

Het aanbieden van gepersonaliseerde content biedt heel wat mogelijkheden en de toepassingen

situeren zich in verschillende domeinen. In deze paragraaf wordt geıllustreerd hoe divers en

uiteenlopend toepassingen van live event broadcasting wel kunnen zijn.

T–Learning vloeit voort uit de combinatie van interactieve televisie en E–Learning [30]. T–

Learning laat televisiekijkers toe kennis op te doen via het televisieplatform door bijvoorbeeld

deel te nemen aan een quiz. Live event broadcasting verruimt de mogelijkheden van T–Learning.

Een rijschool kan bijvoorbeeld een theorieles over de verkeersregels live uitzenden en na de uit-

zending kunnen de kijkers een quiz afleggen over de gegeven leerstof. Een professor kan zijn

hoorcolleges uitzenden zodat studenten thuis de colleges kunnen volgen.

Om het onveiligheidsgevoel in metrostations te verlagen kunnen camera’s opgesteld worden

waarmee vanuit het politiekantoor toezicht kan worden gehouden. Ook op andere plaatsen kan

surveillance worden gebruikt. Met traffic monitoring kunnen gevaarlijke kruispunten of drukke

snelwegen extra in het oog worden gehouden. Verkeersgebruikers kunnen vooraleer deel te ne-

men aan het verkeer de situatie op de geplande route overzien en anticiperen op eventuele files

of ongevallen.

De dienst thuiszorg kan bij minder valide patienten eenvoudige camera’s in de woning laten

installeren. Zo kunnen de patienten van op de dienst worden gevolgd en kan personeel op thuis-1Podcasting komt uitgebreid aan bod in hoofdstuk 4.2Een blog is een publicatie van artikels op het web die regelmatig wordt geupdatet.


bezoek gaan indien een patient hulp nodig heeft. Dit is een toepassing van T–Health, zoals dit

verder beschreven wordt. In de kindercreche kunnen camera’s worden opgesteld zodat bezorgde

ouders tijdens hun koffiepauze op het kantoor hun kind even kunnen gade slaan. Ook de groot-

ouders kunnen deze remote baby monitoring gebruiken.

Live event broadcasting heeft ook commerciele toepassingen en biedt nieuwe vormen voor recla-

me. Een firma kan voor de promotie van een product bijvoorbeeld een belangrijke voetbalmatch

live uitzenden. Gebruikers die in de supermarkt het product, of een bepaalde hoeveelheid ervan,

aankopen, mogen bij het afrekenen aan de kassa hun elektronische identiteitskaart laten inscan-

nen. Bij de aanvang van de wedstrijd kunnen die gebruikers dan na authenticatie aan de hand

van hun identiteitskaart afstemmen op het kanaal waarop de voetbalmatch te zien is.

Hoewel het bovenstaande de diversiteit van de toepassingen aantoont, wordt bij het aanbieden

van live event broadcasting voor televisie geen veronderstelling gemaakt omtrent het onderwerp

van de live–uitzending. Net zoals Blogging voor erg uiteenlopende onderwerpen zoals politiek

of nieuws wordt aangewend, zal live event broadcasting ongetwijfeld in verschillende domeinen

toepassing vinden.

1.1.3 Requirements

Na de bovenstaande toepassingen kan er overgegaan worden tot het vastleggen van de require-

ments voor de applicatie voor live event broadcasting. Volgende lijst somt de voornaamste

vereisten op.

• De gebruiker moet op de hoogte worden gebracht van de live–uitzendingen die beschikbaar

zijn.

• De beschikbare live–uitzendingen moeten op een overzichtelijke manier worden gepresen-

teerd, bijvoorbeeld in een eenvoudig te doorzoeken catalogus.

• De gebruiker moet een bepaalde live–uitzending kunnen kiezen.

• Indien meerdere camerastandpunten of audiokanalen beschikbaar zijn moet de gebruiker

een keuze kunnen maken volgens zijn voorkeur.

• De vertraging tussen opname van de live–uitzending en weergave op het televisietoestel

moet bij voorkeur zo klein mogelijk zijn.

1.2 Videoconferencing 4

1.2 Videoconferencing

1.2.1 Inleiding

Communicatie is een uitermate belangrijk aspect van het hedendaags leven. Het is dan ook niet

verwonderlijk dat er tegenwoordig diverse communicatievormen zoals SMS, telefonie en email

beschikbaar zijn. Eenzelfde diversiteit is merkbaar in de apparaten die voor communicatie

aangewend worden. Videoconferencing ligt al binnen de technische mogelijkheden maar heeft

tot op de dag van vandaag het grote publiek nog niet bereikt. Deze dienst wordt tegenwoordig

wel al in beperkte mate aangeboden op de laatste generatie mobiele telefoons. De combinatie

van televisie en videoconferencing lijkt nochtans evenzeer aantrekkelijk maar is momenteel nog

niet beschikbaar.

1.2.2 Toepassingen

Videonconferencing in zijn algemene vorm, een audiovisuele communicatievorm, biedt heel wat

toekomst. Vergaderingen tussen afdelingen van een multinational vinden nu vaak al plaats door

middel van videoconferenties. Momenteel vereist dit wel gespecialiseerde systemen en daarom

blijft videoconferencing buiten het bereik van het grote publiek. Videoconferencing heeft desal-

niettemin het potentieel om de huidige telefonie te verdringen indien de dienst met voldoende

kwaliteit wordt aangeboden.

Bij T–Learning kan videoconferencing worden toegepast. Zo worden interactieve hoorcolleges

op afstand mogelijk tussen professor en student. Het succes van instant messenger–applicaties

zoals Microsoft MSN Messenger3 toont aan hoe populair chatten is. Videoconferencing kan ook

ingebed worden in dergelijke chatapplicaties.

T–Health is de verzamelnaam voor ziekenzorg en het verschaffen van medische informatie door

middel van internetgerelateerde technologieen. De doelstelling van T–Health is het aanbieden

van een verbeterde en kwalitatief hogere ziekenzorg terwijl de kost hiervoor daalt. Videoconfe-

rencing kan hierin een belangrijke rol spelen. Zo kan een patient van thuis uit een arts consulteren

via het televisiescherm. Een arts kan voor het behandelen van een bepaald medisch dossier de

expertise van een andere arts benutten via een videoconferentie.3http://messenger.msn.com


Een intelligente elektronische programmagids (EPG) kan een gebruikersprofiel van de kijker

samenstellen. Een reclamefirma kan dit profiel dan aanwenden voor verkoopsdoeleinden. Indien

bijvoorbeeld de gebruiker vaak naar documentaires kijkt, kan een winkelketen, die documentai-

res te koop aanbiedt op DVD, de gebruiker contacteren door middel van een videoconferentie

om hem te informeren over de promoties van bepaalde producten. Videoconferencing biedt dus

ook nieuwe businessmodellen voor reclame en telemarketing.

1.2.3 Requirements

Onderstaande lijst schetst de voornaamste requirements voor videoconferencing.

• De gebruiker moet een videoconferentie aan kunnen gaan met een andere gebruiker.

• De gebruiker moet een overzicht krijgen van de gebruikers die kunnen worden gecontac-

teerd, bijvoorbeeld aan de hand van een soort telefoonboek.

• De vertraging tussen opname en weergave op het televisietoestel moet zo klein mogelijk

gehouden worden zodat de videoconferentie vlot en aangenaam kan verlopen.

Nu live event broadcasting en videoconferencing, met hun potentieel aan toepassingen, werden

omschreven, is het tijd om kennis te maken met het platform waarop beide diensten aangeboden

zullen worden. Daartoe wordt in het volgende hoofdstuk een korte inleiding gegeven tot DVB,

iDTV en het doelplatform MHP.

DVB, IDTV & MHP 6

Hoofdstuk 2

DVB, iDTV & MHP

2.1 DVB

Digitale media zijn tegenwoordig omnipresent. Denken we bijvoorbeeld aan de compact disc

(CD) en digital versatile disc (DVD). Digitalisatie van media heeft een aantal belangrijke voor-

delen. Vooreerst is de kwaliteit duidelijk superieur, ten tweede is het eenvoudiger om de media

te beschermen door middel van foutdetectie en foutcorrectie. Een derde, misschien ook het be-

langrijkste, voordeel is de mogelijkheid om digitale media te comprimeren. Het broadcasten van

media vindt echter nog steeds grotendeels plaats in het analoge domein. De stap naar digital

broadcasting is reeds gezet en er kan verwacht worden dat het broadcasten meer en meer in het

digitale domein zal plaatsvinden. De begrippen Digital Video Broadcasting (DVB) en Digital

Audio Broadcasting (DAB) klinken wellicht al niet meer onbekend. Digitale broadcasting be-

tekent weliswaar een wijziging van de opstelling die nodig is om televisie te ontvangen. Als de

transmissie in het digitale domein gebeurt is er een component nodig die het ontvangen digitaal

signaal vertaalt naar een signaal dat te begrijpen is voor het televisietoestel. Figuur 2.1 toont

de opstelling. De kern van de opstelling is de set–top box (STB). De STB ontvangt het digitaal

broadcastsignaal via het broadcastkanaal en converteert het naar een analoog signaal dat naar

de televisie wordt gevoerd. Hoewel dit converteren een van de hoofdtaken is van de STB, bevat

de STB heel wat meer functionaliteit zoals verder zal blijken.

Gezien de voordelen van digitale transmissie en om de introductie van digitale televisie te ver-

eenvoudigen werd in 1993 het DVB Project1 opgericht. Dit consortium bestaat uit ruim 2501http://www.dvb.org

2.1 DVB 7

Figuur 2.1: iDTV opstelling in de woonkamer.

bedrijven en staat in voor het uitbrengen van specificaties voor digitale televisie in Europa. De

DVB–standaard, die ondertussen al ver buiten Europa wordt toegepast, maakt gebruik van de

ITU-R BT.601–standaard [29] voor digitalisering en van de MPEG–2–standaard voor compres-

sie en transmissie. Het DVB–consortium beschouwt verschillende transmissiekanalen waarlangs

gebroadcast kan worden: via satelliet, via kabel en terrestrieel via antennes. Voor elk van deze

kanalen werd een specificatie uitgebracht die de fysische parameters voor het transmissiekanaal

beschrijven: DVB–S [13], DVB–C [14] en DVB–T [17]. Er is tevens een specificatie die het

ontvangen van terrestriele radio–en televisie–uitzendingen op mobiele apparatuur behandelt:

DVB-H [18]. Digitale broadcasting begint net zoals bij analoge televisie met het opnemen van

een gebeuren in de televisiestudio. Indien de opgenomen signalen analoog zijn, worden ze nu

gedigitaliseerd. Voor video wordt daarvoor gebruik gemaakt van de ITU-R BT.601 [29], voor

audio gebruikt men de AES/EBU standaard [1]. De beeldsignalen worden omgevormd tot een

digitaal signaal. Ook het audiosignaal wordt gedigitaliseerd. De gezamenlijke bitsnelheid van het

resulterende audio– en videosignaal bedraagt meer dan 270 Mbit/sec. Indien zoals bij analoge

televisie een bandbreedte van 8 MHz ter beschikking is, komt men via de Shanon capaciteitsli-

2.2 MPEG–2 8

miet2 al snel tot de conclusie dat compressie noodzakelijk is. Voor de compressie van de audio

en video evenals voor de transmissie wordt de MPEG–2–standaard gevolgd.

2.2 MPEG–2

In 1995 werd MPEG–2–standaard gepubliceerd door de International Standards Organisation

(ISO)3. De standaard beschrijft compressie, opslag en transmissie van digitale audio en video.

De MPEG–2–standaard bestaat uit negen delen waarvan voor digitale televisie vooral delen

een, twee, drie en zes belangrijk zijn. Het eerste deel, MPEG–2 Systems Specification [25],

beschrijft hoe gecomprimeerde audio en video datastromen gemultiplexed kunnen worden in een

datastroom. Deel twee, MPEG–2 Video Specification [26], beschrijft de compressie van digitale

video en deel drie, MPEG–2 Audio Specification [27], beschrijft de compressie van digitale audio.

Deel zes tenslotte, MPEG–2 Extensions for DSM-CC [28], beschrijft een carrouselsysteem dat

gelijkenissen vertoont met het huidige teletekstsysteem.

2.2.1 MPEG–2 Video & Audio Specification

De MPEG–2–videospecificaties en MPEG–2–audiospecificaties beschrijven hoe audio en video

gecomprimeerd kunnen worden en ook de syntax van de gecomprimeerde audio en video. Dit

process wordt omschreven als MPEG–codering. In wat volgt worden enkel de relevante elementen

inzake MPEG–codering van audio en video behandeld. Voor meer details wordt de lezer verwezen

naar [26] en [27].

2.2.1.1 MPEG–2 Video Codering

Een ongecomprimeerde digitale videosequentie bestaat uit een opeenvolging van ongecompri-

meerde beelden, die in MPEG–2–terminologie presentation units worden genoemd. Opeenvol-

gende beelden in een videosequentie verschillen doorgaans weinig van elkaar, dit wordt aangeduid

als temporele redundantie. Ook binnen eenzelfde beeld is er redundantie aanwezig, er kunnen

regio’s gevonden worden met dezelfde kleur of textuur. Dit heet spatiale redundantie. Figuur 2.2

toont de beide vormen van redundantie. Het doel van compressie is dan ook de redundante in-

formatie te verwijderen om een lagere bitsnelheid te bekomen. Spatiale redundantie houdt in dat

naburige pixels in een beeld gelijkaardige waarden hebben en bemoeilijkt compressie. Daarom2De Shanon capaciteitslimiet geeft de maximale bitsnelheid aan voor een bandbreedte beperkt kanaal.3http://www.iso.org

2.2 MPEG–2 9

Figuur 2.2: Spatiale en temporele redundantie.

past men een zogenoemde transformatiecodering toe door middel van de Discrete Cosine Trans-

form (DCT). De DCT transformeert een groep pixels in evenveel transformatiecoefficienten die

beter te comprimeren zijn. De transformatie op zich is inverteerbaar en introduceert dus geen

compressie. De transformatiecoefficienten kunnen echter wel afgerond worden door middel van

quantisatie en geeft aanleiding geeft tot een bescheiden compressie. De quantisatie brengt na-

tuurlijk wel een daling in beeldkwaliteit met zich mee. Berekent men vanuit de gequantiseerde

transformatiecoefficienten opnieuw beeldpixels dan zullen die niet meer gelijk zijn aan de origi-

nele. Een goede quantisatie zorgt er echter wel voor dat het visueel verschil miniem is.

Temporele redundantie wordt verwijderd door het toepassen van motion compensated predic-

tion. Als opeenvolgende beelden gelijkaardige regio’s vertonen is het voordeliger om dergelijke

regio’s slechts eenmaal te coderen. De encoder zoekt in een vooraf gecodeerd referentiebeeld

naar de best passende regio en codeert de locatie ervan, door middel van een motion vector4, en

het verschil tussen de gevonden regio en de eigenlijke regio. Dit verschil wordt de predictiefout

genoemd. Het referentiebeeld kan een voorafgaand of volgend beeld zijn, maar er kan ook ge-

bruik worden gemaakt van een voorafgaand en een volgend beeld. Men duidt dit respectievelijk

aan als forward, backward of bidirectional prediction. Figuur 2.3 illustreert de drie voorspel-

lingstypes. Bij het decoderen zal dan de regio uit het referentiebeeld overgenomen worden en

er de predictiefout bij opgeteld worden. Motion estimated prediction kan de compressie-effientie

drastisch verbeteren.

4Een bewegingsvector of motion vector is een verwijzing naar het referentiebeeld waarin de regio is gevonden

2.2 MPEG–2 10

Figuur 2.3: Voorwaartse, achterwaartse en bidirectionele predictie.

Presentation units worden door MPEG–2–videocompressie omgezet in een van drie beeldty-

pes, zogenaamde picture types: I–frames, P–frames en B–frames. Het eerste type gebruikt enkel

intra frame coding wat betekent dat het beeld onafhankelijk van andere beelden wordt gecom-

primeerd. Bij een I–frame wordt dus enkel de spatiale redundantie verwijderd. Dit beeldtype

is nuttig voor resynchronisatie van de MPEG–2–decoder maar vereist het grootste aantal bits.

P–frames gebruiken inter frame coding. Gebruikmakend van voorwaartse predictie worden P–

frames voorspeld op basis van een voorafgaand I–of P–frame. P–frames kunnen dus zelf ook

als referentie gebruikt worden voor voorspelling. Ze hebben een betere compressie–effientie dan

I–frames. Ook bij het laatste type, B–frames, wordt inter frame coding toegepast. Hier gebruikt

men bidirectionele predictie wat aanleiding geeft tot de beste compressie–effientie. De bidirec-

tionele predictie vergt echter ook de meeste rekentijd. Bovendien resulteert het gebruik van

B–frames in een additionele vertraging bij het decoderen omdat de beide referentiebeelden, die

gebruikt werden bij de predictie, eerst moeten worden gedecodeerd. Een videosequentie wordt

dus gecodeerd als een opeenvolging van I–, P–of B–frame. De keuze van het beeldtype is echter

niet willekeurig. De sequentie wordt namelijk gecodeerd als een opeenvolging van een group of

pictures (GOP). Een GOP start steeds met een I–frame en bevat, volgend op het I–frame, een

bepaalde combinatie van P-en B-frames. Figuur 2.4 toont een voorbeeld van een typische GOP.

De STB kan steeds beginnen met het decoderen van de videostroom vanaf het begin van een

GOP. De structuur van de GOP bepaalt de uiteindelijke bitrate maar ook de gevoeligheid voor

transmissiefouten [34]. Het is namelijk zo dat wanneer motion compensated prediction wordt

toegepast foutpropagatie kan optreden. Foutpropagatie betekent dat een fout in een gedeco-

deerd referentiebeeld aanleiding geeft tot fouten in beelden die voorspeld werden op basis van

2.2 MPEG–2 11

Figuur 2.4: Group of Pictures (GOP).

dat referentiebeeld. Hoewel hier summier enkele belangrijke aspecten van het videocompres-

sieproces worden geschetst zijn, vallen andere belangrijke aspecten buiten het bestek van deze

bundel. De geınteresseerde lezer wordt doorverwezen naar [34] en [26].

2.2.1.2 MPEG–2 Audio Codering

Audio wordt eveneens MPEG gecodeerd wat resulteert in een gecodeerde audio bitstroom. De

exacte werking van het audiocompressieproces is niet relevant voor wat volgt. De gedetaileerde

beschrijving is te vinden in [27].

2.2.2 MPEG–2 Systems Specification

Nadat de audio en video MPEG gecodeerd zijn heeft men eenheden die een gecomprimeerde

representatie zijn van een beeld of een geluidsfragment en een voorgedefinieerde syntax volgen.

Deze eenheden worden in het MPEG–jargon access units genoemd. De digitale videosequentie

wordt dus omgezet in een opeenvolging van video access units. De digitale audio wordt eveneens

geconverteerd naar een opeenvolging van audio access units. Een dergelijke opeenvolging van

eenheden noemt men een elementary stream (ES). De opname van de camera in de televisie-

studio wordt dus omgezet naar twee ES’s, een voor audio en een voor video. Gewoonlijk wordt

hieraan nog een ES toegevoegd die teletekst informatie bevat of een ES met ondertiteling. De

MPEG–2 Systems Specification beschrijft hoe deze ES’s gecombineerd kunnen worden tot een

enkele datastroom. Figuur 2.5 toont schematisch dit proces. In de specificatie worden twee

multiplextypes gedefinieerd: de Program Stream (PS) en de Transport Stream (TS). Het eerste

type is bedoeld voor opslag en wordt wereldwijd gebruikt voor het populaire medium DVD. Het

tweede type vindt zijn toepassing in broadcasting. In wat volgt, wordt de structuur van een

transportstroom geschetst. Om onduidelijkheden uit de weg te gaan dient volgende opmerking

gemaakt te worden. De term program wordt in de MPEG–specificaties gebruikt om een televi-

2.2 MPEG–2 12

Figuur 2.5: MPEG–2–multiplexer.

siekanaal aan te duiden. In de broadcastcontext wordt de term gebruikt voor het aanduiden van

een televisieprogramma en wordt een televisiekanaal zelf aangeduid als een service. Wanneer

in het onderstaande de term kanaal wordt vermeld, dient dit geınterpreteerd te worden als een

program in de MPEG–context.

Een kanaal bestaat, zoals boven aangehaald, typisch uit meerdere ES. De TS werd ontworpen

om meerdere kanalen te transporteren. Een dergelijk soort TS wordt een Multi Program Trans-

port Stream (MPTS) genoemd. De TS waar slechts een kanaal aanwezig is, wordt aangeduid

met Single Program Transport Stream (SPTS). Het eigenlijke multiplexen van de verschillende

kanalen start met het omvormen van de ES’s van elk kanalen tot een Packetised Elementary

Stream (PES). Daartoe worden de access units, waaruit de ES is opgebouwd worden, opge-

nomen als inhoud van PES–packets. Deze PES–pakketten zijn de bouwstenen van de PES.

Figuur 2.6 toont het omvormen van een ES tot PES. Elk PES–pakket heeft een header en een

payload. De lengte van de PES–pakketten kan variabel zijn maar is naar boven begrensd. De

PES–pakketten zelf worden vervolgens opgesplitst in pakketten van 184 bytes. Aan elk pakket

wordt tenslotte een vier bytes grote header toegevoegd. De bekomen eenheden zijn TS–packets.

Deze pakketten zijn tenslotte de eenheden waaruit een TS is opgebouwd. TS–pakketten, van

elke ES van een kanaal en van verschillende kanalen, worden gemultiplexed in een datastroom.

De header van het TS–pakket bevat een verwijzing naar de originele ES waartoe de inhoud

2.2 MPEG–2 13

Figuur 2.6: ES–en PES–structuur.

van het TS–pakket behoort. Deze verwijzing heet de Packet Identifier (PID) en is belangrijk

in het reconstrueren van de kanalen die aanwezig zijn in de TS. Figuur 2.7 geeft een schema-

tische voorstelling van het multiplexen van de verschillende TS–pakketten tot een MPTS. De

Figuur 2.7: MPEG–2 Transport Stream.

TS–pakketten kunnen beschermd wordt met foutprotectie zoals Reed–Solomon–codes. Elke TS,

bestaande uit een opeenvolging van TS–pakketten, wordt tenslotte RF–gemoduleerd op de juis-

te carrier, RF–gemultiplexed en uitgezonden via kabel, antenne of satelliet. De bovenstaande

uiteenzetting schetst kort hoe digitale televisie gevormd wordt, startend met de opname in de

televisiestudio tot de transmissie van de digitale informatiestroom. Maar hoe kan de STB in

de woonkamer nu deze digitale informatiestroom decoderen tot de gebruikelijke televisiekanalen?

2.2 MPEG–2 14

De reconstructie van een televisiekanaal begint met het afstemmen van de STB op de fre-

quentie van de TS. Daarna moet de STB achterhalen welke kanalen aanwezig zijn in de TS.

Zoals op de figuur 2.5 te zien is, moet er naast ES’s ook andere informatie toegevoegd worden,

waaronder Program Specific Information (PSI). Deze informatie wordt eveneens opgenomen in

TS–pakketten zoals ook te zien is in figuur 2.7. De PSI is belangrijk voor het decoderen. Deze

informatie omschrijft de structuur van de multiplex en is vervat in PSI–tabellen. De MPEG–2

Systems Specification beschrijft vier zulke tabellen: de Program Assocation Table (PAT), de

Program Map Table (PMT), de Network Information Table (NIT) en de Conditional Access

Table (CAT).

2.2.2.1 Program Association Table (PAT)

De STB start de reconstructie door het ophalen van de PAT. De PAT geeft aan welke kanalen

die aanwezig zijn in de TS. De PAT kan eenvoudig in de TS worden gevonden doordat de TS–

pakketten die de PAT informatie bevatten steeds PID–waarde nul hebben. Figuur 2.8 toont

een voorbeeld PAT. In de PAT wordt voor elk kanaal, dat aangeduid wordt met een program

Figuur 2.8: Program Association Table (PAT).

2.2 MPEG–2 15

number5, de PID–waarde gegeven van de TS–pakketten die de PMT van het kanaal bevatten.

De volgende stap die de STB moet nemen om een kanaal te kunnen decoderen, is het ophalen

van de PMT.

2.2.2.2 Program Map Table (PMT)

Eens de PID–waarde van de PMT van het gezochte televisiekanaal is bekomen, wordt de PMT

gereconstrueerd. Daartoe selecteert de STB de TS–pakketten met de PID–waarde van de PMT

van het kanaal. Figuur 2.9 toont de PMT van kanaal met nummer drie. De PMT bevat voor

Figuur 2.9: Program Map Table (PMT).

elke ES die aanwezig is in het kanaal de PID–waarden van de TS–pakketten die informatie van

de ES bevatten. Zo kan op figuur 2.9 het volgende worden afgelezen. Er is een ES die video

bevat en aanwezig is in TS–pakketten met PID–waarde 41. Verder zijn er ook drie ES’s met

audio die terug te vinden zijn in de TS–pakketten met respectievelijke PID–waarden 80, 81 en

82. TS–pakketten met PID–waarde 90 bevatten de ondertiteling. Op deze manier kan de STB

het televisiekanaal filteren uit de multiplex en decoderen.

2.2.2.3 Network Information Table (NIT) & Conditional Access Table (CAT)

De NIT verschaft informatie over het fysieke netwerk waarover de TS wordt geleverd. De NIT

wordt in de PAT aangeduid met kanaalnummer nul, zoals ook op figuur 2.8 te zien is. Deze5In de MPEG–context wordt een kanaal een program genoemd, vandaar dat het kanaalnummer omschreven

wordt als program number.

2.2 MPEG–2 16

informatie omvat onder meer de kanaalfrequenties, modulatiekarakteristieken, enz.. De CAT is

aanwezig indien een ES binnen de TS gescrambled6 is. In dat geval geeft de CAT onder meer

aan welk scramblingsysteem gebruikt wordt. Voor meer informatie over beide tabellen alsook

hun toepassing wordt verwezen naar [25].

2.2.2.4 DVB Service Information

In de DVB–standaard worden nog enkele bijkomende tabellen gedefinieerd die aangeduid worden

als DVB Service Information (DVB SI). De MPEG–2 PSI–tabellen beschrijven vooral de struc-

tuur van de multiplex. De DVB SI–tabellen geven de STB extra informatie over het netwerk

en de inhoud van de verschillende kanalen die aanwezig zijn in de multiplex. Voorbeelden van

DVB SI–tabellen zijn onder meer de Event Information Table (EIT) en de Service Description

Table (SDT). De EIT verschaft informatie over programma’s, het moment waarop ze starten,

hun duur, enz.. De SDT beschrijft dan weer de aanwezige kanalen, de provider, enz... Voor een

gedetailleerde beschrijving wordt verwezen naar [19]. De DVB SI–tabellen worden net als de

MPEG–2 PSI–tabellen opgenomen in TS–pakketten.

2.2.2.5 Timing Model

Een belangrijk aspect bij het decoderen van digitale televisie is timing. Elk kanaal in een MPEG–

2 MPTS heeft een eigen onafhankelijke klok waarvan tijdsstempels, die Program Clock References

(PCR) worden genoemd en opgenomen zijn in de header van MPEG–2 TS–pakketten. Een

tijdsinterval tussen opeenvolgende PCR–waarden dient volgens de MPEG–2–standaard kleiner

dan of gelijk te zijn aan 100 ms. Als een MPEG–decoder afstemt op een kanaal om de media

te decoderen, zal de decoder zijn interne klok synchroniseren met de klok van het kanaal aan

de hand van deze PCR–waarden7. De synchronisatie is nodig om op de correcte tijdstippen

access units waaruit een ES bestaat te decoderen en presenteren. Elk PES–pakket bevat een

Presentation Time Stamp (PTS) en mogelijk ook een Decoding Time Stamp (DTS). Figuur 2.10

geeft dit alles schematisch weer. Indien enkel een PTS voorkomt dan geeft dit tijdsstempel het

moment aan waarop een access unit gedecodeerd en gepresenteerd moet worden aan de gebruiker.

Bevat een PES–pakket een DTS en een PTS, dan bepaalt de eerste stempel het moment waarop

de access unit gedecodeerd moet worden en de tweede stempel wanneer de presentatie ervan moet6Er zijn verschillende encryptiesystemen in gebruik zoals VideoGuard in het Verenigd Koninkrijk en in Italie

en NagraVision in Duitsland. Meer informatie over scrambling en conditionele toegang is te vinden in [12].7Dit synchroniseren gebeurt aan de hand van een fasevergrendelingslus.

2.2 MPEG–2 17

Figuur 2.10: Timing.

gebeuren. In dit geval zal de PTS steeds een grotere waarde hebben dan de DTS en dus een

later tijdstip aanduiden. Een dergelijke scheiding van decoderen en presenteren is bijvoorbeeld

nodig door het gebruik van B–frames. De PTS en DTS worden vergeleken met de waarde van

de interne klok waardoor het belang van een nauwkeurige kloksynchronisatie duidelijk naar voor

komt.

2.2.3 MPEG–2 Extensions for DSM–CC

Digital Storage Media – Command and Control (DSM–CC) is een standaard waarmee langs het

broadcastkanaal data kan worden getransporteerd. DSM–CC is gebaseerd op een carrouselprin-

cipe waarbij informatie periodiek uitgezonden wordt. Het teletekstsysteem gebruikt hetzelfde

principe. De ontvanger die een bepaalde pagina wenst, moet wachten tot de pagina, die in

de carrousel is opgenomen, terug wordt uitgezonden. DSM–CC kent twee carrousel types: de

datacarrousel en de objectcarrousel. Bij het eerste type wordt data in blokken gezonden maar

is er een bijkomende informatie over de eigenschappen van die data. Het tweede type, de ob-

jectcarrousel, bouwt verder op het eerste type en biedt een directorystructuur waarin informatie

is ondergebracht. De informatie die langs het broadcastkanaal wordt verzonden kan tekst zijn,

maar ook afbeeldingen of applicaties.

2.3 iDTV 18

2.2.4 MPEG–2 Profiles & Levels

De MPEG–2–standaard omvat heel wat functionaliteit en omdat het onwaarschijnlijk is dat

een applicatie alle functionaliteit nodig heeft, worden profiles en levels gedefinieerd. Profielen

en levels zijn bedoeld om het implementeren van de standaard in producten te vereenvoudigen

en interoperabiliteit tussen implementaties te garanderen. Elk profiel beschrijft capabilities,

bepaalde functionaliteiten die aanwezig zijn in het profiel. Zo is onder meer het Main profile

gedefinieerd. Dit profiel bevat alle kernfunctionaliteiten van de standaard, zoals B–frames en

ondersteuning voor geınterlinieerde video. Naast het Main Profile worden nog een vijftal andere

profielen beschreven. Een level beschrijft de spatiale en temporele resolutie die ondersteund

worden. Er zijn vier levels gedefinieerd in de MPEG–2–standaard. Het Main Level bijvoorbeeld

laat een spatiale resolutie toe die 720 pixels breed en 576 pixels hoog is, en een temporele

resolutie tot 30 beelden per seconde. Voor DVB wordt het Main Profile gebruikt in combinatie

met het Main Level.

2.3 iDTV

De interactiviteit bij analoge televisie is beperkt. De kijker kan via de afstandsbediening de

zender van zijn keuze selecteren en teletekst informatie opvragen. De interactiviteit wordt soms

verhoogd door de kijker te laten interageren met de programma’s die hij aan het bekijken is. De

interactie gebeurt dan via kanalen zoals televoting en SMS waarlangs de kijker bijvoorbeeld zijn

keuze kan doorsturen. Deze kanalen staan echter wel los van de televisie. Dit principe wordt

nu al toegepast bij het Eurovisie Songfestival. Gezien de massale reactie van het publiek is het

duidelijk dat de gebruiker de extra interactiviteit op prijs stelt. Interactive Digital Television

(iDTV) verruimt de ervaring van de kijker door naast digitale televisie, zoals die boven wordt

beschreven, ook interactiviteit aan te bieden. Deze interactiviteit wordt gerealiseerd aan de hand

van applicaties. Elektronische programmagidsen (EPG), spelletjes, leerapplicaties en videocon-

ferencing zijn slechts een greep uit het aanbod. Zoals in figuur 2.1 wordt getoond, is de centrale

eenheid in de opstelling de STB. De STB zal in de eerste plaats het digitale broadcastsignaal

decoderen en naar de televisie voeren. Daarnaast kunnen op de STB ook applicaties uitgevoerd

worden zoals bijvoorbeeld een EPG. In figuur 2.1 is ook een andere belangrijke eigenschap weer-

gegeven, namelijk het terugkeerkanaal. Dit kanaal kan gebruikt worden om voorkeuren van de

gebruiker door te geven, waardoor interactiviteit niet alleen lokaal maar ook globaal kan zijn.

2.3 iDTV 19

De architectuur van een STB is gelaagd en er kunnen steeds een drietal lagen worden onderschei-

den die worden afgebeeld in figuur 2.11. De system resources layer bevat de hardwarebronnen

Figuur 2.11: STB–architectuur.

zoals CPU , RAM , GPU , MPEG–decoder, ... Hoewel deze opsomming doet denken aan een

PC–platform is het belangrijk op te merken dat de hardwarebronnen beperkt zijn. Een STB is

een product bedoeld voor massaproductie en massaconsumptie. Het spreekt dan ook voor zich

dat de hardwarebronnen aanwezig in de eenheid eerder gekozen zijn met betrekking tot kost dan

met betrekking tot performantie. Bij de ontwikkeling van applicaties voor de STB moet hier

dan ook voldoende rekening mee gehouden worden. Bovenop de system resource layer bevindt

zich de system software layer. Deze laag bevat het besturingssysteem en de applicatiebeheerder.

De applicatiebeheerder staat in voor het beheren van applicaties die uitgevoerd worden op de

STB en de bronnen die daarvoor worden gebruikt. De hoogste laag is de applications layer

die de applicaties bevat. De applicaties kunnen aanwezig zijn in opslagruimte in de STB maar

kunnen ook ontvangen worden via het broadcastkanaal door middel van DSM-CC. De software

stack in de STB is eveneens gelaagd en heeft een middleware–platform tussen de applicaties en

systeemsoftware. Het middleware–platform verbergt de systeemsoftware en systeemhardware

voor de applicatieontwikkelaar en maakt applicaties portable. Er zijn verschillende middleware–

oplossingen voor handen. Sommige zijn gebaseerd op de Java Virtual Machine (JVM). Ze

kunnen ingedeeld worden in twee groepen; de open platformen en de particuliere platformen.

Onder de laatste categorie vallen onder meer OpenTV, MediaHighway, Power TV en Liberate.

Deze platformen worden vaak gebruikt door commerciele broadcasters zoals bijvoorbeeld Ca-

nal+ en Bsky. In de categorie open platformen vinden we onder meer het Multimedia Home

2.4 Multimedia Home Platform (MHP) 20

Platform (MHP) [16] en het OpenCable Applications Platform (OCAP) [5].

2.4 Multimedia Home Platform (MHP)

In 1997 werd binnen het DVB–consortium een groep opgericht die de naam DVB–MHP draagt.

Deze groep is verantwoordelijk voor het uitbrengen van de MHP–specificaties. De MHP–

specificaties beschrijven een open middleware–platform voor iDTV. De laatste specificatie, MHP

Specifications 1.1.1 [16], verscheen in 2003 en ondertussen zijn al heel wat MHP–compatibele

STB’s beschikbaar. Een open platform bewerkstelligt een horizontale markt waarin applicaties

portable zijn en er concurrentie mogelijk is. Applicaties die ontwikkeld worden voor MHP, zullen

uitgevoerd kunnen worden op elke MHP–compatibele STB. MHP gebruikt de DVB–specificaties

en in de MHP–specificaties wordt de structuur en de componenten van het platform gedefini-

eerd. MHP Specifications 1.0.2 [15] en MHP Specifications 1.1.1 [16] beschrijven de basis ar-

chitectuur, het application model, de applicatiesignalisatie, het DVB–J–platform, het grafisch

model in MHP, beveiliging, enz.. Figuur 2.12 toont de architectuur van MHP en de verschillende

componenten. Enkele van de componenten worden hierna kort geschetst.

Figuur 2.12: MHP–architectuur.


2.4.1 DVB–J Platform

De kern van MHP is gebaseerd op het DVB–J–platform. Dit platform gebruikt de JVM van

Sun8. De JVM verschaft een gemeenschappelijke interface ongeacht verschillende software en

hardware implementaties. MHP–applicaties, xlets zoals ze genoemd worden, zullen dus hetzelfde

gedrag vertonen ongeacht de onderliggende hard–en software van de STB. Het DVB–J–platform

biedt een aantal API’s aan waarlangs een xlet toegang heeft tot verscheidene bronnen van de

STB. In figuur 2.12 worden deze afgebeeld. De Sun Java–API’s bevatten onder meer het Java

Media Framework (JMF) [38], voor het presenteren en controleren van audio en video, en de

Abstract Window Toolkit (AWT) [37], voor het creeren van user interfaces. De HAVi–API’s9

zijn bedoeld voor presentatie en gebruikerinterfaces. De DAVIC–API’s10 bieden functionaliteit

in verband met het gebruik van hardware bronnen, conditionele toegang en tuning. Tenslotte zijn

er nog de DVB–API’s die uitbreidingen of beperkingen omvatten voor de Java–API’s, beveiliging

incorporeren, enz...

2.4.2 Applicatiemodel

Op de STB kunnen MHP–applicaties uitgevoerd worden. Naar analogie met applets, zoals die

gebruikt worden op internet, wordt in de MHP–specificatie een applicatiemodel gedefinieerd voor

xlets. Het applicatiemodel beschrijft de levenscyclus van de xlets. Er worden vier toestanden

gedefineerd: Loaded, Paused, Active en Destroyed. Figuur 2.13 toont de verschillende toestanden

en de toestandstransities. Belangrijk is op te merken dat simultaan op de STB verscheidene xlets

in parallel kunnen worden uitgevoerd. Daarom moeten deze ook de bronnen van de STB delen.

2.4.3 Applicatiesignalisatie

Hierboven werd reeds vermeld dat in de DVB–specificaties DVB SI–tabellen worden gedefinieerd

die de reeds aanwezige MPEG–2 PSI–tabellen aanvullen met additionele informatie. Op dezelfde

manier wordt, in de MHP–specificaties, de Application Information Table (AIT) gedefinieerd.

Deze tabel bevat informatie over de locatie van applicaties, over de applicaties die uitgevoerd

mogen worden als op een bepaald televisiekanaal wordt afgestemd en ook welke applicaties

automatisch opgestart moeten worden.8Sun Microsystems Inc., http://www.sun.com9Home Audio Video interoperability, http://www.havi.org

10Digital Audio–Visual Council, http://www.davic.org


Figuur 2.13: Levenscyclus xlet.

2.4.4 Grafisch Model in MHP

In MHP kan de applicatie–ontwikkelaar gebruik maken van verschillende componenten voor het

weergeven van afbeeldingen, knoppen, tekst, enz... Het beeld dat de gebruiker ziet is steeds

opgebouwd aan de hand van vlakken, het ene boven op het andere. Er worden in de MHP–

specificatie drie vlakken gedefinieerd: het achtergrondvlak, het videovlak en het grafisch vlak

[16]. Figuur 2.14 toont deze drie vlakken. In het achtergrondvlak kan een statische afbeelding,

Figuur 2.14: Grafisch model in MHP.

zoals een MPEG–2 I–frame, of een bepaalde monotone kleur worden weergegeven. In het video-


vlak wordt de video getoond. In het grafisch vlak kunnen afbeeldingen worden weergegeven of

componenten waarmee de gebruiker kan interageren zoals knoppen.

2.4.5 MHP–Profielen

Net zoals in de MPEG–2–standaard definieren de MHP–specificaties drie profielen: het Enhan-

ced Broadcasting Profile [15], het Interactive Broadcasting Profile [15] en het Internet Access

Profile [16]. Elk profiel beschrijft een bepaalde functionaliteit en heeft een toepassingsdomein.

Een profiel omschrijft ook de vereisten waaraan een STB, die voldoet aan het profiel, moet

beantwoorden. Figuur 2.15 geeft deze profielen schematisch weer.

Figuur 2.15: MHP–profielen.

Het Enhanced Broadcasting–profiel beschrijft de basisfunctionaliteit die ook terug te vinden is

in bestaande middlewaresystemen. Het verondersteld niet dat de STB beschikt over een terug-

keerkanaal. Het Interactive Broadcasting–profiel vereist daarentegen wel dat de STB beschikt

over een terugkeerkanaal. Het terugkeerkanaal kan volgens dit profiel gebruikt kan worden voor

het downloaden van applicaties wat niet mogelijk is in het Enhanced Broadcasting–profiel. Het

Internet Access–profiel heeft betrekking op het toegankelijk maken van internetdiensten op de

STB. Dit vereist weliswaar wel een meer gesofistikeerde STB.


Het MHP–platform leent zich ideaal tot het aanbieden van verschillende nieuwe diensten, die

televisie kijken ingrijpend zullen veranderen. Toch verloopt het implementeren van live event

broadcasting en videoconferencing voor het MHP niet zonder uitdagingen. Volgend hoofdstuk

behandelt de problemen alsook de gekozen oplossingen.

LIVE EVENT BROADCASTING & VIDEOCONFERENCING VOOR MHP 25

Hoofdstuk 3

Live Event Broadcasting &

Videoconferencing voor MHP

3.1 Probleemstelling

In het hoofdstuk 1 werden voor live event broadcasting en videoconferencing de requirements

geschetst. Deze vereisten moeten gerealiseerd worden op het MHP–platform en binnen de tech-

nische mogelijkheden van de STB. Zoals zal blijken, zijn sommige vereisten echter niet eenvoudig

te verwezenlijken en vergen een specifieke oplossing. In wat volgt, worden de problemen aange-

kaart en de oplossingen voorgesteld. Hernemen we voor beide diensten, live event broadcasting

en videoconferencing, een concreet voorbeeld.

Een typisch voorbeeld van een live event is een muziekconcert. Het concert wordt tegelijker-

tijd opgenomen vanuit verschillende standpunten waardoor de gebruiker keuze heeft hoe hij het

concert wil beleven. Hij kan op elk moment beslissen van camerastandpunt te veranderen, een

vorm van interactiviteit die bij huidige televisie niet voorkomt. Dit betekent dus dat minstens

het Interactive Broadcasting–profiel vereist is, waarvan eerder sprake was in 2.4.5, zodat de ge-

bruiker zijn voorkeur kan doorgeven. Een vertraging tussen de opname en de weergave op het

televisiescherm is aanvaardbaar, maar wordt bij voorkeur zo klein mogelijk gehouden.

Twee gebruikers wensen een videoconferencing sessie op te zetten. Ze bevinden zich beide

in hun woonkamer en willen op een vloeiende wijze met elkaar kunnen communiceren via het

televisiescherm. In tegenstelling tot live event broadcasting is vertraging hier erg belangrijk en

3.2 Ontvangen van Videostroom 26

moet zo klein mogelijk gehouden worden om een aangename videoconferentie te bekomen. Een

gebruiker moet natuurlijk ook kunnen kiezen met wie hij een videoconferentie aangaat, opnieuw

is dus het Interactive Broadcasting Profile–profiel vereist. Een ander cruciaal aspect is natuurlijk

het opnemen van audio en video. Een gebruiker moet niet alleen een audiovisuele stroom van

de andere gebruiker in de conferentie kunnen ontvangen, hij moet ook een dergelijk stroom van

zichzelf doorsturen.

Bij de beide diensten moet een audiovisuele stroom geleverd worden op vraag van de gebrui-

ker. De term videostroom wordt in wat volgt, gebruikt om dergelijke audiovisuele stroom aan

te duiden. Dat de videostroom bovendien live is, wordt impliciet verondersteld. Naast deze

gemeenschappelijke vereiste is voor videoconferencing ook opname noodzakelijk. Samengevat

dient het volgende gerealiseerd worden.

• Videostroom ontvangen op de STB bij zowel live event broadcasting als videoconferencing.

• Audio en video opnemen bij videoconferencing bijvoorbeeld met een webcam.

• Vertraging bij voorkeur beperken voor live event broadcasting en minimaliseren voor vi-

deoconferencing.

Er wordt bovendien aangenomen dat de videostroom afkomstig is van een IP–netwerk. Deze

veronderstelling wordt gemaakt omwille van de eenvoudige reden dat er tegenwoordig meer en

meer gebruikt wordt gemaakt van IP in zogenaamde backbone–netwerken. De veronderstelling

behoudt dus de algemeenheid en bijgevolg kan de videostroom afkomstig zijn van eender welk

netwerk dat IP gebruikt. In wat volgt, worden de eerste twee vereisten behandeld en wordt

gezocht hoe deze vereisten in de MHP–specificatie en binnen de mogelijkheden van de STB’s

kunnen worden vervuld. De vertraging is natuurlijk evenzeer belangrijk maar komt in een

volgend hoofdstuk aan bod.

3.2 Ontvangen van Videostroom

Figuur 2.1 toont de opstelling die in de woonkamer aanwezig is voor het ontvangen van iDTV.

De centrale eenheid in de opstelling de STB en zoals op de figuur te zien is, beschikt de STB over

twee kanalen. Het eerste kanaal, het broadcastkanaal, is unidirectioneel. Langs dit kanaal wordt

digitale televisie ontvangen. Het tweede kanaal, het terugkeerkanaal, is bidirectioneel en kan


gebruikt worden om keuzes van de gebruiker door te geven of informatie te ontvangen. Het te-

rugkeerkanaal kan verschillende vormen aannemen. Het kan een lage snelheid internetconnectie

zijn, door middel van een PSTN–modem of GPRS, maar evengoed een hogesnelheid internetcon-

nectie zijn, via een kabelmodem. Er zijn twee kanalen waarlangs een videostroom ontvangen zou

kunnen worden: het broadcastkanaal en het terugkeerkanaal. Gezien de flexibiliteit waarmee een

kijker een live–uitzending moet kunnen kiezen of waarmee een gebruiker een videoconferentie

moet kunnen opzetten, lijkt het terugkeerkanaal de beste keuze. De MHP–specificatie beschrijft

de interactieprotocollen die gebruikt kunnen worden voor dit terugkeerkanaal. Figuur 3.1 toont

een overzicht van deze protocollen.

Figuur 3.1: Protocollen voor het terugkeerkanaal.

Voor het zenden van een live videostroom wordt gewoonlijk gebruik gemaakt van UDP over IP

om vertragingen klein te houden. Beide protocollen zijn aanwezig in de protocolstack van het

terugkeerkanaal.

3.2.1 MHP Exploratie

In de MHP–specificatie is er geen voor de hand liggende ondersteuning te vinden om via het

terugkeerkanaal een videostroom te ontvangen. Video drips, kleine videofragmenten, kunnen wel

langs het terugkeerkanaal worden ontvangen maar zijn niet geschikt voor toepassingen in ware


tijd. Er werden een aantal mogelijkheden uitgeprobeerd om, weliswaar binnen de grenzen van

de MHP–specificatie, toch via het terugkeerkanaal een videostroom te ontvangen. Deze worden

in wat volgt een voor een behandeld.

3.2.1.1 Video Weergave in het Achtergrondvlak

Zoals ook in hoofdstuk 2 werd aangehaald, zie 2.4.4, zijn er binnen het grafisch model van MHP

drie vlakken te onderscheiden: het achtergrondvlak, het videovlak en het grafisch vlak. Het

achtergrondvlak kan gebruikt worden om een egale kleur of een MPEG–2 I–frame in weer te

geven [15]. MPEG–2 I–frames kunnen ontvangen worden via het terugkeerkanaal. Het lijkt

dus in principe mogelijk om een videosequentie te coderen als een opeenvolging van MPEG–2

I–frames en die aan een voldoende hoge snelheid weer te geven in het achtergrondvlak. Zo zou

de illusie van video worden gecreeerd. Deze manier van werken heeft echter een aantal evidente

nadelen. Zoals ook in 2.2.1 wordt vermeld, wordt bij MPEG–2 I–frames intra frame coding

toegepast. De videosequentie zou heel weinig gecomprimeerd worden en er zou dus een hoge

bandbreedte nodig zijn wat, gezien de mogelijke vormen die het terugkeerkanaal kan aannemen,

niet gegarandeerd is. Verder is er dan ook onzekerheid over de haalbare beeldsnelheid en of die

beeldsnelheid zou varieren tussen verschillende STB’s.

3.2.1.2 Video Weergave in het Grafisch Vlak

Er kan natuurlijk ook gebruik worden gemaakt van het grafisch vlak. In het grafisch vlak kunnen

afbeeldingen worden weergegeven. De toegelaten formaten zijn PNG, GIF en JPEG. Encoderen

van de videosequentie als een opeenvolging van JPEG–frames1 en deze weergeven in het grafisch

vlak zou eveneens een oplossing kunnen zijn. Ook deze manier van werken heeft een aantal

nadelen. Het weergeven van afbeeldingen in het grafisch vlak is een intensieve taak voor een

STB. Opnieuw is er onzekerheid met betrekking tot de haalbare beeldsnelheid. Daarnaast is

in MHP–specificatie 1.0.2 nog een bijkomende beperking. Een STB die aan deze specificatie

voldoet, hoeft in het grafisch vlak slechts over een kleurenpalet bestaande uit 188 kleuren te

beschikken [15]. Dit betekent dat elke afbeelding, die wordt weergegeven in het grafisch vlak,

getransformeerd zal worden naar deze 188 kleuren. Deze transformatie kan resulteren in een

slechte weergave van de videosequentie. Deze beperking is echter niet meer aanwezig in MHP–

specificatie 1.1.1 [16].1Dit is het principe bij Motion JPEG–compressie (MJPEG).


Beide pogingen hebben bovendien een belangrijk gemeenschappelijk nadeel. Telkens werd enkel

het video–aspect beschouwd. De videostroom zou opgedeeld moeten worden in beeld en geluid.

De audio zou apart ontvangen moeten worden wat aanleiding kan geven tot synchronisatie-

problemen tussen audio en video bij het afspelen. Dit nadeel heeft de volgende poging echter

niet.

3.2.1.3 JMF Extensie

In het vorig hoofdstuk werd JMF reeds vermeld. De API wordt in MHP gebruikt voor het

presenteren en controleren van audio en video. In JMF wordt naar media gerefereerd met een

locatie–aanduiding, een zogenaamde locator. Het ophalen van de media gebeurt door een data-

bron, een DataSource, en het decoderen en presenteren ervan wordt uitgevoerd door een speler

of Player. Elke speler heeft een of meerdere objecten die functionaliteit toevoegen, die Controls

worden genoemd. Die functionaliteit betreft bijvoorbeeld het regelen van het volume. JMF

gebruikt een manager om voor media een passende databron aan een geschikte speler te linken.

Om de werking van JMF te illustreren nemen we het veelvoorkomende voorbeeld waarbij er

wordt afgestemd op een televisiekanaal. Veronderstel dat dit kanaal aangeduid wordt met de

locatie–aanduiding dvb://0.0.1. Deze aanduiding is een DVB locator en bestaat uit drie ele-

menten; een Network Identifier (ONID), een Transport Stream Identifier (TSID) en een Service

Identifier (SID). De eerste twee elementen duiden het netwerk en de transportstroom aan. Het

laatste element is ook gelijk aan het kanaalnummer zoals dit voorkomt in de PAT, zie hoofd-

stuk 2.2.2. Uit de aanduiding leidt de manager het protocol dvb af. Voor dit protocol wordt

een geschikte databron geınitialiseerd. Daarna wordt de correcte speler gecreeerd en tenslotte

wordt deze verbonden met de databron. De speler ontvangt de media van de databron en start

het decoderen en presenteren.

In JMF 1.0 worden verschillende types databronnen ondersteund. Zo zijn er de Broadcast

DataSource, zoals die voor het protocol dvb wordt gebruikt, de File DataSource, om media uit

een bestand af te spelen en de HTTP DataSource. Op het PC–platform, waarvan JMF wordt

geleend, is er voorziening om eigen databronnen te definieren waardoor JMF uitbreidbaar is. Het

is in principe wel mogelijk om een eigen databron te implementeren waarmee een videostroom

over het terugkeerkanaal kan worden ontvangen maar de ontvangen media zal niet kunnen wor-


den afgespeeld. JMF uitbreiden behoort niet tot de mogelijkheden in MHP.

Samenvattend kan er dus gesteld worden dat het niet mogelijk is binnen de huidige MHP–

specificaties om een videostroom te ontvangen via het terugkeerkanaal. Het is interessant om

de mogelijkheden van huidige en toekomstige STB’s daar tegenover te plaatsen.

3.2.2 STB Voorzieningen

Aangezien een videostroom ontvangen via het terugkeerkanaal in de MHP–specificaties geen

vereiste is, is het ook te verwachten dat de meeste MHP–compatibele set–top boxen deze functi-

onaliteit niet zullen hebben. Er valt op te merken dat sommige fabrikanten dergelijke functiona-

liteit toch in het design opnemen of van plan zijn dit in hun productlijn te voorzien. Dergelijke

boxen zijn vandaag misschien minder courant, maar zullen waarschijnlijk in de nabije toekomst

wel vaker opduiken.

3.2.2.1 IP STB

Sommige STB’s hebben wel de mogelijkheid om een videostroom over IP via het terugkeerkanaal

te ontvangen. Deze functionaliteit wordt geıncorporeerd in het STB–design ondanks het feit dat

dit niet in de MHP–specificatie als vereiste wordt vermeld. Een dergelijke STB wordt een IP

set–top box (IP STB) genoemd. Andere fabrikanten voorzien dan weer speciale ASIC–modules

(Application Specific Integrated Circuit) om bestaande set–top boxen van de functionaliteit te

voorzien.

3.2.2.2 IP Triple Play in HFC–netwerken

De term IP Triple Play wordt gebruikt om de combinatie van video–, spraak–en datadiensten

over IP aan te duiden. Datadiensten over IP zijn al lang beschikbaar en sinds geruime tijd wordt

er Voice over IP (VoIP) aangeboden op het PC–platform en ook door middel van IP–telefoons.

De laatste dienst, video, wordt momenteel nog niet over IP aangeboden maar er kan verwacht

worden dat IP Television (IPTV) weldra geıntroduceerd zal worden. Het grote voordeel voor

de operator is dat bij de drie diensten telkens dezelfde infrastructuur kan worden gebruikt.


In een HFC–toegangsnetwerk2 wordt de DOCSIS–standaard gebruikt om IP–verkeer te trans-

porteren. De standaard beschrijft hoe IP–pakketten, die bijvoorbeeld spraak of data bevatten,

kunnen geencapsuleerd worden in MPEG–2–TS–pakketten voor transport over het kabelnet-

werk. Langs de gebruikerszijde ontvangt een cable modem (CM) de MPEG–2 TS, haalt de

IP–pakketten uit de TS en levert deze af aan een apparaat dat met de CM is verbonden. Zo

kan een PC bijvoorbeeld spraak over IP ontvangen. Het terugkeerkanaal van een STB kan tot

stand gebracht worden door aansluiting op de CM.

Er zijn fabrikanten die STB’s hebben aangekondigd die CM–functionaliteit zullen bezitten [4].

Een dergelijke Dual Feed Set–Top Box heeft twee tuners zoals in figuur 3.2 wordt geıllustreerd.

Een van beide tuners wordt gebruikt voor het afstemmen op een MPEG–2 TS en het ontvangen

Figuur 3.2: Dual feed set–top box.

van digitale televisie. De andere kan gebruikt worden om IP–pakketten te ontvangen die volgens

de DOCSIS–standaard in een MPEG–2 TS zijn ondergebracht. Bovendien kunnen deze STB’s,

als de IP–pakketten bijvoorbeeld video bevatten, de ontvangen video wel afspelen.

Beide voorbeelden tonen aan dat fabrikanten geneigd zijn om ondersteuning te bieden voor

ontvangen van video over IP via het terugkeerkanaal. Door deze functionaliteit ook in de MHP–

standaard op te nemen, zou MHP dichter bij IPTV worden gebracht. MHP voor IPTV is

trouwens ook al voorgesteld [33].2Een HFC–netwerk is een netwerk dat bestaat uit een hybride van coaxkabel en glasvezel. De hybride komt

tot stand door het upgraden van het bestaande kabelnetwerk door middel van optische technologie. De structuur

een HFC–netwerk wordt in volgend hoofdstuk beschreven.


3.2.3 IP2DVBGateway & IP2DVBScheduler

Na de bovenstaande uiteenzetting luidt de conclusie dat het terugkeerkanaal niet aangewend

kan worden om een videostroom te ontvangen. Er kan immers geen beroep worden gedaan op

speciale boxen die wel over dergelijke functionaliteit beschikken want dat zou de portabiliteit

van de applicatie in gevaar brengen. Hoe kan de videostroom dan tot bij de gebruiker wor-

den gebracht die erom vraagt? De oplossing bestaat erin de videostroom op te nemen in de

broadcast waardoor de STB die kan ontvangen via het broadcastkanaal. De videostroom zal

opgenomen worden in een kanaal en bij de andere aanwezige kanalen worden gevoegd. Deze

functionaliteit zal verzorgd worden door de IP2DVBGateway. Figuur 3.3 toont het principe.

De IP2DVBGateway ontvangt via het IP–netwerk videostromen en deze worden bij andere te-

Figuur 3.3: Principe IP2DVBGateway.

levisiekanalen in de broadcast gevoegd. Gezien de anatomie van digitale televisie, zoals die in

het vorig hoofdstuk werd geschetst, is het overbrengen van een live videostroom naar de broad-

cast echter geen sinecure. Bij digitale televisie, bestaat de broadcast uit televisiekanalen die

MPEG–2 gecodeerd en opgenomen zijn in MPEG–2 TS’s. De videostroom zal, door opname

in de broadcast, beschikbaar worden gemaakt als televisiekanaal. Meteen rijzen enkele vragen.

Hoe gebeurt de toekenning van deze televisiekanalen? Hoe zal de STB op de hoogte worden

gebracht van het kanaal waarop zijn aangevraagde videostroom te zien is?

3.3 Opname van Videostroom 33

De videostroom zal, om opgenomen te kunnen worden in de broadcast, in ieder geval MPEG–2

gecodeerd moeten worden. Er kan geopteerd worden voor een flexibele IP2DVBGateway die

een waaier aan formaten ondersteunt maar dan moet de component het transcoderen van de

videostroom voor zijn rekening nemen. Hier wordt echter gekozen om de eis op te leggen dat

de videostroom reeds MPEG–2 gecodeerd is en geleverd wordt aan de IP2DVBGateway als

een MPEG–2 SPTS. Zo wordt de taak van het transcoderen verlegd naar de bron van de vi-

deostroom. Die bewuste keuze wordt gemaakt met betrekking tot schaalbaarheid, maar heeft

natuurlijk een impact op de bron die een videostroom zal moeten kunnen leveren als SPTS. De

voorwaarde dat de videostroom geleverd wordt als SPTS houdt in dat de videostroom in principe

al behoort tot een digitaal televisiekanaal. Dit televisiekanaal moet echter correct in de broad-

cast opgenomen en gesignaliseerd worden. Daartoe zal de structuur van de SPTS die naar de

IP2DVBGateway wordt gezonden aan bepaalde voorwaarden moeten voldoen. De structuur be-

treft de ID–waarden voor netwerk, transportstroom en kanaal en de PID–waarden van de PMT

en de ES’s. De ID–waarden vormen ook de locatie–aanduiding in de broadcast en zullen gebruikt

worden om de STB mede te delen waar in de broadcast het televisiekanaal met de videostroom

terug te vinden is. Het voorschrijven van de structuur van SPTS’s die naar de IP2DVBGateway

gezonden mogen worden, zal de taak zijn van de IP2DVBScheduler. De IP2DVBScheduler zal

het aanspreekpunt zijn om een kanaal in de broadcast te reserveren zodat er een videostroom

in kan opgenomen worden. De IP2DVBScheduler zal controle uitoefenen op de IP2DVBGateway.

Er zijn hardware oplossingen die de bovenbeschreven functionaliteit vervullen. De kostprijs

van dergelijke producten is echter hoog en de eenheden zijn ook niet zo flexibel.

3.3 Opname van Videostroom

Het is evident dat bij videoconferencing elke deelnemer beschikt over opname–apparatuur zodat

andere deelnemers hem kunnen zien en horen. Deze functionaliteit wordt echter niet beschreven

in de MHP–specificaties en evenmin zijn de huidige STB’s hierop voorzien.

3.3.1 MHP Exploratie

In de MHP–specificaties zijn er niet veel ondersteunde randapparaten te vinden. De enige

apparaten die worden vermeld, zijn de afstandsbediening en het toetsenbord. Gezien het poten-

tieel van videoconferencing lijkt het nochtans waarschijnlijk dat toekomstige MHP–specificaties


ondersteuning zullen bieden. Daartoe zullen keuzes gemaakt moeten worden met betrekking

tot interoperabiliteit. De specificaties kunnen de ondersteuning voorschrijven van algemene

opname–apparatuur zoals een USB–camera ofwel kan een specifieke eis opgelegd voor welbe-

paalde apparatuur. Bovendien moet het formaat voor transmissie, van de opgenomen audio

en video, worden vastgelegd. Enerzijds betekent dit dat de STB van een encoder zal moeten

voorzien zijn en anderzijds zal de beoogde ontvanger, een andere STB, de gezonden media ook

moeten kunnen decoderen. Dit kan de kost van de eenheid aanzienlijk verhogen afhankelijk van

de gekozen standaard voor het encoderen en decoderen. Er zijn standaarden voor videocodering,

zoals H.261 en H.263, die acceptabele kwaliteit combineren met voldoende goedkope hardware.

De H.261 en H.263 standaarden worden tegenwoordig vaak gebruikt voor videoconferencing [34].

3.3.2 STB Voorzieningen

Veelal beschikken STB’s slechts over een afstandsbediening. Soms is er ook een toetsenbord

beschikbaar maar een USB-camera aansluiten is niet mogelijk. Sommige fabrikanten voorzien

uitbreidingen aan de hand van een ASIC–module die een ingebouwde camera met microfoon

bevat. Een dergelijke ASIC–module kan niet alleen voor het opnemen worden gebruikt maar

ook voor het ontvangen van een videostroom afkomstig van een andere STB die met eenzelfde

ASIC–module is uitgerust. Het spreekt voor zich dat dergelijke hardwarematige uitbreidingen

voor de STB de implementatie van videoconferencing heel wat vereenvoudigen. Tegelijkertijd

is videoconferencing dan enkel mogelijk tussen set–top boxen voorzien van dergelijke ASIC–

modules.

3.3.3 Capture–Module

Door de STB op te nemen in een thuisnetwerk zijn alternatieven beschikbaar om de opname

van beeld en geluid uit te voeren. Het opnemen kan toegewezen worden aan een entiteit in

het thuisnetwerk. De MHP–applicatie, die wordt uitgevoerd op de STB, kan dan deze enti-

teit aanspreken indien een videoconferentie wordt gestart. Het incorporeren van de STB in

een thuisnetwerk kan op verschillende manieren gebeuren. Er kan gebruik worden gemaakt van

Open Services Gateway Initiative (OSBI)3 of Universal Plug and Play (UPnP)4. OSGI is een

raamwerk waardoor toestellen in het thuisnetwerk met elkaar kunnen communiceren. UPnP is

een geheel van protocollen waarmee dezelfde doelstellingen beoogd worden. Voor OCAP is reeds3http://www.osgi.org4http://www.upnp.org


een extensie verschenen in verband met home networking [6]. Scenario’s met MHP en OSGI

waarin de interactie tussen digitale televisie ontvangers en thuisnetwerken wordt beschreven,

zijn terug te vinden in [40]. Binnen de DVB–MHP–groep werkt een aparte groep, MHP–Home

Networking (MHP–HN), aan dit onderwerp. In wat volgt, wordt enkel verondersteld dat de

STB is opgenomen in het thuisnetwerk door aansluiting op een router. Figuur 3.4 toont de

opstelling. Het terugkeerkanaal wordt verschaft via de router zodat er IP–connectiviteit is. De

Figuur 3.4: Thuisnetwerk.

figuur toont twee voorbeelden van entiteiten die aangesproken kunnen worden door de STB.

Een dergelijke entiteit moet echter wel de opgenomen media kunnen sturen als MPEG–2 SPTS

aan de IP2DVBGateway, zoals eerder beschreven.

Er zijn netwerkcamera’s op de markt beschikbaar die videostroom kunnen leveren in MPEG–

2–formaat. Dergelijke camera’s worden bijvoorbeeld aangewend bij beveiligingstoepassingen of

voor traffic monitoring. De toestellen zijn echter niet bepaald goedkoop wat meteen een groot

bezwaar is tegen het gebruik ervan voor videoconferencing. Een tweede bezwaar is te vinden

in het aansturen van dergelijke netwerkcamera’s. Indien gebruik zou worden gemaakt van een

dergelijke camera zal de MHP–applicatie immers tot op zekere hoogte afhankelijk zijn van het

gebruikte cameratype.

Een alternatief is gebruik te maken van een Capture–module die uitgevoerd wordt op een host in

het thuisnetwerk. Een eenvoudige webcam kan aangesloten worden op de host en de combinatie

van webcam en de softwaremodule vormt een netwerkcamera. De MHP–applicatie kan dan de


softwaremodule aanspreken net zoals een netwerkcamera. Het protocol voor de interactie tussen

MHP–applicatie en de Capture–module kan nu wel eenmalig worden vastgelegd. Hier is de af-

hankelijkheid van het type camera dat wordt gebruikt, verborgen voor de MHP–applicatie. De

STB zal in het thuisnetwerk zoeken naar dergelijke softwaremodules en een dergelijke module

gebruiken om opnames te maken.

De twee vereisten die het moeilijkst te realiseren zijn, het ontvangen van een videostroom

op de STB en het genereren ervan, werden in dit hoofdstuk besproken. De oplossingen, die

gepresenteerd werden, zijn respectievelijk de IP2DVBGateway met IP2DVBScheduler en de

Capture–module. De IP2DVBGateway en IP2DVBScheduler zullen een cruciale rol spelen in

het aanbieden van videostroom op vraag van de gebruiker. De Capture–module zal zorgen voor

het opnemen en het zenden van een videostroom bij videoconferencing. Bij live event broadcas-

ting zal een module met gelijkaardige functionaliteit, de Streamer–module, worden aangewend

om live–uitzendingen te verzorgen. Nu de conceptuele oplossingen voor de problemen voorge-

steld zijn, worden in het volgend hoofdstuk de architecturen voor live event broadcasting en

videoconferencing behandeld.

ARCHITECTUREN VOOR LIVE EVENT BROADCASTING & VIDEOCONFERENCING 37

Hoofdstuk 4

Architecturen voor Live Event

Broadcasting & Videoconferencing

In het vorig hoofdstuk werden bij het presenteren van de oplossingen reeds enkele componen-

ten aangehaald die in de architecturen zullen voorkomen. In beide architecturen zal gebruik

gemaakt worden van de IP2DVBScheduler en de IP2DVBGateway. Live–uitzendingen worden

gegenereerd door Streamer–modules. Het opnemen en zenden van beeld en geluid van een par-

ticipant in een videoconferentie, wordt uitgevoerd door een Capture–module. In dit hoofdstuk

worden de architecturen voorgesteld en komt de functionaliteit van elk van de componenten aan

bod.

4.1 Live Event Broadcasting

4.1.1 Architectuur Exploratie

De gebruiker zal in de woonkamer interageren met een MHP–applicatie die uitgevoerd wordt

op de STB. De applicatie zal de gebruiker een overzicht geven van de live events en tevens de

gebruiker toelaten een live–uitzending te bekijken. Er zal informatie moeten worden opgehaald

over de beschikbare live–uitzendingen. Daarvoor zal een server voorzien worden die door de

applicatie kan bevraagd worden. Ook het aanvragen van een live–uitzending, of een specifiek

camerastandpunt van een bepaald live gebeuren, zal via deze server verlopen. Er is dus sprake

van een client–server–architectuur. De specifieke werking voor het verkrijgen van de informatie

over de live–uitzendingen en het aanvragen ervan is gebaseerd op Podcasting.


4.1.2 Podcasting

De term Podcasting is een samentrekking van iPod1 en broadcasting. Podcasting is een sys-

teem waarbij audio–opnames verspreid kunnen worden via het internet. Daartoe worden audio–

opnames, in een formaat zoals bijvoorbeeld MP3, op het internet geplaatst en er worden ver-

wijzingen naar de opnames bekend gemaakt. Een dergelijke verwijzing wordt een podcast feed

genoemd en is opgesteld volgens het RSS–formaat2. De verwijzing bevat informatie over de

locatie van de opnames, over de opname zelf en de aanbieder ervan. Figuur 4.1 toont sche-

matisch de opbouw van een podcast feed. Opnames zijn ondergebracht in een virtueel kanaal.

Figuur 4.1: Structuur van een podcast feed.

Het begin van een podcast feed bevat informatie over het kanaal zoals de titel, taal en datum

van publicatie. Elke opname wordt beschreven door een item. Ook over elke opname kan in-

formatie worden verschaft. In een item is het belangrijkste XML–element de enclosure. Deze

bijlage bevat de URL waar de opname kan worden gevonden. Er zijn heel wat XML–elementen

aanwezig in een podcast feed, sommige ervan zijn verplicht, andere zijn optioneel. Voor een

grondige beschrijving wordt verwezen naar de RSS 2.0–specificatie [41]. Voor de complete struc-

tuur van een podcast feed wordt verwezen naar appendix A.1. Opdat de gebruiker de opnames

zou kunnen beluisteren wordt een aggregator–programma3 gebruikt. De gebruiker geeft de URL

van podcast feeds, waarvoor hij interesse heeft, bij de aggregator op en abonneert zich op deze

manier op bepaalde kanalen. De aggregator haalt die podcast feeds op regelmatige tijdstippen

op en houdt de gebruiker op de hoogte van nieuwe opnames in de kanalen. Indien de gebruiker

dit wenst kunnen nieuwe opnames gedownload worden. Het downloaden kan gebeuren op de PC1iPod is de populaire MP3–speler van Apple.2Really Simple Syndication (RSS) is een toepassing van XML waarmee de hoofdlijnen, een korte inhoud of

nieuwe artikels van een webpagina samen met de link naar de pagina worden gepubliceerd.3Een dergelijk programma wordt soms ook aangeduid met de term pod catcher.


van de gebruiker maar programma’s zoals iTunes4 laten ook toe dat de opnames direct op een

aangesloten MP3–speler kunnen worden gedownload.

Hetzelfde principe wordt ook al gebruikt voor videobestanden en draagt de naam Vodcasting.

Hoewel Podcasting specifiek het downloaden van de audiobestanden betreft, kunnen bij Vodcas-

ting videobestanden worden gedownload maar worden gestreamd5. Om Vodcasting toe te passen

zal in de architectuur gebruik gemaakt worden van streaming. De structuur van de vodcast feeds,

gelijklopend aan die van de podcast feeds, wordt op enkele plaatsen aangepast of uitgebreid om

bijkomende functionaliteit te bieden. Appendix A.2 toont de structuur van de gebruikte vodcast

feed. De veranderingen worden aangebracht omwille van specifieke redenen.

De eerste aanpassing betreft het url–attribuut van een bijlage. Bij live event broadcasting

zullen live–uitzendingen beschikbaar worden gemaakt. Het attribuut zal hier geen videobestand

aanduiden zoals bij Vodcasting maar een entiteit die instaat voor een bepaalde live–uitzending.

Een dergelijke entiteit is een Streamer-module en het url–attribuut bevat dan ook de URL van

een bepaalde module. De tweede aanpassing volgt uit het feit dat de STB geen videostroom

kan ontvangen via het terugkeerkanaal. Een aangevraagde live–uitzending moet opgenomen

worden in de broadcast maar dit wordt verborgen voor de MHP–applicatie. Opdat eenvoudig

een bepaalde live–uitzending zou kunnen worden aangevraagd, wordt elk kanaal, elk item en

elke bijlage voorzien van een ID. Als er een vodcast feed wordt gedownload op de STB dan

kan een bepaalde live–uitzending, die in de feed ondergebracht is als bijlage, eenvoudig worden

aangevraagd aan de hand van de ID–waarden van het betreffende kanaal, het item en de bijlage

zelf. Deze drie ID–waarden vormen een Vodcast locator. Deze aanduiding is geınspireerd op een

DVB locator en heeft een heel eenvoudige vorm, namelijk vodcast://IDkanaal.IDitem.IDbijlage.

De laatste aanpassing is een extensie. Er wordt voorzien dat een item meerdere bijlagen kan

bevatten. Deze extensie biedt meer flexibiliteit aan de hierarchie van kanalen, items en bijla-

gen. Een kanaal kan nu een live–uitzending als item bevatten, bijvoorbeeld een muziekconcert,

waarbij het item meerdere camerastandpunten heeft, onder de vorm van bijlagen.

Een aantal van de XML–elementen werden vervangen en er werden XML–elementen toege-4http://www.apple.com/itunes5Streaming betekent dat het afspelen van het bestand al kan beginnen nog voor het complete bestand is

ontvangen.


voegd. Zo kan bijvoorbeeld aangeduid worden of authenticatie van de gebruiker vereist is om

een bepaald item te mogen bekijken. Het toevoegen of verwijderen van XML–elementen is in

verder beschreven architectuur overigens toegelaten. De enige vereiste is dat steeds de hierarchie

bestaande uit kanalen, items en bijlagen met de vereiste ID–waarden wordt gerespecteerd. Live

event broadcasting door middel van Vodcasting biedt interessante mogelijkheden. Gebruikers

kunnen zelf virtuele kanalen aanmaken waarop ze live–uitzendingen kunnen toevoegen en verwij-

deren. Naast de conventionele televisiekanalen kunnen gebruikers ook live–uitzendingen bekijken

op de virtuele kanalen van andere gebruikers.

4.1.3 Ontworpen Architectuur

Figuur 4.2 toont de ontworpen architectuur voor live event broadcasting. In wat volgt, worden

de verschillende componenten besproken. Daarna wordt aan de hand van een concreet scenario

de werking uitgelegd.

Figuur 4.2: Architectuur voor live event broadcasting.


4.1.3.1 Componenten

De MHP–applicatie, die uitgevoerd wordt op de STB, bestaat uit drie modules, een Aggregator–

module, een HTTP–module en een GUI–module. Om het ingeven van de URL van een vodcast

feed uit de weg te gaan, zal een HTML–pagina gebruikt worden. De server, die door de appli-

catie bevraagd zal worden, zal een HTML–pagina ter beschikking stellen die hyperlinks bevat

naar alle beschikbare vodcast feeds. Het volstaat dus om de HTML–pagina op te vragen om

te achterhalen welke vodcast feeds er beschikbaar zijn. De Aggregator–module zal, gebruik ma-

kend van de HTTP–module, periodiek de HTML–pagina opvragen. Vervolgens haalt de module

de gerefereerde vodcast feeds op en verwerkt die tot een overzicht van live–uitzendingen. Alle

communicatie tussen de MHP–applicatie en de server gebeurt door middel van HTTP. De ge-

bruiker kan met de applicatie interageren via de GUI–module. De GUI–module presenteert het

overzicht van de live–uitzendingen aan de gebruiker en laat deze toe een keuze te maken. Indien

voor de gekozen live–uitzending meerdere camerastandpunten beschikbaar zijn, kan er tijdens

het bekijken van de live–uitzending van standpunt worden veranderd.

Centraal in de architectuur is de server. De server wordt voorzien van vodcast feeds en biedt

op basis hiervan een HTML–pagina aan. Indien om een specifieke vodcast feed wordt gevraagd,

wordt die ook bezorgd. De server staat ook in voor het behandelen van een vraag naar specifieke

live–uitzending die aangeduid wordt met een Vodcast locator. Daarvoor zal de server eerst op

zoek gaan naar een IP2DVBScheduler die een kanaal ter beschikking kan stellen. Indien een

kanaal gereserveerd is, zal de server de verantwoordelijke Streamer–module vragen de uitzending

te starten. Bovendien kunnen, terwijl het systeem online is vodcast feeds worden aangepast of

bijgevoegd. De eerst volgende keer dat de HTML–pagina wordt opgevraagd zal de pagina dan

ook hyperlinks bevatten naar de nieuwe vodcast feeds. Zo kunnen Aggregator–modules van de

MHP–applicaties hun overzicht actueel houden. Om een live–uitzending toe te voegen aan het

systeem volstaat het om een nieuwe Streamer–module op te starten en op de server de bijhorende

vodcast feed te plaatsen. Het systeem is dus Plug and Play. De server zal ook bijhouden voor

welke gebruiker wat uitgezonden wordt aan de hand van gebruikersidentificatie. Het is immers

evident dat een live–uitzending, of specifieker een camerastandpunt, slecht hoeft uitgezonden te

worden als een gebruiker daarom verzoekt. Als bovendien twee gebruikers hetzelfde aanvragen

dan zal de uitzending eenmaal in de broadcast worden opgenomen. Als de situatie zich voordoet

waarbij een gebruiker aan het kijken is naar een live–uitzending en beslist om een andere uitzen-


ding te bekijken dan moet de eerste uitzending gestopt worden tenzij er nog andere gebruikers

zijn die de eerste uitzending aan het bekijken zijn.

De IP2DVBScheduler biedt kanalen ter reservatie aan waarin media kan worden opgenomen

en controleert de IP2DVBGateway die de videostroom van een uitzending zal opnemen in de

broadcast. Voor elk gereserveerd kanaal worden specifieke eisen gesteld met betrekking tot de

toegelaten MPEG–2 SPTS, die de videostroom bevat, om een correcte signalisatie in de broad-

cast te garanderen. Bij de reservatie van een kanaal worden daartoe configuratieparameters

gegeven voor het gereserveerde kanaal.

De opname van een live–uitzending zal gebeuren aan de hand van een Streamer–module. De

Streamer–module zal de live–opname MPEG–2 coderen en naar de IP2DVBGateway zenden als

MPEG–2 SPTS. De structuur van de SPTS is bepaald door de configuratieparameters van het

gereserveerd kanaal. Een Streamer–module kan instaan voor verschillende live–uitzendingen of

meerdere camerastandpunten van eenzelfde live–uitzending. Elke uitzending wordt aangeduid

met een Vodcast locator die wordt overhandigd aan de module indien een bepaalde uitzending

gestart moet worden.

4.1.3.2 Werking

Het volgende scenario toont de werking van de architectuur. De verschillende stappen zijn

aangeduid in figuur 4.2.

1. De MHP–applicatie wordt opgestart en Aggregator–module vraagt de HTML–pagina van

de server op. De pagina wordt doorzocht naar vodcast feeds. Voor elke gevonden verwij-

zing wordt vervolgens de vodcast feed zelf opgevraagd bij de server. Na deze procedure

presenteert de GUI–module een overzicht aan de gebruiker.

2. De gebruiker kiest de live–uitzending die hij wenst te bekijken. Dit resulteert in een

specifiek verzoek aan de server. Het verzoek bevat de Vodcast locator die de live–uitzending

aanduidt.

3. De server doorzoekt de vodcast feeds waarover hij beschikt naar de Streamer–module

die instaat voor het uitzenden van de live–uitzending. Indien de Streamer–module werd

gevonden, probeert de server bij de IP2DVBScheduler een kanaal te reserveren. In-

dien de reservatie succesvol is verlopen, ontvangt de server configuratieparameters. De


IP2DVBScheduler licht de IP2DVBGateway in dat de MPEG–2 SPTS, die ontvangen zal

worden, in de broadcast moet worden opgenomen.

4. De server contacteert de bewuste Streamer–module, die verantwoordelijk is voor de live–

uitzending en geeft de parameters om de MPEG–2 SPTS te vormen door.

5. De Streamer–module stelt de configuratieparameters in, begint de opname en zendt de

MPEG–2 SPTS naar de IP2DVBGateway.

6. De server beantwoordt het verzoek van de MHP–applicatie met de DVB locator van het

kanaal waarop de uitzending geplaatst werd. De MHP–applicatie laat vervolgens de STB

afstemmen op het kanaal.

4.2 Videoconferencing

4.2.1 Architectuur Exploratie

Voor videoconferencing zijn verschillende architecturen mogelijk. Een eerste type is de peer–

to–peer–architectuur (P2P)6. Skype7 is een populair programma voor VoIP dat gebruik maakt

van P2P–technologie [2]. Er zijn al verschillende uitbreidingen voor Skype beschikbaar zoals

Video4Skype8 en Festoon9 waarmee videoconferenties kunnen worden opgezet. Videoconferen-

cing kan ook gerealiseerd worden aan de hand van een publish–subscribe–systeem waarbij een

gebruiker de conferentie publiceert als onderwerp en pakketten met audio of video beschouwd

worden als gebeurtenissen waarvoor andere gebruikers zich kunnen inschrijven [20]. Een derge-

lijk systeem dat gebruik maakt van het Narada Event Brokering System10 wordt beschreven in

[21].

Omdat de STB niet rechtstreeks een videostroom kan ontvangen zal de architectuur geen gebruik

kunnen maken van het P2P–principe. De ontworpen architectuur is gebaseerd op de architectuur

voor VoIP. De gebruiker zal zich moeten kunnen registreren en een andere gebruiker uitnodigen

voor een videoconferentie. Er is dus signalering nodig voor het opzetten van een videoconferen-

tie. Bij VoIP wordt voor signalisatie het Session Initiation Protocol (SIP) [35] in combinatie6In een peer–to–peer–architectuur kan elke component rechtstreeks met elke andere component communiceren.7http://www.skype.com8http://www.dialcom.com9http://www.festooninc.com

10http://www.naradabrokering.org


met het Session Description Protocol (SDP) [23] gebruikt [9]. Het SIP wordt ook gebruikt in de

kern van de derde generatie mobiele netwerken [9]. Zo is het niet ondenkbaar dat in de nabije

toekomst een videoconferentie tussen een mobiele telefoon en een televisie tot stand zal kunnen

worden gebracht. SIP kan overigens ook gebruikt worden bij P2P–technologie [36].

4.2.2 Session Description Protocol (SDP)

SDP [23] wordt gebruikt om de parameters van een sessie in te stellen. De partijen waartussen

een sessie opgezet zal worden, kunnen zo informatie uitwisselen over de mogelijkheden van hun

SIP–stations11. Er zijn verschillende categorieen parameters die elk aangeduid worden met een

letter. Onderstaand voorbeeld illustreert de sessieparameters bij VoIP.

c = IN IPv4 157.193.215.98

b = 8

m = audio 4321 RTP/AVP 18

De informatie over de verbinding wordt weergegeven met c. Er wordt informatie verschaft over

het type netwerk, het adresformaat en het IP–adres van het station. De letter b duidt de vereiste

bandbreedte aan. De laatste regel, aangeduid met m, geeft het type media aan, het poortnummer

waarop media ontvangen kan worden, het transportprotocol en tenslotte een aanduiding voor

het formaat. Het station van de ene gebruiker kan bijvoorbeeld drie formaten aanduiden in zijn

SDP–bericht en het station van de andere gebruiker kan dan antwoorden met een SDP–bericht

dat het gekozen formaat vermeldt. Met SDP kunnen op deze manier de mogelijkheden van de

stations worden aangegeven en kan er als het ware onderhandeld worden over de sessieparame-

ters. SDP zal in de architectuur gebruikt worden om parameters voor de Capture–module in het

thuisnetwerk, die een MPEG–2 SPTS zal versturen, te transporteren. Net zoals in de architec-

tuur voor live event broadcasting moet de MPEG–2 SPTS, die naar de IP2DVBGateway wordt

gezonden, voldoen aan de voorwaarden opgelegd door de IP2DVBScheduler. De parameters

kunnen eenvoudig opgenomen worden in een SDP–bericht.11Een SIP–station of SIP–terminal wordt gedefinieerd als een entiteit die communicatie ondersteund, in twee

richtingen en in ware tijd, met een andere SIP–entiteit. Het station ondersteunt signalisatie en uitwisseling van

media. Een voorbeeld van een SIP–terminal is een SIP–telefoon.


4.2.3 Session Initiation Protocol (SIP)

Om een sessie, zoals een gesprek bij VoIP, te beheren wordt SIP [35] gebruikt. Dit protocol

laat toe een sessie op te zetten, te wijzigen tijdens het verloop of te beeindigen. Daarvoor

worden verzoek–en antwoordberichten gebruikt zoals; REGISTER, INVITE, BYE, OK, ... Het

formaat van de SIP–berichten is analoog aan dat van HTTP [9]. SIP kan voor het transport van

berichten verschillende transportprotocollen gebruiken zoals TCP, UDP of TLS over TCP. De

werking van SIP wordt geıllustreerd aan de hand van een vereenvoudigd voorbeeld, zie figuur 4.3.

Twee gebruikers, A en B willen een gesprek opzetten. Beide hebben zichzelf geregistreerd bij de

Figuur 4.3: SIP–scenario.

SIP–server aan de hand van een REGISTER–bericht. Het REGISTER–bericht bevat de locatie

van de gebruiker die gespecificeerd wordt als het IP–adres van het station waarop de gebruiker

te contacteren is. De SIP–server houdt deze informatie bij in een zogenaamde location service

database12. Als gebruiker A een gesprek wil opzetten met een gebruiker B dan zal A daarvoor

een INVITE–bericht zenden naar de SIP–server. Het bericht geeft aan dat gebruiker B gecon-

tacteerd moet worden en bevat ook de SDP–informatie van gebruiker A. De SIP–server gebruikt

de location service database om het IP–adres van het station van gebruiker B op te zoeken.

Het INVITE–bericht zal vervolgens naar het station van B gezonden. Gebruiker B kan dan

kiezen om in te gaan op de uitnodiging of niet. Indien gebruiker B de uitnodiging aanvaardt,12De location service database is als het ware een telefoonboek. Het houdt voor elke gebruiker de locatie, aan

de hand van een IP–adres bij, waarop de gebruiker gecontacteerd kan worden. Dit telefoonboek kan echter wel

dynamisch gewijzigd worden doordat SIP mobiliteit ondersteunt [35].


wordt geantwoord met een OK–bericht dat de SDP–informatie van B bevat. Op deze manier

kan eenvoudig een sessie opgezet worden. Het bovenstaand voorbeeld is sterk vereenvoudigd en

voor een gedetailleerde beschrijving van SIP wordt verwezen naar [35].

SIP kan met een wijziging worden gebruikt in de architectuur. De SDP–informatie moet door de

SIP–server worden bijgevoegd omdat dit informatie betreft over de gereserveerde kanalen en de

reservatie van kanalen de verantwoordelijkheid is van de SIP–server. Dit hangt nauw samen met

de voorwaarde dat alle signalisatieberichten langs de SIP–server moeten passeren13 en wordt bij

de werking van de architectuur verduidelijkt.

4.2.4 Ontworpen Architectuur

Figuur 4.4 toont de ontworpen architectuur. Bij elk van de gebruikers is in het thuisnetwerk,

naast de STB, een Capture–module aanwezig op een host. De thuisnetwerken zijn verbonden

met het internet, bijvoorbeeld via een router. In wat volgt, worden de componenten beschreven

en de interactie ertussen geıllustreerd aan de hand van een voorbeeldscenario.

4.2.4.1 Componenten

De MHP–applicatie bestaat uit drie modules; een SIP–module, een netwerkmodule en een GUI–

module. De SIP–module staat in voor het verzenden van SIP–berichten voor registratie of

invitatie en het luisteren naar binnenkomende berichten. Het ontdekken van Capture–modules

op het thuisnetwerk wordt uitgevoerd door de netwerkmodule. Via deze module kan een bepaal-

de Capture–module ook geconfigureerd worden. De netwerkmodule kan een Capture–module

verzoeken om de live–opname te starten of te stoppen. Het Discover Configure Command Proto-

col (DCCP), zoals beschreven in appendix B, kan gebruikt worden voor de communicatie tussen

Capture–module en netwerkmodule. De gebruiker hanteert de MHP–applicatie door middel van

de GUI–module. Zo kan de gebruiker een bepaalde gebruiker uitnodigen voor een videoconferen-

tie en hij kan beslissen om een uitnodiging van een andere gebruiker te accepteren of te weigeren.

De SIP–server is de centrale component in de architectuur. De server verwerkt de registratie–

berichten en slaat de informatie op in de location service database. Indien een invitatiebericht

wordt ontvangen, wordt de videoconferentie voorbereid door het reserveren van een kanaal voor13Dit wordt ingesteld via de regel Record-Route in de SIP–berichten.


Figuur 4.4: Architectuur voor videoconferencing.

elke gebruiker. Invitatie–en bevestigingsberichten worden uitgebreid met SDP–informatie die

gebruikt zal worden door de MHP–applicatie om de Capture–module in te stellen.

De IP2DVBScheduler en IP2DVBGateway hebben dezelfde functionaliteit als in de architectuur

voor live event broadcasting. De IP2DVBScheduler stelt kanalen ter beschikking die gebruikt

kunnen worden voor videoconferenties. Voor elk kanaal dat gereserveerd wordt, worden configu-

ratieparameters meegegeven die de structuur van de MPEG–2 SPTS voorschrijven. Deze infor-

matie zal uiteindelijk door de SIP–server vermeld worden als SDP–informatie in SIP–berichten.

4.2.4.2 Werking

Het volgende scenario toont de werking van de architectuur. Er wordt verondersteld dat de

beide gebruikers zich reeds hebben geregistreerd. De verschillende stappen zijn aangeduid in

figuur 4.4.

1. Gebruiker A wenst gebruiker B uit te nodigen voor een video–conferentie. Na het invoeren

4.3 Schaalbaarheid 48

van de gebruikersnaam van B, stuurt de SIP–module van de MHP–applicatie een invitatie

naar de SIP–server.

2. De SIP–server zoekt de locatie van gebruiker B op. Daarna worden twee kanalen gere-

serveerd bij de IP2DVBScheduler, een voor elke gebruiker. De configuratieparameters

van het tweede kanaal samen met de DVB locator van het eerste kanaal worden aan het

invitatiebericht toegevoegd als SDP–informatie. De uitgebreide invitatie wordt vervol-

gens naar de MHP–applicatie van gebruiker B gezonden. De IP2DVBScheduler brengt de

IP2DVBGateway op de hoogte dat twee MPEG–2 SPTS’s ontvangen zullen worden.

3. De SIP–module zal via de GUI–module gebruiker B op de hoogte brengen van de invitatie.

Indien gebruiker B ingaat op de invitatie worden de configuratieparameters van het invita-

tiebericht gebruikt om de Capture–module te configureren. Daarna zal de MHP–applicatie

afstemmen op het eerste kanaal. De SIP–module zendt tenslotte een bevestiging naar de

SIP–server.

4. Bij ontvangst van de bevestiging van gebruiker B neemt de SIP–server de configuratiepa-

rameters van het eerste kanaal en de DVB locator van het tweede kanaal en voegt die toe

als SDP–informatie aan het bevestigingsbericht. Dit bericht wordt teruggezonden naar de

MHP–applicatie van gebruiker A.

5. De SIP–module ontvangt de bevestiging waardoor de MHP–applicatie van gebruiker A de

Capture–module configureert en tenslotte afstemt op het tweede kanaal.

6. De Capture–modules zenden de live media door naar de IP2DVBGateway waarmee de

videoconferentie tot stand is gebracht.

De signalisatie moet steeds via de SIP–server verlopen. Indien in het bovenstaande voorbeeld

gebruiker B niet wenst in te gaan op de invitatie dan kan, indien de afwijzing langs de SIP–server

wordt teruggezonden, de SIP–server ook de reservatie van de twee kanalen ongedaan maken. Dit

is noodzakelijk voor een efficient gebruik van het reserveringsmechanisme.

4.3 Schaalbaarheid

De boven beschreven architecturen steunen beide op het gebruik van reserveerbare kanalen in

de broadcast. De broadcast heeft echter een beperkte bandbreedte. Daarom wordt de schaal-


baarheid van de voorgestelde architectuur voor videoconferencing besproken voor het specifieke

geval van een HFC–toegangsnetwerk. Figuur 4.5 toont de structuur van een HFC–netwerk.

Figuur 4.5: HFC–toegangsnetwerk.

Een HFC–netwerk bestaat uit een hybride van de transmissiemedia coaxkabel en glasvezel. Vanaf

een optische knoop, of Optical Node Unit (ONU), tot aan de gebruiker thuis is het transmis-

siemedium coaxkabel. Het spectrum is opgedeeld in twee, voor opwaarts en neerwaarts verkeer

zoals in figuur 4.6 wordt weergegeven.

Figuur 4.6: Spectrum coaxkabel.

Het spectrum is langs onder begrensd door interferentie en langs boven door attenuatie. De

frequentieband voor opwaarts verkeer start op 20 MHz en eindigt op 65 MHz. Het spectrum


voor neerwaarts verkeer start op 80.6 MHz en reikt tot 860 MHz [31]. In de laatste band zijn ook

de radio–, televsisie–en datasignalen ondergebracht in kanalen met een bandbreedte van 8 MHz.

De reserveerbare kanalen, bijvoorbeeld voor een videoconferentie of live–uitzending, zullen ook

geplaatst worden in dergelijke 8 MHz–kanalen. Het beschikbare spectrum is duidelijk beperkt

en het is belangrijk na te gaan hoeveel bandbreedte, uitgedrukt in 8 MHz–kanalen, er nodig is

voor videoconferencing met de boven beschreven architectuur. Het deel van het spectrum, dat

nog beschikbaar is na het plaatsen van de gebruikelijke radio–, televisie–en datasignalen, zal

gebruikt kunnen worden om reserveerbare kanalen in onder te brengen. Om de schaalbaarheid

na te gaan moet er gecontroleerd worden of er voldoende bandbreedte beschikbaar is voor het

vereiste aantal reserveerbare kanalen. Dit aantal dient daarvoor eerst bepaald te worden afhan-

kelijk van het aantal gebruikers.

Er kan ingeschat worden hoeveel reserveerbare kanalen ter beschikking moeten zijn om een be-

paald aantal gebruikers te bedienen met een bepaalde dienstkwaliteit. Daarvoor wordt gebruik

gemaakt van de Erlang B–formule die ook in de telefonie wordt aangewend om telefooncentrales

te dimensioneren [8].

P =

Am

m!m∑

n=0

An

n!

Deze formule geeft de kans P weer dat alle m lijnen bezet zijn en een oproep verloren gaat.

De variabele A is de verkeersintensiteit uitgedrukt in erlang14 en is afhankelijk van het aantal

gebruikers. Met de formule kan dus berekend worden hoeveel lijnen er in een telefooncentra-

le beschikbaar moeten zijn om een bepaalde blokkeringskans te bekomen. Hetzelfde principe

kan toegepast worden voor videoconferencing. Voor een bepaalde verkeersintensiteit kan bere-

kend worden wat het benodigde aantal reserveerbare kanalen is om een bepaalde vooropgestelde

blokkeringskans te bekomen. Als de waarde voor m gekend is, kan berekend worden hoeveel 8

MHz–kanalen, aangeduid met de variabele N, deze reserveerbare kanalen zullen innemen. Indien

elk reserveerbaar kanaal een bitsnelheid Br Mbit/s toegewezen krijgt en een 8 MHz–kanaal een

bitsnelheid B Mbit/s heeft, dan kan N berekend worden als volgt.

N =m · Br

B

Het aantal gebruikers per ONU varieert tussen 125 en 2000. Nemen we als voorbeeld een ver-14Een erlang is gedefinieerd als een dimensieloze eenheid voor verkeersintensiteit [32].


keersintensiteit van 24.75 erlang15. Figuur 4.7 geeft het verloop van de blokkeringskans P, als

functie van het aantal kanalen m, voor dit concrete geval. Merk op dat de abscisas start op 25

Figuur 4.7: Kans op een verloren oproep als functie van het aantal lijnen.

omdat het aantal kanalen minstens groter moet zijn dan de verkeersintensiteit [32]. Vanaf 36

kanalen bedraagt de blokkeringskans minder dan 1%. Veronderstellen we verder dat Br gelijk is

aan 1 Mbit/s, dan is er een totale bitsnelheid gelijk aan 36 Mbit/s nodig. Indien een 64–QAM–

modulatieschema wordt toegepast, is de bitsnelheid B ruim gelijk aan 40 Mbit/s. Dit wordt

berekend aan de hand van het modulatieschema en de roll–off –factor van de pulsvorm van het

signaal [31]. N bedraagt dus minder dan een en de voorgestelde oplossing stelt geen problemen

met betrekking tot schaalbaarheid.

Er dienen een vijftal opmerkingen gemaakt te worden bij bovenstaand voorbeeld. Ten eer-

ste is er in het bovenstaande voorbeeld nog geen rekening gehouden met de foutprotectie die

zal toegevoegd worden aan de SPTS en ongeveer 25% overhead bedraagt [34]. Ten tweede is de

bitsnelheid van een 8 MHz–kanaal afhankelijk van de locatie van dat kanaal in het spectrum. De15Deze verkeersintensiteit is gebaseerd op de verkeersintensiteit bij telefonie voor een zelfde aantal gebruikers.

4.4 Verdeeldheid 52

Signal to Noise Ratio (SNR) bepaalt immers het modulatieschema en dus ook de haalbare bit-

snelheid. Verder wordt voor een reserveerbaar kanaal een bitsnelheid van 1 Mbit/s aangenomen

hoewel die waarde ver boven de opwaarste snelheid ligt van de huidige internetconnecties. De

vierde opmerking betreft de duur van een videoconferentie. Deze duur wordt gelijkaardig veron-

dersteld aan die van een telefoongesprek wat niet noodzakelijk zo zal zijn. Tenslotte betreft de

laatste opmerking het gebruik van de Erlang B–formule. Hierbij wordt impliciet verondersteld

dat een gebruiker van wie de aanvraag voor een videoconferentie werd afgewezen niet opnieuw

zal proberen. Indien daar toch moet rekening mee gehouden worden, zal een andere formule

toegepast moeten worden om het benodigde aantal reserveerbare kanalen te bepalen [32].

4.4 Verdeeldheid

Uit figuren 4.2 en 4.4 blijkt duidelijk de verdeelde aard van beide architecturen. Voor de inter-

actie tussen de verschillende componenten wordt gekozen voor Java. Dit omwille van het feit

dat het MHP gebruik maakt van het DVB–J–platform en omwille van de portabiliteit die eigen

is aan Java. Door middel van Java RMI kunnen de componenten in een verdeelde applicatie

eenvoudig met elkaar te laten communiceren. De servers in beide architecturen kunnen een-

voudig geımplementeerd aan de hand van J2EE–technologie. Tot slot dient nog een opmerking

gemaakt te worden. In figuren 4.2 en 4.4 worden de IP2DVBScheduler en IP2DVBGateway

als aparte componenten afgebeeld die uitgevoerd worden op afzonderlijke hosts. Bij de imple-

mentatie zullen beide componenten op dezelfde host worden uitgevoerd. Dit doet echter niets

af aan de relatie tussen beide componenten. De IP2DVBGateway wordt gecontroleerd door de

IP2DVBScheduler en deze relatie komt ook duidelijk naar voor in de implementatie.

In het volgend hoofdstuk wordt de implementatie van de IP2DVBGateway en de kern van

de Streamer–en Capture–modules besproken.

IP2DVBGATEWAY & VLC 53

Hoofdstuk 5

IP2DVBGateway & VLC

In het vorige hoofdstuk werden de componenten geıdentificeerd en de architecturen geschetst.

Beide architecturen hebben de IP2DVBGateway en telkens is er ook een module aanwezig voor

live–opname. Dit hoofdstuk is dan ook gewijd aan de implementatie van de IP2DVBGateway

en het opnemen van live audio en video.

5.1 IP2DVBGateway

5.1.1 Inleiding

De IP2DVBGateway zal een videostroom, die geleverd wordt door UDP over IP, opnemen in

de broadcast. De videostroom wordt, zoals eerder werd beschreven, verondersteld MPEG–2

gecodeerd te zijn en wordt aangeboden als een MPEG–2 SPTS aan de IP2DVBGateway. Voor

het verdere betoog wordt verondersteld dat de IP2DVBGateway op elk moment slechts een

SPTS kan overbrengen van het IP–netwerk naar de broadcast. Het geval van meerdere SPTS’s,

wat multiplexen vereist, komt later aan bod.

5.1.2 Werking IP2DVBGateway

De IP2DVBGateway zal als softwaremodule geımplementeerd en uitgevoerd worden op een host

die voorzien is van een DVB–ASI–kaart. De videostroom kan via de DVB–ASI–kaart bij andere

kanalen in de broadcast gevoegd worden. Voor de testopstelling wordt gebruikt gemaakt van een

DVB–ASI–kaart van DekTec1. De DekTec DTA–140 is een PCI–kaart die vergezeld wordt van

een C++ API, die DTAPI wordt genoemd. De functionaliteit van de IP2DVBGateway wordt1http://www.dektec.com

5.1 IP2DVBGateway 54

in de mate van het mogelijke onafhankelijk gemaakt van het type DVB–ASI–kaart. Toch zal

soms met de specifieke werking van de DVB–ASI kaart rekening gehouden moeten worden.

De functionaliteit van de IP2DVBGateway kan bondig samengevat worden. Een videostroom

wordt, onder de vorm van een MPEG–2 SPTS, ontvangen. Zoals in hoofdstuk 2 werd uitgelegd

bestaat deze SPTS uit TS–pakketten. Deze pakketten zullen via de DVB–ASI–kaart uitgestuurd

worden. Er wordt herbruikbaarheid nagestreefd zodat verschillende transmissiesnelheden wor-

den ondersteund en de vertraging doorheen de component enigszins instelbaar is. De werking

wordt schematisch afgebeeld in figuur 5.1. De werking is gebaseerd op het principe van een

Figuur 5.1: Werking IPDVBGateway.

circulaire buffer. TS–pakketten worden via de netwerkinterface ontvangen, gebufferd in een be-

paald aantal geheugenblokken met instelbare grootte en tenslotte verstuurd naar de FIFO2 van

de DVB–ASI–kaart. Het bufferen gebeurt door een bepaald aantal TS–pakketten te verzamelen

in een geheugenblok en vervolgens dit blok weg te schrijven naar de FIFO van de kaart. Het weg-

schrijven van een dergelijk blok gebeurt telkens door een aparte thread zodat ondertussen verder

TS–pakketten kunnen worden ontvangen. Dit is ook te zien in figuur 5.1. De TS–pakketten wor-

den door de kaart vervolgens gelezen uit de FIFO en via de DVB–ASI–uitgang verzonden. De2Bufferen op de kaart werkt volgens het first in, first out–principe (FIFO).


vertraging doorheen de IP2DVBGateway wordt in hoofdzaak door twee factoren bepaald. De

eerste factor is de grootte van een geheugenblok, uitgedrukt als geheel aantal TS–pakketten, dat

in een schrijfoperatie overgebracht wordt naar de FIFO. De tweede factor is de minimale inhoud

die in de FIFO aanwezig moet zijn voor de eigenlijke transmissie wordt gestart.

5.1.2.1 Grootte Geheugenblok

TS–pakketten worden ontvangen en opgeslagen in een geheugenblok vooraleer het doorsluizen

naar de FIFO plaatsvindt. Gezien het transfereren van informatie naar die FIFO enige tijd

in beslag neemt, spreekt het voor zich dat het niet aangewezen is om telkens een TS–pakket

ontvangen wordt dit direct door te geven naar de FIFO. Elke overdracht van informatie naar

de FIFO houdt immers een niet te verwaarlozen overhead in [7]. Daarom mag de hoeveelheid

informatie per overdracht of het aantal TS–pakketten per overdracht niet te klein uitvallen.

Langs de andere kant betekent een te groot aantal TS–pakketten bufferen per overdracht dat de

vertraging doorheen de IP2DVBGateway toeneemt. Figuur 5.2 toont het principe. Een blok met

Figuur 5.2: Vertraging.

een grootte α bytes wordt, indien de aankomstsnelheid β bytes per seconde bedraagt, opgevuld

in αβ seconden. Om een gewenste vertraging δ te bekomen moet de blokgrootte α voldoen aan:

α = δ · β

De werkelijke vertraging door de IP2DVBGateway is dan echter groter. De transmissiesnelheid

van de DVB–ASI–kaart zal gelijk gekozen worden aan de aankomstsnelheid. Indien de trans-

missiesnelheid lager wordt gekozen zou er zich informatie opstapelen in de IP2DVBGateway.

Een hogere transmissiesnelheid is uitgesloten. Er wordt verondersteld dat het systeem zich in

regime bevindt. Het blok met een grootte α bytes zal dus uit de FIFO verzonden worden met


een snelheid β wat voor een additionele vertraging δ zorgt. Bovendien moet ook de transfertijd

naar de FIFO, δtransfer, van het blok in rekening gebracht worden. We bekomen voor de totale

vertraging doorheen de IP2DVBGateway de volgende waarde.

δtotaal = 2 · δ + δtransfer

Hieruit kan besloten worden dat de vertraging volledig vrij in te stellen is. Dat dit echter niet

het geval is, zal verder blijken.

5.1.2.2 Initiele FIFO–inhoud

De tweede factor die de vertraging bepaalt is de minimale hoeveelheid informatie in de FIFO,

de initial FIFO load, voor de kaart begint aan de transmissie. Enerzijds betekent een grote

minimale FIFO–inhoud dat eens de kaart de transmissie heeft gestart de situatie, waarbij de

FIFO sneller geleegd wordt dan er informatie wordt toegevoegd, zich minder snel kan voordoen.

De situatie waarbij de FIFO van de DVB–ASI–kaart tijdens de transmissie leeg raakt, wordt in

de DTAPI aangeduid als een Transmit FIFO Underflow. Anderzijds neemt naarmate de mini-

male FIFO–inhoud toeneemt ook de vertraging toe. Er wordt immers gewacht tot een grotere

hoeveelheid TS–pakketten aanwezig is in de FIFO vooraleer de transmissie start. De keuze voor

de grootte kan worden afgewogen. Een Transmit FIFO Underflow resulteert bij de ontvanger in

het ontbreken van informatie die nodig is bij het decoderen en presenteren. De STB bijvoorbeeld

krijgt niet snel genoeg de media binnen en er kunnen zich artefacten voordoen in het beeld of

storingen in het geluid. Voor live event broadcasting lijkt het dus aangewezen de vertraging

liever wat groter te kiezen dan een afname in beeld–en geluidskwaliteit te hoeven tolereren. Bij

videoconferencing is de situatie anders. Hier zal levendigheid van de sessie geprefereerd worden

en kan enigszins wat kwaliteit opgeofferd worden voor interactiviteit.

Een tweetal bijkomende opmerkingen dienen gemaakt worden in verband met voorwaarden

opgelegd door de DTAPI. De API dicteert dat de hoeveelheid informatie, uitgedrukt in aantal

bytes, die per schrijfoperatie naar de FIFO wordt overgebracht een veelvoud van vier moet be-

dragen [7]. Er wordt echter steeds gewerkt met geheugenblokken bestaande uit een geheel aantal

TS–pakketten om moeilijkheden met het opdelen van individuele TS–pakketten uit de weg te

gaan. Verder is het ook zo dat TS–pakketten, met of zonder foutprotectie3, altijd een grootte

hebben die een veelvoud van vier is. Deze voorwaarde vormt dus geen beperking. De tweede3Foutprotectie aan de hand van Reed Solomon–codes vergroot de afmeting van een TS–pakket tot 204 bytes.


voorwaarde is dat de totale FIFO–grootte, die instelbaar is, een veelvoud dient te zijn van zes-

tien [7]. De FIFO–grootte zal ingesteld worden afhankelijk van het aantal blokken dat gebruikt

wordt om TS–pakketten te bufferen maar in overeenstemming met bovenstaande voorwaarde.

5.1.3 Implementatie IP2DVBGateway

De DekTec–kaart is aanstuurbaar door middel van de C++ API en de IP2DVBGateway en krijgt

door middel van de DTAPI–bibliotheek toegang tot de DVB–ASI–kaart. De IP2DVBGateway

bestaat uit slechts drie klasses; de main–klasse, de WriteThread–klasse en de DVBCard–klasse.

De IP2DVBGateway heeft bij het opstarten nood aan zes programma–argumenten. Onderstaan-

de lijst verklaart de programma–argumenten bondig.

• TSinUDP : het aantal TS–pakketten in een UDP–pakket

• TSPacketSize: het aantal bytes in een TS–pakket

• TxRate: de in te stellen transmissiesnelheid van de DVB–ASI kaart in bits per seconde

• TxDelay : de gewenste vertraging (de waarde δ uit bovenstaande redenering)

• Port : de poort waarop TS–pakketten ontvangen zullen worden

• ThreadCount : het maximum toegestane aantal simultane WriteThread–objecten

Het argument ThreadCount is ook gelijk aan het aantal geheugenblokken dat gebruikt wordt

voor buffering.

5.1.3.1 Main–klasse

De main–klasse berekent bij het opstarten een aantal parameters vertrekkende van de programma–

argumenten. UDPPacketSize is het aantal bytes aan inhoud van een UDP–pakket.

UDPPacketSize = TSinUDP · TSPacketSize

Daarna wordt de grootte van een geheugenblok, uitgedrukt als aantal UDP–pakketten, berekent

aan de hand van de volgende formule.

NumUDPPackets =TxRate

(UDPPacketSize · 8)· TxDelay

Het aantal bytes dat in een schrijfoperatie naar de FIFO wordt geschreven bedraagt dus:

NumBytesToTransfer = NumUDPPackets · UDPPacketSize


Er wordt een geheugenruimte met een grootte gelijk aan ThreadCount · NumBytesToTransfer

bytes gealloceerd. Deze geheugenruimte vormt de circulaire buffer. De berekende parameters

worden vervolgens gebruikt voor het instellen van de DVBCard–en WriteThread–klasse. Daarna

wordt de socket waarop de TS–pakketten ontvangen zullen worden, geınitialiseerd en tenslotte

wordt de hoofdlus gestart. De uitvoering van de main–klasse wordt schematisch weergegeven

in figuur 5.3. De geheugenblokken worden op een cyclische manier overlopen en opgevuld met

Figuur 5.3: Hoofdlus.

TS–pakketten. Telkens een geheugenblok beschikbaar is, wordt het opgevuld met ontvangen

TS–pakketten. Daarna wordt een WriteThread–object, die de verdere afhandeling voor zijn

rekening zal nemen, aangemaakt en gestart. De beschikbaarheid van een geheugenblok hangt

af van het feit of het WriteThread–object de voorafgaande TS–pakketten in het geheugenblok

al heeft overgebracht naar de FIFO. Indien de overdracht nog niet heeft plaatsgevonden, wacht

de hoofdlus tot die operatie is beeindigd.

5.1.3.2 WriteThread–klasse

Voor elk geheugenblok dat opgevuld is met TS–pakketten wordt een nieuw WriteThread–object

opgestart. Het object zal het schrijven van het betreffende geheugenblok naar de FIFO uitvoe-


ren. De WriteThread–klasse beschikt daartoe over een DVBCard–object zoals verder beschreven

wordt. Er kunnen simultaan verschillende WriteThread–instanties opgestart zijn, maar elk ob-

ject wacht tot het vorig object zijn schrijfoperatie heeft uitgevoerd.

5.1.3.3 DVBCard–klasse

De DVBCard–klasse verbergt het aansturen van de DVB–ASI kaart. Voor het instellen van

de DVB–ASI–kaart voorziet de DVBCard–klasse twee initialisatiemethodes. Een aantal van de

instellingen worden hieronder opgesomd.

• ClockGenMode: de klok generator mode

• TxPacketMode: de grootte van de TS–pakketten die behandeld zullen worden, er is onder

andere keuze tussen groottes 188 en 204 bytes

• TxStuffMode: geeft aan of er nulpakketten of K28.5–synchronisatiekarakters moeten wor-

den ingevoegd indien een Transmit FIFO Underflow optreedt

• TsRate: transmissiesnelheid van de DVB–ASI–kaart in bit per seconde

• FifoSize: de totale grootte van de FIFO op de kaart, deze grootte bepaalt ondermeer de

vertraging om data naar de kaart over te brengen (δtransfer in bovenstaande redenering)

De initiele FIFO–inhoud wordt gelijk gekozen aan de waarde van de variabele NumBytesTo-

Transfer. Na de eerste schrijfoperatie wordt de transmissie dus al gestart. Verder wordt ook de

grootte van de totale FIFO–grootte ingesteld, rekening houdende met de eerder vermelde voor-

waarde. De transmissiesnelheid van de DVB–ASI–kaart wordt gelijk genomen aan de waarde van

het programma–argument TxRate dat bij het opstarten wordt gespecificeerd. Nadat de kaart

wordt geconfigureerd, kan via deze klasse informatie naar de FIFO overgebracht worden via de

daartoe voorziene schrijfmethode. Het uitvoeren van een schrijfoperatie neemt drie stappen in

beslag zoals figuur 5.4 weergeeft. Eerst wordt de informatie geplaatst in de FIFO via de schrijf-

methode Write uit de DTAPI. Deze methode geeft informatie over het al dan niet slagen van de

overdracht. Het kan bijvoorbeeld voorkomen dat de hoeveelheid informatie, uitgedrukt in bytes,

geen veelvoud van vier is hoewel dit vereist is. Daarom voorziet de DTAPI in feedback voor elke

schrijfoperatie. Daarna wordt de status van de DVB–ASI–kaart nagegaan door gebruik te maken

van de methode GetFlags van de DTAPI. Met deze methode kan er gecontroleerd worden of er

een Transmit FIFO Underflow is opgetreden of indien er bij transmissie een synchronisatiefout


Figuur 5.4: Schrijfoperatie DVBCard–klasse.

is voorgekomen. In de derde stap wordt de inhoud van de FIFO opgevraagd zodat in de vierde

stap de transmissie gestart kan worden als er in de FIFO genoeg informatie aanwezig is.

5.1.4 Aanspreken vanuit Java

De IP2DVBGateway is geımplementeerd in C++ maar zal door de IP2DVBScheduler gecon-

troleerd worden. De IP2DVBScheduler zal echter geschreven worden in Java en daarom is het

nodig om de IP2DVBGateway te kunnen aanspreken vanuit Java.

5.1.4.1 IP2DVBGatewayInterface

Voor toegang vanuit Java is de volgende interface voorzien.

public interface IP2DVBGatewayInterface {

public void setTSinUDP(int i);

public void setTSPacketSize(int i);

public void setTxRate(int i);


public void setTxDelay(float f);

public void setPort(int i);

public void setThreadCount(int i);

public void destroy();

}

De interface is eenvoudig en beperkt zich tot het instellen van de eerder vermelde programma–

argumenten voor de IP2DVBGateway. De methode destroy sluit de IP2DVBGateway af. Langs

deze interface kan de IP2DVBScheduler controle uitoefenen op de IP2DVBGateway.

5.1.4.2 IP2DVBGatewayThread

Het oproepen van de IP2DVBGateway wordt behandeld door de IP2DVBGatewayThread–klasse

die de bovenstaande interface implementeert. De klasse zal de IP2DVBGateway opstarten en

controleren. Hiervoor wordt de klasse Runtime gebruikt die laat toe om door middel van een

commandolijn een programma op te starten vanuit Java. Het gebruik van de Runtime–klasse is

echter niet zo evident. Nemen we onderstaand voorbeeld.

Runtime rt = Runtime.getRuntime();

Process p = rt.exec(”MyProg.exe”);

De methode getRuntime() geeft een referentie naar de huidige Java Runtime Environment te-

rug. De exec–methode creeert vervolgens een proces, het programma MyProg.exe dat uitgevoerd

wordt, waarnaar een referentie teruggeven wordt aan de JVM. Er is echter meer aan de hand dan

op het eerste zicht lijkt. Het opstarten van een programma op deze manier kan ervoor zorgen

dat het opgestart programma, en mogelijk ook het Java–programma van waaruit de oproep werd

gemaakt, blokkeert. De oorzaak hiervan ligt bij de in–en uitvoer van het proces. Het opgestarte

programma kan namelijk zelf uitvoer genereren of invoer nodig hebben om verder te kunnen uit-

voeren. Het besturingssysteem voorziet echter slechts een beperkte buffer voor de in–en uitvoer

en daarom is het nodig deze vanuit het oproepende Java–programma te verwerken. Er zijn twee

klasses voorzien, ProcessInputStream en ProcessOutputStream, die deze taak vervullen. Via de

ProcessInputStream–klasse kan informatie aan het opgestarte programma worden doorgegeven

en de ProcessOutputStream–klasse ontvangt de uitvoer van het programma telkens die wordt

gegenereerd. Bij de ProcessOutputStream–klasse is er bovendien de keuze om de output van

het opgeroepen programma naar het Java–programma te sturen of weg te schrijven naar een

bestand.


5.1.5 Extensies

De boven beschreven IP2DVBGateway kan een videostroom, geleverd als SPTS, in de broad-

cast opnemen. Het principe kan echter uitgebreid worden zodat simultaan meerdere SPTS’s

gemultiplexed worden door de IP2DVBGateway en in de broadcast geplaatst worden. Voor het

uitvoeren van multiplexing zijn verschillende alternatieven mogelijk.

ISO 13818 Stream Multiplexer4 is een open-bron multiplexer waarmee in ware tijd verschillende

MPEG–2 multiplex types gecombineerd kunnen worden tot een geheel. Terwijl het multiplexen

wordt uitgevoerd, kan er kanaalinformatie worden gewijzigd en kan de PAT worden aangepast.

Recent is er voorziening toegevoegd waarmee ook DVB SI–informatie kan worden opgenomen.

De Java Stream Assembly API (JAS) [39] is een Java API waarmee in ware tijd mediastromen

bewerkt en gemultiplexed kunnen worden. De MPEG–2 multiplex types, PS en TS, worden on-

dersteund en er zijn in de API talrijke klasses voor het behandelen van dergelijke multiplexen.

JAS voorziet ook fysieke interfaces zoals een DVB–ASI–link of een Ethernet interface. Beide

alternatieven werden echter niet geschikt bevonden om toepassing te vinden.

Gezien de IP2DVBScheduler de structuur van de te ontvangen MPEG–2 SPTS’s op voorhand

bepaalt, kan volgens een eenvoudig principe multiplexing worden toegepast. Figuur 5.5 toont

hoe de structuur van twee SPTS’s en de gewenste structuur na het multiplexen van beide tot

een MPEG–2 MPTS. De structuur van de SPTS’s wordt schematische voorgesteld. Voor de

Figuur 5.5: Multiplex operatie.

binnenkomende SPTS’s worden de TS–pakketten met PID–waarde nul verwijderd. Dit zijn de4http://www.scara.com/ schirmer/o/mplex13818

5.2 VLC 63

TS–pakketten die de PAT–informatie bevatten. De informatie over de gereserveerde kanalen

wordt bijgehouden door de IP2DVBScheduler. Er wordt een nieuwe PAT aangemaakt op ba-

sis van de gereserveerde kanalen en deze wordt toegevoegd. Het resultaat is de MPTS die in

figuur 5.5 te zien is. Dit principe kan natuurlijk voor meer dan twee SPTS’s worden toege-

past. In de main–klasse van de IP2DVBGateway, zie 5.1.3.1, kunnen op verschillende poorten

TS–pakketten ontvangen en aan de filtering onderworpen worden. Om de bitsnelheden van de

SPTS’s te respecteren kan bijvoorbeeld een Weighted Fair Queuing–principe (WFQ) [9] toege-

past worden zoals in figuur 5.6 wordt afgebeeld. Afhankelijk van de bitsnelheid van elke SPTS

Figuur 5.6: Multiplex operatie met Weighted Fair Queueing (WFQ).

wordt een gewicht toegekend aan elke poort. Dit gewicht bepaalt hoe vaak op de poort een TS–

pakket zal worden ontvangen en verwerkt. Er zal wel moeten worden op toegezien dat er vaak

genoeg TS–pakketten met MPEG–2 PSI–informatie TS–pakketten met DVB SI–informatie wor-

den toegevoegd om een geldige MPTS te bekomen. Bovendien zal ook de timinginformatie van

elke SPTS, de PCR–waarden, moeten worden aangepast. Het beschreven multiplexingprincipe

is nog niet aanwezig in de huidige implementatie van de IP2DVBGateway.

5.2 VLC

5.2.1 Inleiding

Het intelligent randapparaat, de Capture–module, zal in de videoconferencing–architectuur in-

staan voor het live opnemen en verzenden naar de IP2DVBGateway. De Streamer–module zal in

5.2 VLC 64

de architectuur voor live event broadcasting een gelijkaardige functie vervullen. De videostroom

zal echter MPEG–2 gecodeerd moeten zijn en verzonden worden als MPEG–2 SPTS. Bovendien

zal de structuur van de SPTS voorgeschreven worden door de IP2DVBScheduler. De opname

en het verzenden zijn dus onderworpen aan voorwaarden. De twee modules zullen voor het

eigenlijke opnemen, transcoderen en verzenden beroep doen op bestaande software.

Voor het opnemen van audio en video, bijvoorbeeld aan de hand van een webcam en micro-

foon, blijken verschillende mogelijkheden voor handen te zijn. JMF, zoals in het vorige hoofd-

stuk beschreven, komt hiervoor in aanmerking maar heeft een grote beperking wat betreft de

ondersteunde formaten en codecs. Er zijn weliswaar uitbreidingen voor JMF te vinden zoals

plug–ins Fobs4JMF5 en JFFMPEG6 maar deze uitbreidingen laten alleen toe dat er meer for-

maten kunnen worden afgespeeld. Opnemen en transcoderen naar MPEG–2–formaat behoort

niet tot de mogelijkheden van JMF. VideoLAN Client (VLC)7 is een open–bron mediaspeler die

talrijke formaten ondersteund. Met VLC kan opgenomen worden en MPEG–2 codering worden

uitgevoerd. Bovendien heeft VLC de mogelijkheid om de structuur van de SPTS in te stellen.

VLC biedt dus de functionaliteit die vereist is.

5.2.2 VLC Commandolijn

Om VLC te gebruiken voor opname, transcodering en streaming, is het nodig talrijke parameters

te kunnen instellen. Instellingen kunnen via de commandolijn worden opgegeven. De comman-

dolijn van VLC is behoorlijk uitgebreid en daarom wordt er dan ook eerst even ingegaan op

de structuur ervan aan de hand van twee voorbeelden. De voorbeelden illustreren slechts een

heel beperkt aantal opties. Een volledige beschrijving van alle opties word bekomen door het

commando ”vlc.exe –longhelp –advanced“.

5.2.2.1 Bestand Stromen

Onderstaande voorbeeld geeft commandolijn die gebruikt wordt om een bestand te stromen als

SPTS naar een bepaalde host.

vlc.exe file.avi - -sout=#transcode{vcodec=mp2v,vb=1024,fps=25.0,

height=272,width=640,venc=ffmpeg{bframes=0,keyint=20,strict-rc=1,vt=0},5http://fobs.sourceforge.net6http://jffmpeg.sourceforge.net7http://www.videolan.org

5.2 VLC 65

acodec=mp2a,ab=192,channels=2,samplerate=44100}:std{access=udp,

mux=ts{tsid=1234,program-pmt=1,pid-pmt=40,pid-video=66,pid-audio=67,}

,url=192.168.30.2:2500} - -loop

De bovenstaande commandolijn stroomt het bestand ”file.avi”, na transcoderen naar MPEG–

2–formaat, als een SPTS. Daarvoor worden de transcode–module en de std–module gebruikt.

De eerste module, transcode, wordt aangewend voor het transcoderen van het videobestand en

de tweede module, std, voor het stromen. De transcode–module heeft heel wat parameters die

ingesteld kunnen worden. De onderstaande lijst geeft kort uitleg over de schillende opties met

betrekking tot het transcoderen.

• vcodec: het gewenste video formaat

• vb: de gewenste bitsnelheid voor de video

• fps: de beeldsnelheid voor de video

• height : de hoogte van de video

• width: de breedte van de video

• venc: de video–encoder

• acodec: het gewenste audio formaat

• ab: de gewenste bitsnelheid voor de audio

• channels: het aantal audiokanalen (mono, stereo of dolby surround)

• samplerate: de bemonsteringsfrequentie voor de audio

Voor een aantal van de bovenvermelde opties zoals vcodec en acodec ligt de keuze voor de

hand. De optie samplerate moet gekozen worden overeenkomstig het audioformaat. Zo is voor

MPEG–2–audio een bemonsteringsfrequentie van 44.1 kHz toegelaten. Andere opties moeten

echter specifiek gekozen worden rekening houdende met het feit dat de videostroom uiteindelijk

in de broadcast zal opgenomen worden. Zoals in hoofdstuk 2 werd vermeld, gebruikt de DVB–

standaard het MPEG–2 Main Profile in combinatie met het Main Level. De videoresolutie en

beeldsnelheid kunnen dus zeker niet vrij gekozen worden. De video–encoder die gespecifieerd

wordt in het voorbeeld is FFMPEG8. FFMPEG wordt in VLC gebruikt als plug–in, maar is8http://ffmpeg.sourceforge.net

5.2 VLC 66

op zich eigenlijk een conversieprogramma ontwikkeld voor Linux. Er kunnen heel wat opties

ingesteld worden voor FFMPEG. De optie bframes bepaalt het aantal MPEG–2 B–frames,

keyint het aantal beelden tussen twee opeenvolgende MPEG–2 I–frames, strict-rc legt vast of er

strikte controle op de informatie–uitvoer wordt toegepast en vt staat voor de videotolerantie in

bits per seconde. Bij de std–module worden drie opties ingesteld.

• access: bepaald of de media stream opgeslagen wordt of verzonden (file, udp, http, ...)

• mux : de gebruikte encapsulatie voor de stream (ts, ps, ...)

• url : de locatie waar de stroom wordt opgeslagen of naartoe wordt verzonden

De access–optie wordt ingesteld op udp, zodat de getranscodeerde stroom verzonden wordt

door middel van transportprotocol UDP. De gekozen mux–optie is ts, zodat de getranscodeerde

media als SPTS wordt verzonden. Zoals in het voorbeeld is te zien, worden voor de SPTS opties

ingesteld. De ID–waarden voor de transport stroom en kanaal worden opgegeven door de opties

tsid en program–pmt. Voor het specificeren van de PID–waarden voor PMT, audio en video

worden respectievelijk de opties pid-pmt, pid-audio en pid-video gebruikt. Tenslotte geeft de

algemene loop–optie aan dat het stromen van het bestand herhaald moet worden.

5.2.2.2 Camera & Microfoon Stromen

De structuur van de commandolijn om audio en video opnames te stromen naar een host, is

gelijkaardig met het bovenstaand voorbeeld. Om een randapparaat zoals een USB–webcam of

microfoon aan te spreken wordt er gewerkt met DirectShow.

vlc.exe - -dshow:// - -vdev=“Logitech QuickCam Chat”

- -adev=“Conexant AMC Audio” size=“176x144”

- -sout=#transcode{vcodec=mp2v,vb=1024,fps=25.0,height=272,width=640,

venc=ffmpeg{bframes=0,keyint=20,strict-rc=1,vt=0},

acodec=mp2a,ab=192,channels=2,samplerate=44100}

:std{access=udp,mux=ts{tsid=1234,program-pmt=1,pid-pmt=40,

pid-video=66,pid-audio=67},url=192.168.30.2:2500}

DirectShow is een door Microsoft ontwikkelde API waarmee operaties op media kunnen uitge-

voerd worden. VLC laat het stromen van een webcam en microfoon toe door gebruik te maken

van DirectShow. De drie opties in verband met DirectShow worden hieronder opgesomd.

5.2 VLC 67

• vdev : het apparaat om beeld op te nemen (gespecifieerd aan de hand van de naam onder

DirectShow)

• adev : het apparaat om geluid op te nemen (gespecifieerd aan de hand van de naam onder

DirectShow)

• size: de resolutie voor de beeldopname

De andere modules zijn dezelfde als in het eerste voorbeeld.

5.2.3 Aanspreken vanuit Java

VLC zal instaan voor het opnemen, transcoderen en uitzenden en zal gecontroleerd worden

door de Capture–en Streamer–module. Deze modules zullen, net als de IP2DVBScheduler, in

Java geımplementeerd worden en daarom zal VLC aangesproken moeten worden vanuit Java.

Daarom wordt dezelfde structuur gevolgd als bij de IP2DVBGateway.

5.2.3.1 VLCInterface

Onderstaande interface geeft de methodes waarmee controle kan uitgeoefend worden op VLC.

public interface VLCInterface {

public void openFile(String fileName);

public void openURL(String url);

public void openNetworkStream(int port);

public void openDirectShow(String vdevice, String videoSize, String adevice);

public void setOutput(String access, String multiplex, String ip, int port);

public void setTSMuxSettings(int transportstreamID, int serviceID, ...);

public void setTranscoding(String videoCodec, int videoBitrate, ...);

public void setFFMPEGSettings(int bFrameRatio, int keyInterval, ...);

public void setLoop();

public void destroy();

}

De eerste vier methodes kunnen worden gebruikt om respectievelijk een bestand te openen, een

URL te openen, te luisteren op een poort naar een binnenkomende stroom en om gebruik te

maken van randapparatuur. Het grootste deel van de interface bestaat uit methodes om de

5.2 VLC 68

eerder vermelde opties in te stellen. De structuur van de SPTS in termen van ID–waarden en

PID–waarden, wordt ingesteld met de methode setTSMuxSettings. De setTranscoding–methode

laat toe om de verschillende opties voor het transcoderen in te stellen. Tenslotte kan de video–

encoder FFMPEG geconfigureerd worden met de setFFMPEGSettings–methode. De optie loop

kan enkel ingesteld worden als er een bestand gestroomd wordt.

5.2.3.2 VLCThread

Voor het oproepen van VLC vanuit java wordt de VLCThread–klasse aangewend. Deze klasse

implementeert bovenstaande interface en gebruikt de Runtime–klasse. Dezelfde opmerkingen als

bij de IP2DVBGatewayThread–klasse gelden hier. Het is noodzakelijk dat de in–en uitvoer van

VLC worden verwerkt. Daartoe worden de ProcessInputStream–en de ProcessOutputStream–

klasse, waarvan eerder sprake, gebruikt.

5.2.4 Extensies

Uit de eerder gegeven voorbeelden bleek al het kleine verschil tussen de commandolijn voor het

stromen van een bestand en het stromen van live opnames. Video on Demand (VOD) wordt dan

ook als extensie toegevoegd aan de architectuur voor live event broadcasting. Deze uitbreiding

vereist de introductie van een nieuw aspect van VLC: de remote control interface–module. De

commandolijn voor het opstarten van VLC wordt uitgebreid met de volgende regel:

-I rc –rc-quiet –rc-host “:port”

Voor de rc–module worden twee opties ingesteld:

• quiet : de remote controle interface wordt verborgen en wordt onzichtbaar uitgevoerd in

de achtergrond

• host : specifieert de host en poort waarop commando’s ontvangen kunnen worden

Door de bovenstaande uitbreiding luistert VLC op de gespecificeerde poort naar commando’s

waardoor een aantal nieuwigheden beschikbaar worden die vereist zijn voor VOD. Zo kan onder

meer het afspelen gepauzeerd, gestopt en herstart worden. De VLCInterface–interface wordt

uitgebreid met de volgende methodes: vlcPlay, vlcPause, vlcStop, vlcFastForward en vlcRe-

wind. Slechts het pauzeren, stoppen en herstarten werden geımplementeerd omdat tijdens het

transcoderen, vooruitspoelen en terugspoelen geen effect hebben. De Streamer–modules in de

5.3 Performantie 69

architectuur voor live event broadcasting zullen hierdoor ook videobestanden zoals films of mu-

ziekvideo’s beschikbaar kunnen stellen voor de gebruiker. VOD wordt hier niet gerealiseerd

met enkele videoservers maar aan de hand van een willekeurig aantal Streamer–modules. Bo-

vendien kunnen deze modules eenvoudig aan het systeem worden toegevoegd of eruit worden

weggenomen wat resulteert in een dynamisch wijzigbare verzameling van videobestanden. De

bestanden, die een Streamer–module aanbiedt, worden net zoals live–uitzendingen aangeduid

met een Vodcast locator. De bestanden hoeven overigens niet lokaal beschikbaar te zijn omdat

VLC media kan ophalen van bijvoorbeeld een internetlocatie en in ware tijd terug kan uitsturen

als MPEG–2 SPTS. Dit opent een waaier aan mogelijkheden omdat ook videobestanden van op

het internet kunnen worden afgespeeld op de televisie. Een belangrijk aspect bij het stromen

van internetvideo is echter de vertraging en de gevolgen die deze vertraging kan hebben op het

transcoderen.

5.3 Performantie

In het bovenstaande werden de twee componenten geschetst waarmee een live videostroom

kan worden geleverd, VLC, en in de broadcast kan worden opgenomen, IP2DVBGateway.

In deze paragraaf wordt de performantie besproken. Figuur 5.7 toont de combinatie van de

IP2DVBGateway en VLC. In het bovenstaande werd impliciet ondersteld dat de MPEG–2 SPTS,

Figuur 5.7: VLC en IP2DVBGateway.

die de aangevraagde media bevat, geleverd wordt aan de IP2DVBGateway aan een constante

snelheid of Constant Bit Rate (CBR). Dit is echter geen realistische veronderstelling.

5.3 Performantie 70

5.3.1 Netwerk

Het IP–netwerk waarover de MPEG–2 SPTS wordt gezonden, biedt een Best Effort–dienst. Dit

betekent dat er geen garanties zijn met betrekking tot de beschikbare bandbreedte of vertraging.

TS–pakketten worden ook niet met zekerheid afgeleverd en het is mogelijk dat eenzelfde pak-

ket meermaals ontvangen wordt. Dit stelt heel wat problemen voor het transport van een SPTS.

De vertraging die de SPTS ondervindt, is afhankelijk van ander verkeer op het netwerk en

van de gevolgde route tussen bron en bestemming. TS–pakketten kunnen tijdelijk een grotere

vertragingstijd ondervinden waardoor bij de IP2DVBGateway minder TS–pakketten ontvangen

worden. Een ogenblik later kan er dan plots een grotere hoeveelheid pakketten aankomen in een

zogenaamde burst. Bij een burst kan er verlies van TS–pakketten optreden. De vertragingstijden

van TS–pakketten kunnen bovendien onderling verschillen, wat aanleiding geeft tot jitter. De

pakketten komen dan mogelijk uit volgorde aan bij de IP2DVBGateway. De volgorde van de

TS–pakketten met dezelfde PID–waarde is af te leiden uit een vier bit veld in de header van het

TS–pakket, de continuity counter. Bij opeenvolgende TS–pakketten met dezelfde PID–waarde

wordt deze teller met een verhoogd modulo zestien. Als TS–pakketten in een andere volgorde

worden ontvangen en uitgestuurd via de DVB–ASI–kaart zal dit gedetecteerd worden door de

MPEG–decoder en zal het afspelen verstoord worden. Ook het timingmodel, zie 2.2.2, is gevoe-

lig voor jitter. TS–pakketten die de PCR–tijdsstempels bevatten, kunnen in de juiste volgorde

aankomen maar een veranderlijke vertraging ondervinden. Dit wordt schematisch weergegeven

in figuur 5.8. Indien een TS–pakket met PCR–waarde te laat aankomt, kan er resynchronisatie

plaatsvinden. Indien de variaties in vertraging te groot zijn, kan de fasevergrendelingslus, die

gebruikt wordt voor synchronisatie van de decoderklok, hier niet voor compenseren waardoor

de synchronisatie verloren kan gaan. De veranderlijke vertraging van de PCR–pakketten wordt

omschreven als PCR–jitter en heeft een grote invloed op het afspelen [22].

5.3.2 VLC

VLC, de bron van de SPTS, blijkt ook geen CBR–stroom maar een VBR–stroom te zenden.

Dit kan eveneens aanleiding geven tot bursts van pakketten maar ook een tijdelijk tekort aan

pakketten waardoor een Transmit FIFO Underflow kan optreden. Er werden verschillende op-

ties van VLC getest maar steeds was de bitsnelheid van de uitgestuurde SPTS variabel. VLC

biedt wel een shaping–optie waarmee tijdens een instelbaar aantal milliseconden de bitsnelheid

5.3 Performantie 71

Figuur 5.8: PCR–jitter.

constant blijft. Tussen dergelijke tijdsintervallen is er dan nog steeds een variabiliteit in bit-

snelheid. Het gebruik van de optie zorgt bovendien voor een additionele vertraging evenredig

met het ingestelde tijdsinterval. VLC introduceert sowieso een niet te verwaarlozen vertraging

tussen opname en uitsturen van de SPTS en omwille van het belang van vertraging wordt de

shaping–optie dan ook niet gebruikt.

5.3.3 Maatregelen

Het spreekt voor zich dat het aanbieden van live event broadcasting en videoconferencing moet

plaatsvinden met voldoende kwaliteit of Quality of Service (QoS). Gebruikers zijn bij het huidige

televisie kijken een bepaalde constante kwaliteit gewoon en nieuwe diensten moeten minstens

een gelijkaardig kwaliteitsniveau halen. De boven beschreven problemen hebben een grote im-

pact op de kwaliteit. Jitter kan er bijvoorbeeld voor zorgen dat een deel van een beeld verkeerd

wordt weergegeven of er storingen zijn in het geluid. PCR–jitter kan leiden tot het wegvallen

van beeld en geluid tot synchronisatie opnieuw is bereikt. Het is daarom belangrijk na te gaan

wat hiertegen ondernomen kan worden.

Net zoals bij de architectuur van VoIP kan QoS worden voorzien in het IP–netwerk. De In-

ternet Engineering Task Force (IETF) heeft twee architecturen voorgesteld waarmee QoS kan

worden aangeboden: Integrated Services (IntServ) en Differentiated Services (DiffServ). Een

van beide zou kunnen gebruikt worden om QoS tussen VLC en de IP2DVBGateway te verschaf-

5.3 Performantie 72

fen. Met IntServ kunnen door middel van het Resource Reservation Protocol (RSVP) garanties

worden verstrekt in termen van vertraging en bandbreedte [9].

Indien er geen gebruik wordt gemaakt van IntServ of DiffServ kan er toch te geanticipeerd

op pakketverkeer dat onderhevig is aan bursts. Daartoe kan het aantal geheugenblokken, dat

gebruikt wordt voor buffering in de IP2DVBGateway, worden verhoogd. Een tijdelijk hoge-

re aankomstsnelheid kan opgevangen worden waardoor het verlies van TS–pakketten kleiner

wordt. Bij een daarop volgende lagere aankomstsnelheid kan een Transmit FIFO Underflow ver-

meden worden doordat er nog gebufferde TS–pakketten beschikbaar zijn. De IP2DVBGateway

kan ook worden uitgebreid zodat de volgorde van TS–pakketten hersteld kan worden door het

incorporeren van een dejitter–buffer. PCR–jitter kan behandeld worden door middel van PCR–

restamping, waarbij de PCR–waarden worden aangepast. Voor het VBR–probleem bij VLC zijn

verschillende mogelijke oplossingen. De IP2DVBGateway kan zelf een schatting maken van de

bitsnelheid van de SPTS op basis van het aantal ontvangen pakketten. Indien nodig kan de trans-

missiesnelheid van de DVB–ASI–kaart dan verlaagd of verhoogd worden. Een tweede manier

vereist communicatie tussen de IP2DVBGateway en VLC. Indien VLC, bij het encoderen van

de media tot een SPTS, op regelmatige tijdstippen informatie verschaft over de ogenblikkelijke

bitsnelheid van de SPTS, kan de IP2DVBGateway op basis van deze informatie de transmissie-

snelheid regelen.

Om in de huidige implementatie een zo hoog mogelijke kwaliteit aan te bieden, worden aan

bepaalde opties van VLC specifieke waarden toegekend. De lengte van de GOP, zie hoofdstuk

2, wordt klein gekozen om de invloed van artefacten te verlagen. Indien een grote GOP zou

gebruikt worden, kunnen artefacten in beelden aanleiding geven tot artefacten in daaropvolgen-

de beelden. Dit wordt temporele foutpropagatie genoemd. Door een kleine GOP te gebruiken,

zal deze foutpropagatie beperkt worden. De keyint–optie in VLC wordt daartoe op een waar-

de minder dan tien ingesteld. Verder wordt ook geprobeerd om de invloed van PCR–jitter te

beperken. Hoewel volgens de MPEG–2–standaard het tijdsinterval tussen twee PCR–waarden

slechts kleiner hoeft te zijn dan of gelijk aan 100 ms [25], wordt hier een kleinere waarde geno-

men zodat de MPEG–2–decoder van de STB voldoende snel kan resynchroniseren indien nodig.

Dit wordt ingesteld met de optie pcr van VLC. De invloed van het netwerk en de VBR–stroom

van VLC leiden er ook toe dat de vertraging doorheen de IP2DVBGateway, die ingesteld kan

5.3 Performantie 73

worden met het TxDelay–argument, niet zo klein mogelijk kan worden gekozen. De kleinste

toegelaten waarde, die nog een acceptabele kwaliteit geeft op het televisiescherm, bedraagt on-

geveer 0.25 seconden. De totale vertraging van camera tot televisiescherm ligt dan, bij ideale

netwerkomstandigheden, in de buurt van een seconde en is te hoog voor videoconferencing.

IMPLEMENTATIE LIVE EVENT BROADCASTING ARCHITECTUUR 74

Hoofdstuk 6

Implementatie Live Event

Broadcasting Architectuur

In dit hoofdstuk wordt de implementatie van het netwerkgedeelte van de architectuur voor live

event broadcasting besproken. Dit gedeelte van de architectuur bestaat uit de IP2DVBScheduler,

in combinatie met de IP2DVBGateway, de Streamer–module, die gebruik maakt van VLC, en de

server. De IP2DVBGateway en VLC werden in vorig hoofdstuk behandeld. De extensie uit het

vorige hoofdstuk, waardoor het afspelen van videobestanden mogelijk wordt, is ook opgenomen

in de architectuur. De MHP–applicatie waarmee de gebruiker kan interageren, komt in het

volgende hoofdstuk aan bod.

6.1 IP2DVBScheduler

De IP2DVBScheduler, in combinatie met de IP2DVBGateway, biedt een dynamisch reserve-

ringsmechanisme waarmee kanalen in de broadcast toegekend kunnen worden. Kanalen kun-

nen gereserveerd worden voor een bepaalde duur en worden daarna terug vrijgegeven. De

IP2DVBScheduler maakt deel uit van een verdeelde applicatie en zal het aanspreekpunt zijn om

een reservatie aan te vragen. Bij de beschrijving van de architecturen werd in hoofdstuk 4 de

keuze verantwoord om voor de implementatie gebruik te maken van Java RMI.

De IP2DVBScheduler wordt geımplementeerd als een Java Remote Object. Via Java RMI kan

een dergelijk object aangesproken worden. Elk remote object stelt een interface ter beschikking,

de zogenaamde remote interface, die de methodes bevat die op het object kunnen worden uit-

6.2 Streamer 75

gevoerd. De IP2DVBSchedulerInterface–interface stelt de volgende methodes ter beschikking.

public interface IP2DVBSchedulerInterface extends Remote {

public StreamParam requestService() throws RemoteException;

public boolean releaseService(String dvbLocator) throws RemoteException;

}

De methode requestService probeert een kanaal of service te reserveren en geeft, indien de re-

servatie is gelukt, een StreamParam–object terug. Dit object bevat de configuratieparameters,

waarvan sprake in hoofdstuk 4, en beschrijft de structuur van de MPEG–2 SPTS die naar de

IP2DVBGateway mag worden gezonden. De structuur van de MPEG–2 SPTS wordt bepaald

door de ID–waarden voor de transportstroom en kanaal en de PID–waarden voor de PMT en de

ES’s. Er zijn echter ook nog andere parameters die de bron nodig heeft om de SPTS te vormen:

de toegestane bitsnelheid voor audio en video, de bemonsteringsfrequentie voor de audio, de

resolutie van de video, de beeldsnelheid voor de video, de poort waarnaar de SPTS moet worden

gezonden en het IP–adres van de IP2DVBGateway. Ook deze parameters zijn ondergebracht in

het StreamParam–object. Met de tweede methode in de interface kan een eerder gereserveerd

kanaal worden vrijgegeven. Het is hierbij voldoende om enkel de DVB locator door te geven

als argument. De IP2DVBScheduler houdt namelijk intern de reserveringen bij en weet bij ont-

vangst van de DVB locator welk kanaal moet worden vrijgegeven zodat dit kanaal opnieuw voor

reservatie in aanmerking komt.

De configuratie van elk van de reserveerbare kanalen kan ingesteld worden door middel van

een XML–bestand dat bij het opstarten wordt ingelezen. Voor de kanalen kunnen de talrijke

parameters worden gespecificeerd zoals die hierboven werden beschreven. De IP2DVBScheduler

en IP2DVBGateway worden uitgevoerd op dezelfde host en de IP2DVBGateway wordt ge-

controleerd door de IP2DVBScheduler. Daarvoor gebruikt de IP2DVBScheduler de klasse

IP2DVBGatewayThread zoals in vorig hoofdstuk geıntroduceerd. Figuur 6.1 verduidelijkt de

combinatie van de IP2DVBScheduler en IP2DVBGateway.

6.2 Streamer

Het opnemen, transcoderen en stromen zal, zoals in vorig hoofdstuk beschreven, uitgevoerd wor-

den door VLC. De Streamer–module zal daarvoor VLC aanspreken vanuit Java. De Streamer–

6.2 Streamer 76

Figuur 6.1: IP2DVBScheduler en IP2DVBGateway.

module zelf maakt deel uit van de verdeelde applicatie en zal door de server aangesproken

worden om een live–uitzending te starten of te stoppen. Ook hier wordt gebruik gemaakt van

Java RMI. De Streamer–module wordt, net zoals de IP2DVBScheduler, geımplementeerd als een

Java Remote Object. De remote interface wordt hieronder weergegeven.

public interface StreamerInterface extends Remote {

public boolean startStreaming(StreamParam param, String vodcastLocator)

throws RemoteException;

public boolean play(String vodcastLocator) throws RemoteException;

public boolean pause(String vodcastLocator) throws RemoteException;

public boolean stop(String vodcastLocator) throws RemoteException;

public boolean fastforward(String vodcastLocator) throws RemoteException;

public boolean rewind(String vodcastLocator) throws RemoteException;

public boolean stopStreaming(String vodcastLocator) throws RemoteException;

}

De methode startStreaming neemt onder meer een StreamParam–object, waarvan eerder sprake,

als programma–argument en initieert indien mogelijk de uitzending. De Vodcast locator, waar-

van het principe in het hoofstuk 4 werd geıntroduceerd, duidt een bepaald camerastandpunt

en bijhorend audiokanaal of een videobestand1 aan. De stopStreaming methode beeindigt een

uitzending. Bij het opstarten van de Streamer–module wordt de vodcast feed verschaft die ook

bij de server wordt geplaatst. Dit bestand wordt ingelezen, waaruit de module een verband kan

leggen tussen een Vodcast locator en een bepaalde combinatie van camera en microfoon of video-

bestand. De Streamer–module kan meerdere camerastandpunten en bijhorende audiokanalen of1Voor VOD duidt een Vodcast locator een bepaald videobestand aan.

6.3 Server 77

videobestanden uitzenden. Toch mag de module op elk ogenblik maar een uitzending verzorgen.

Figuur 6.2 toont hoe de Streamer–module is opgebouwd en gebruik maakt van VLC.

Figuur 6.2: Streamer–module en VLC.

6.3 Server

Het server gedeelte voorziet in heel wat functionaliteit, zoals ook in hoofdstuk 4 duidelijk werd.

De implementatie wordt echter eenvoudig verwezenlijkt door gebruik te maken van J2EE–

technologie. De server wordt opgebouwd aan de hand van een Servlet en meerdere Beans.

Figuur 6.3 toont de server in detail. Werken met J2EE-componenten biedt heel wat voor-

Figuur 6.3: Serverimplementatie door middel van J2EE–componenten.

delen. Het zijn verplaatsbare componenten die makkelijk ontplooid kunnen worden op een

6.3 Server 78

J2EE–compatibele server. De levenscyclus van dergelijke J2EE–componenten wordt bovendien

automatisch beheert. In wat, volgt worden de componenten en hun werking beschreven.

6.3.1 LiveEventServlet

Het gedeelte van de server waarmee de MHP–applicatie communiceert, wordt geımplementeerd

als servlet. De MHP–applicatie zal optreden als een web client zoals in figuur 6.3 wordt weergege-

ven. Het aanspreken van de LiveEventServlet voor een specifieke verzoek is eenvoudig. Daarvoor

surft men naar de URL die de locatie van de LiveEventServlet aanduidt en geeft de parame-

ters van het verzoek door in die URL. De parameters worden hierbij als naam–waarde–koppels

gespecificeerd, zoals hieronder wordt geıllustreerd.

http://.../LiveEventServlet?naamA=waardeA&naamB=waardeB

Het voorbeeld geeft aan hoe twee parameters worden doorgegeven. Het scheiden van de pad-

naam en de parameters gebeurt door middel van een vraagteken. Daarna komen de namen en

de waarden van de parameters die gescheiden worden door een ambersant. Telkens een verzoek

wordt ontvangen, controleert de LiveEventServlet of het HTTP–verzoekbericht een zogenaamde

cookie2 bevat en voegt aan het antwoordbericht een cookie toe indien nodig. Dit is nodig om

de verzoeken van verschillende gebruikers te kunnen onderscheiden. De LiveEventServlet staat

in voor vijf taken.

De eerste taak waarvoor de LiveEventServlet instaat, is het genereren van een HTML–pagina

die als overzicht dient en waarin alle beschikbare vodcast feeds worden vermeld. De vodcast

feeds worden gezocht in een folder op de host waarop de LiveEventServlet is ontplooid. De

bestandsnamen van de gevonden bestanden worden vervolgens opgenomen als hyperlinks in de

HTML–pagina. Om de HTML–pagina te laten generen en op te vragen volstaat het te surfen

naar de URL die de locatie van de LiveEventServlet aanduidt. Er dienen dus geen parameters

te worden doorgegeven. Het resultaat van dit verzoek is een HTTP–antwoordbericht waarin

de HTML–pagina is opgenomen als bijlage. In het antwoordbericht wordt echter een speciale

hoofding of zogenaamde headerline opgenomen. De hoofding geeft de recentste vodcast feed aan

die in de folder werd gevonden. Zo kunnen de entiteiten die een dergelijk verzoek plaatsen een

idee krijgen of de HTML–pagina nieuwe elementen bevat. Dit aspect komt ook terug bij het2Cookies worden frequent toegepast op het internet. Het laat een server toe om informatie over internetge-

bruikers bij te houden.

6.3 Server 79

bespreken van de MHP–applicatie in het volgende hoofdstuk.

De tweede taak van de LiveEventServlet is het doorsturen van een specifieke vodcast feed waar-

naar verwezen wordt in de HTML–pagina. Daarvoor wordt slechts een parameter gebruikt met

de naam info. De waarde van de parameter duidt het XML–bestand aan dat gewenst is. De

bijlage in het antwoordbericht zal dan het gevraagde XML–bestand zijn indien dit kon worden

gevonden. Indien het bestand niet werd gevonden, wordt geantwoord met een foutbericht.

De LiveEventServlet kan ook gevraagd worden om een specifieke live–uitzending of een bepaald

videobestand af te spelen. Daarvoor wordt in het verzoek een Vodcast locator doorgegeven. De

ID–waarden waaruit de Vodcast locator is opgebouwd3 worden meegegeven als de waarden van

de parameters met respectievelijke namen channelID, itemID en enclosureID. Het resultaat van

een dergelijk verzoek, indien succesvol uitgevoerd, is een HTTP–bericht dat als bijlage een DVB

locator heeft die het kanaal aanduidt waarop de aangevraagde uitzending te zien is.

De vierde taak is het verschaffen van controle over het afspelen van een videobestand. De

mogelijkheden zijn in de huidige implementatie beperkt tot pauzeren, herstarten en stoppen.

Een dergelijk commando kan doorgegeven worden aan de hand van de parameter met de naam

control. Toegelaten waarden voor deze parameter zijn play, pause, stop, fastforward en rewind.

Merk op dat dit logischerwijze enkel mogelijk is indien de gebruiker een videobestand aan het

bekijken is. Dit verzoek resulteert in een bevestiging van het commando of een foutbericht in-

dien het commando niet toegelaten was.

De vijfde en laatste taak is het behandelen van een verzoek om een uitzending te stoppen. Dit

verzoek wordt aangegeven door middel van de parameter exit die de waarde true krijgt.

Er dienen twee opmerkingen te worden gemaakt. Ten eerste wordt bij het uitvoeren van een

commando, zoals het pauzeren, of het stopzetten van de uitzending geen Vodcast locator mee-

gegeven onder de vorm van parameters. De LiveEventServlet weet voor welke gebruiker het

uitvoeren van het commando of het stopzetten van de uitzending moet gebeuren aan de hand

van de cookie. De component weet echter niet op welke uitzending dit betrekking heeft. Dit

houdt verband met de tweede opmerking dat de LiveEventServlet alle verzoeken, behalve deze

omtrent het genereren van de HTML–pagina en het doorsturen van een vodcast feed, zal door-

geven aan een andere entiteit. Dit brengt ons bij de tweede component, de SchedulerFacadeSB.3Zie hoofdstuk 4 voor het concept Vodcast locator.

6.3 Server 80

6.3.2 SchedulerFacadeSB

Het uitvoeren van de eigenlijke applicatielogica wordt verzorgd door een zogenaamde Session-

Bean (SB). Deze component staat in voor het intelligent uitzenden. Dit houdt onder andere in

dat een bepaalde live–uitzending, of een bepaald camerastandpunt, slechts eenmaal in de broad-

cast terechtkomt. De situatie is echter anders voor het uitzenden van videobestanden waar elke

gebruiker controle heeft over het afspelen en dus telkens een nieuwe uitzending van het bestand

moet worden geregeld. De component zal verzoeken vanwege de LiveEventServlet uitvoeren.

Daarvoor biedt de SchedulerFacadeSB een interface aan met de onderstaande methodes die ge-

bruikt worden door de LiveEventServlet. Bij elk van de methodes wordt een userID meegegeven,

dit is de cookie die door de LiveEventServlet wordt toegekend.

public interface SchedulerFacadeRemoteBusiness {

String startStreaming(String userID, String url,

String vodcastLocator, boolean exclusive)

throws java.rmi.RemoteException;

boolean stopStreaming(String userID) throws java.rmi.RemoteException;

boolean play(String userID) throws java.rmi.RemoteException;

boolean pause(String userID) throws java.rmi.RemoteException;

boolean stop(String userID) throws java.rmi.RemoteException;

boolean fastforward(String userID) throws java.rmi.RemoteException;

boolean rewind(String userID) throws java.rmi.RemoteException;

}

De eerste methode wordt opgeroepen om een bepaalde uitzending te starten. Als de LiveEvent-

Servlet een verzoek ontvangt om een bepaalde uitzending te starten, zal de component informatie

uit de vodcast feed halen en de startStreaming–methode oproepen op de SchedulerFacadeSB.

Zoals de argumentenlijst van de methode laat zien, wordt naast de gebruikersidentificatie en

de Vodcast locator ook een URL en een booleaanse veranderlijke meegegeven. De laatste twee

argumenten worden door de LiveEventServlet opgezocht in de vodcast feed. De URL duidt de

Streamer–module aan die aangesproken moet worden om het uitzenden te starten. Dit is een

RMI–URL4. De booleaanse veranderlijke geeft aan of de uitzending exclusief gebeurt voor de

gebruiker in kwestie of niet. De overige methodes hebben vanzelfsprekende functionaliteit. De4Een dergelijke URL heeft de vorm rmi://host-adres:poort/naam waarbij naam de aanduiding geeft waarmee

het remote object geregistreerd is bij het RMI–register.

6.3 Server 81

onderstaande bespreking verklaart de verschillende stappen van de startStreaming–methode en

schetst de werking van de component.

De SchedulerFacadeSB ontvangt een invocatie van de startStreaming–methode. De component

zal op zoek gaan naar een IP2DVBScheduler die een kanaal kan reserveren. Indien de requestSer-

vice–methode een StreamParam–object oplevert dat niet ledig is, is er een kanaal gereserveerd.

Vervolgens zal de component proberen de Streamer–module te contacteren die verantwoordelijk

is voor de uitzending. De component invoceert de methode van de StreamerInterface–interface

en geeft daarbij de Vodcast locator en het StreamParam–object door. Indien dit alles succesvol

verloopt, zal het resultaat van de invocatie van de methode startStreaming op de Scheduler-

FacadeSB een String–object zijn dat de DVB locator bevat van het kanaal met de aangevraagde

media.

6.3.3 EntityBeans

Om het intelligent uitzenden te realiseren wordt in databasetabellen bijgehouden wat reeds uit-

gezonden wordt en wat elke gebruiker bekijkt. Daarvoor wordt gebruik gemaakt van EntityBeans

(EB). Deze componenten zijn geassocieerd met informatie in de databasetabellen. De informatie

die bijgehouden wordt, is opgedeeld in drie tabellen en voor elke tabel is een EntityBean–klasse

gedefinieerd.

In de eerste tabel wordt informatie over de gebruikers bijgehouden. Voor elke gebruiker wordt

een ID opgenomen en een aanwijzing bijgehouden van de uitzending die de gebruiker aan het

bekijken is. Deze informatie is ondergebracht in de Users–tabel en is toegankelijk via de User-

sEB–component. De tweede tabel bevat informatie over de beschikbare IP2DVBScheduler–

componenten. Voor elke IP2DVBScheduler, die eveneens aangeduid wordt met een ID, wordt

de RMI–URL bijgehouden waarop de component gecontacteerd kan worden. Deze tabel draagt

de naam Schedulers en is te gebruiken via de SchedulersEB–component. De laatste tabel, Media,

bevat de informatie omtrent de uitzendingen die aan de gang zijn. Een regel in deze tabel bevat

zes velden.

• een ID voor de uitzending

• de Vodcast locator van de uitzending

6.3 Server 82

• de DVB locator van het kanaal waarop de uitzending is te zien

• de RMI–URL van de Streamer–module die voor de uitzending verantwoordelijk is

• de ID van de IP2DVBScheduler die het kanaal ter beschikking stelde

• een booleaanse veranderlijke die aangeeft of de uitzending exclusief gebeurt voor een ge-

bruiker of niet

De informatie in de Media–tabel kan opgevraagd en gewijzigd worden door middel van de Me-

diaEB–component. Het eerste veld, het ID van de uitzending, wordt ook gebruikt in de Users–

tabel en het vijfde veld verwijst naar een IP2DVBScheduler in de Schedulers–tabel.

IMPLEMENTATIE MHP–APPLICATIE VOOR LIVE EVENT BROADCASTING 83

Hoofdstuk 7

Implementatie MHP–Applicatie voor

Live Event Broadcasting

De gebruiker zal thuis in de woonkamer interageren met de MHP–applicatie. De functionaliteit

van de applicatie moet op een overzichtelijke manier gepresenteerd worden en bovendien dient

de applicatie eenvoudig te hanteren zijn. Aan beide aspecten werd voldoende aandacht besteed.

In dit hoofdstuk wordt de opbouw van de applicatie en de werking ervan geschetst.

7.1 Overzicht MHP–Applicatie

In figuur 7.1 wordt een overzicht gegeven van de packages van de ontworpen MHP–applicatie.

De ontwikkelde MHP–applicatie is hierarchisch opgebouwd wat ook weerspiegeld wordt in het

bovenstaande diagram. De bovenste laag wordt gevormd door de Main–klasse. De tweede laag

bevat de modules die elk een bepaalde functionaliteit vervullen. In de onderste laag zijn tenslotte

de controllers te vinden. Deze staan in voor het gebruik van specifieke hardware bronnen of

een gerelateerde taak. Voor de communicatie tussen entiteiten op dezelfde laag of tussen lagen

wordt gebruik gemaakt van events.

7.2 Events & Controllers

7.2.1 Events

Doorheen de MHP–applicatie worden verschillende types gebeurtenissen, of zogenaamde events

gebruikt. Figuur 7.2 toont een overzicht van de voornaamste gebeurtenissen.

7.2 Events & Controllers 84

Figuur 7.1: Overzicht MHP–applicatie.

Figuur 7.2: Overzicht gebeurtenissen.

Er zijn drie categorieen objecten om een gebeurtenis aan te geven: NotificationEvent, Naviga-

tionEvent en ResourceEvent. Voor elke categorie is er een bijhorende interface om naar het type

in kwestie te luisteren: NotificationListener, NavigationListener en ResourceListener. Het type

NotificationEvent wordt gebruikt om een entiteit te informeren over een algemene gebeurtenis.

Op de figuur zijn verschillende subtypes van deze categorie weergegeven. De beschikbaarheid

van een nieuw Vodcasting–kanaal wordt aangegeven door een NewChannelEvent–object. Het

tweede type NavigationEvent geeft gebeurtenissen aan met betrekking tot navigatie. Een object

7.2 Events & Controllers 85

van de klasse ChangeScreenEvent informeert een geınteresseerde entiteit dat de gebruiker naar

een bepaald scherm wenst te navigeren. Het laatste type ResourceEvent betreft gebeurtenissen

in verband met bepaalde hardwarebronnen.

7.2.2 Controllers

Een controller staat in voor het beheer van een specifieke hardwarebron of voor een bepaalde

taak. Elke controller breidt de Controller–klasse uit. Deze klasse is abstract en voorziet een aan-

tal standaardmethodes. Zo kan een ResourceListener–entiteit toegevoegd of verwijderd worden.

Daarnaast zijn er twee methodes initController en disposeController waarvan de functionaliteit

ingevuld dient te worden bij een concrete controller en die gebruikt worden om hardware bronnen

te reserveren en vrij te geven. De BackgroundController bijvoorbeeld zal het achtergrondvlak

reserveren bij initialisatie en vrijgeven wanneer de controller wordt vernietigd.

Indien van toepassing implementeert de controller in kwestie ook de ResourceClient–interface.

Dit is een standaardinterface van de DAVIC–API’s waardoor de controller wordt verwittigd

door het systeem wanneer deze geen toegang meer heeft tot een bepaalde hardwarebron. In dat

geval worden ook de geregistreerde ResourceListener–entiteiten verwittigd. Elke controller is

bovendien geımplementeerd als singleton–klasse. Hierdoor is het eenvoudig om een referentie te

verkrijgen1.

De meeste controllers staan in voor een specifieke hardware bron, zoals het achtergrondvlak,

het videovlak, het grafisch vlak of het terugkeerkanaal. Hierop zijn twee uitzonderingen. De

MediaController staat in voor het beheer van media zoals afbeeldingen en geluiden. De control-

ler laadt media in en geeft indien een bepaald beeld of geluid gewenst is, een referentie terug.

Hierdoor wordt vermeden dat bepaalde media tweemaal ingeladen zou worden. De Service-

Controller staat in voor het huidige kanaal. Via deze component kan op een bepaald kanaal

afgestemd worden en bovendien kan de weergave van het kanaal, zoals de afmetingen van video,

worden aangepast. In [10] is uitgebreide informatie over de verschillende controllers te vinden.1Een dergelijke referentie kan steeds verkregen worden op een zelfde manier, namelijk xxxControl-

ler.getInstance().

7.3 Main & Modules 86

7.3 Main & Modules

Wanneer de applicatiebeheerder2 een MHP–applicatie opstart, wordt aan de applicatie een Xlet-

Context–object overhandigd. Dit object kan door de applicatie aangewend worden om toestands-

veranderingen door te geven aan de applicatiebeheerder3. Het object wordt bijgehouden in de

abstracte ExtendedXlet–klasse die ook de ResourceListener–interface en NotificationListener–

interface implementeert. De Main–klasse, die deze ExtendedXlet–klasse extendeert, initialiseert

de verschillende controllers en modules bij het opstarten en wordt op de hoogte gehouden van

gebeurtenissen. Figuur 7.3 toont het klassendiagram. Volgens hetzelfde stramien als bij de

Figuur 7.3: Main–klasse.

controllers, is een abstracte Module–klasse voorzien. De klasse voorziet in het toevoegen en

verwijderen van een NotificationListener–entiteit. De initModule en disposeModule methodes

moeten door de extenderende klasse voorzien worden. Elke module verschaft twee interfaces,

een naar andere modules toe en een naar de klassen binnen de verpakking van de module. De

naamgeving van deze twee types interfaces is bovendien heel transparant4. Een overzicht van

de modules en hun onderlinge relaties wordt weergegeven in figuur 7.4. In wat volgt, worden de

drie modules beschreven waaruit de MHP–applicatie is opgebouwd.2De applicatiebeheerder wordt in het MHP aangeduid met de term Application Manager.3Zie 2.4.3 voor de verschillende toestanden van een xlet.4De naam van de interface naar andere modules toe is van de vorm xxxModuleInterface en de interface voor

interne werking van de module heeft de vorm xxxInternalInterface

7.4 HTTP–Module 87

Figuur 7.4: Modules.

7.4 HTTP–Module

De HTTP–module staat in voor het verzenden en ontvangen van HTTP–berichten. Dit onderdeel

van de MHP–applicatie communiceert met de server. Het klassendiagram van deze module

wordt getoond in figuur 7.5. De HTTP–module biedt via de HTTPModuleInterface–interface de

methode getPage aan waarmee een pagina kan worden opgevraagd. De module houdt hoofdingen

bij van ontvangen berichten, zoals een cookie5 of een datum die de laatste wijziging van een

pagina aanduidt. Verzoekberichten worden steeds voozien van de nodige hoofdingen. Telkens

er een invocatie van de getPage–methode op de module plaatsvindt, wordt een HTTPThread–

object aangemaakt dat het verzoek zal afhandelen. Er kunnen ook meerdere verzoeken in parallel

worden afgehandeld. De HTTP–module biedt aan deze HTTPThread–objecten de onderstaande

interface aan.

public interface HTTPInternalInterface{

public HTTPRequest fillHeaderLines(HTTPRequest request);

public void updateHeaderLines(HTTPResponse response);

}

5Een cookie dat gebruikt wordt voor gebruikersidentificatie en door de LiveEventServlet, zie hoofdstuk 6,

wordt toegekend.

7.5 Aggregator–Module 88

Figuur 7.5: HTTP–module.

Elk HTTPThread–object zal een HTTP-verzoekbericht aanmaken en de nodige hoofdingen

laten instellen door de HTTP–module. Dit gebeurt via de fillHeaderLines–methode. Het

HTTPThread–object verstuurt vervolgens het verzoek en ontvangt een HTTP–antwoordbericht.

Indien nodig worden hoofdingen aangepast via de updateHeaderLines–methode. Als de status-

code van het antwoordbericht een fout aangeeft, genereert de HTTP–module een indicatie via

een NotificationEvent–object.

7.5 Aggregator–Module

De kern van de MHP–applicatie wordt gevormd door de Aggregator–module. Figuur 7.6 toont

het klassendiagram van de module. Deze module zal om een instelbare tijd een verzoek zenden

naar de server door gebruik te maken van de HTTP–module. De ontvangen HTML–pagina

wordt doorzocht op zoek naar referenties van vodcast feeds door gebruik te maken van een

HTMLParser–object. Voor elke gevonden referentie wordt dan de vodcast feed opgehaald via de

HTTP–module en verwerkt met een XMLParser–object. Het verwerken van meerdere vodcast

feeds gebeurt simultaan en resulteert in het opstellen of het aanpassen van een boomstructuur

waarin kanalen, items en bijlagen zijn ondergebracht6. De boomstructuur wordt bijgehouden

in een tabel waarin voor elk kanaal een ChannelInfo–object is opgenomen. Elk ChannelInfo–6Zie figuur 4.1.

7.6 GUI–Module 89

Figuur 7.6: Aggregator–module.

object bevat de items van het kanaal onder de vorm van ItemInfo–objecten. Op het diepste

niveau zijn de EnclosureInfo–objecten te vinden die ondergebracht zijn in een ItemInfo–object.

De inhoud van de boom kan via methodes in de AggregatorModuleInterface–interface eenvoudig

worden opgevraagd. Er is veel aandacht besteed aan het implementeren van deze opvraag-

methodes omdat de Aggregator–module op geregelde tijdstippen de boom aanpast. Er dient

opgemerkt te worden dat het modificeren van de boom op intelligente wijze gebeurt. Enkel

indien de server daadwerkelijk nieuwe kanalen of items meldt, wordt de boomstructuur aange-

past. Dit gaat gepaard met het genereren van bijvoorbeeld een NewChannelEvent–object of een

NewChannelItemEvent–object om daarin geınteresseerde entiteiten te verwittigen.

7.6 GUI–Module

De GUI–module staat in voor de interactie met de gebruiker. Voor deze module wordt in fi-

guur 7.7 het klassendiagram weergegeven. De GUI–module controleert de navigatie en luistert

dan ook naar NavigationEvent–objecten. De vorige, door de gebruiker genomen, navigatiestap-

pen worden bovendien bijgehouden om eenvoudig te kunnen terug navigeren naar het vorige

scherm. De module biedt via de GUIInternalInterface–interface functionaliteit aan voor de

7.6 GUI–Module 90

Figuur 7.7: GUI–module.

schermen. Sommige methodes, zoals deze die betrekking hebben op het schikken van achter-

grond en video, zijn algemeen. Andere zijn dan weer specifiek voor een bepaald scherm. In wat

volgt, wordt de opbouw van de grafische gebruikersinterface in detail besproken.

7.6.1 Componenten & Weergaves

Voor de opbouw van de schermen wordt zoveel mogelijk gebruik gemaakt van standaardcom-

ponenten. De navigatie tussen standaardcomponenten kan immers eenvoudig ingesteld worden

door middel van de setMove–methode. Hiermee wordt bepaald aan welke component de focus7

wordt doorgegeven bij het indrukken van een bepaalde knop.

7.6.1.1 Componenten

Er zijn twee klassen gedefinieerd omwille van specifieke benodigde functionaliteit. De eerste

klasse is de WScrollableText–klasse. Een tekst van willekeurige lengte kan door middel van een

object van deze klasse opgesplitst worden weergegeven, afhankelijk van hoe groot de beschik-

bare plaats is. De klasse vindt toepassing in het weergeven van bijvoorbeeld informatie over

een kanaal of helpinformatie over een scherm. De opgedeelde tekst kan dan door middel van7De gebruiker kan steeds interageren met de component die op dat ogenblik focus heeft.

7.6 GUI–Module 91

bijvoorbeeld de BOVEN –en ONDER–knoppen doorlopen worden. Om beroep te kunnen doen

op het standaard navigatiemechanisme, extendeert de WScrollableText–klasse de HText–klasse.

De tweede klasse is de WButtonList–klasse die de HListGroup–klasse extendeert. Deze klasse

voegt weinig functionaliteit aan de HListGroup–klasse toe maar verandert het gedrag zodat een

object bekomen wordt die een lijst van knoppen voorstelt. Als er naar een HListGroup–object

wordt genavigeerd, dan kunnen de elementen ervan pas worden doorlopen als op de OK–knop

wordt gedrukt. Als een WButtonList–object echter focus ontvangt, dan kan dit wel direct8.

7.6.1.2 Weergaves

Elke component van de gebruikersinterface heeft een paint–methode die opgeroepen wordt om

de component op het scherm af te beelden. Indien een nieuwe component wordt gedefinieerd,

kan het uitzicht ervan worden bepaald door die methode te overschrijven. Het spreekt voor zich

dat het telkens overschrijven van deze methode voor componenten die slechts weinig verschillen

niet efficient is. Daarom is het in MHP mogelijk om de weergave van een component te schei-

den van het gedrag ervan [24]. Aan een component kan een HLook–object worden verbonden

waarin enkel de weergave van de component wordt vastgelegd. Dit is een handig mechanisme

om eenvoudig een bepaalde uitzicht voor de gebruikersinterface vast te leggen omdat dergelijke

weergave–objecten herbruikt kunnen worden. De belangrijkste methode van deze weergave–

objecten is de showLook–methode die opgeroepen zal worden telkens de component afgebeeld

moet worden.

Voor de weergave van een object van de klasse WScrollableText wordt de WScrollableText-

Look–klasse voorzien. Omdat WScrollableText–klasse een extensie is van de HText–klasse, is

de WScrollableTextLook–klasse is een extensie van de HTextLook–klasse. Het weergave–object

tekent de navigeerbare tekst in de beschikbare ruimte en geeft door middel van pijltjes aan

of er nog meer tekst is dan wat afgebeeld wordt. Op dezelfde manier is voor de WButton-

List–klasse een WButtonListLook–klasse voorzien. De klasse tekent de component als een lijst

van knoppen en geeft ook aan door middel van pijltjes of er nog meer knoppen zijn die niet

zichtbaar zijn. Er dient echter bij deze weergave–klasse een opmerking gemaakt te worden.

De WButtonListLook–klasse breidt de HListGroupLook–klasse uit. De HListGroupLook–klasse

heeft naast de showLook–methode echter nog een andere belangrijke methode, namelijk de get-8Dit wordt verwezenlijkt door een event te sturen naar de component waardoor deze direct in selectiemode

treedt.

7.6 GUI–Module 92

NumVisible–methode. Deze methode wordt opgeroepen om na te gaan hoeveel elementen van

het HListGroup–object er zichtbaar zijn met die bepaalde weergave en is essentieel voor de wer-

king van de component. Door voor de WButtonListLook–klasse ook deze methode te voorzien,

werkt de eigen gedefinieerde weergaveklasse vloeiend samen met het interne afbeeldingssysteem.

Tenslotte werd ook nog een WGraphicLook–klasse voorzien om icoontjes af te beelden zonder

rand. Met deze klasse is kan ook tekst worden geplaatst op die icoontjes.

De weergave–klasses blijken bijzonder handig en worden dan ook gebruikt voor het visualiseren

van navigatie. Dit concept werkt als volgt. Als voor een bepaalde component richtingstoetsen

worden ingesteld voor navigatie, bijvoorbeeld bij het indrukken van RECHTS–knop wordt de

focus doorgegeven aan een bepaalde component, dan worden die navigatiemogelijkheden ook

gevisualiseerd aan de hand van blauwe pijltjes. Door dit te incorporeren in de weergave–klasses,

WScrollableTextLook en WButtonListLook, gebeurt het visualiseren van navigatie automatisch

als componenten met elkaar worden verbonden. Het verduidelijkt voor de gebruiker op elk

moment welke navigatiemogelijkheden er zijn en verhoogt zo het gemak waarmee applicatie

kan worden bediend. Het concept wordt in de huidige implementatie enkel toegepast voor de

richtingstoetsen maar kan zeker uitgebreid worden.

7.6.2 Scherm Modelvorm

Elk scherm extendeert de Screen–klasse. Deze klasse is abstract en is bedoeld als modelvorm

voor een scherm. Figuur 7.8 toont het klassendiagram voor de Screen–klasse.

Figuur 7.8: Screen–klasse.

Via het MediaController–object kunnen afbeeldingen of geluiden worden ingeladen. Er is ook

een referentie naar de GUI–module zodat bijvoorbeeld een bepaalde schikking van video en

7.6 GUI–Module 93

achtergrond kan worden aangevraagd. Elk concreet scherm dat deze modelvorm extendeert

moet een aantal methodes invullen zoals initScreen, disposeScreen, requestFocus en getHelpInfo.

De basisstructuur van een scherm wordt geıllustreerd in figuur 7.9.

Figuur 7.9: Schermmodel.

De structuur bestaat uit vier containers waarvan de onderste container wordt gebruikt om de

gekleurde toetsen op de afstandsbediening weer te geven terwijl in de bovenste container infor-

matie kan weergegeven worden. De modelvorm laat toe dat er eenvoudig nieuwe schermen aan

de GUI kunnen toegevoegd worden. In wat volgt, wordt de functionaliteit van de schermen bon-

dig overlopen. Voor de volledigheid zijn de klassendiagramma’s van de verschillende schermen

opgenomen in appendix C. Enkele momentopnames van de verschillende schermen zijn terug te

vinden in appendix D.

7.6.3 HomeScreen

Dit scherm geeft een overzicht van de MHP–applicatie en wordt direct na het opstarten weer-

gegeven. Bij het weergeven van dit scherm wordt de video geminimaliseerd. Vanuit dit scherm

kan genavigeerd worden naar specifieke onderdelen. Voor dit scherm wordt een speciale schik-

king gebruikt. Daarom worden sommige componenten van het schermmodel, zoals hierboven

beschreven, verborgen.

7.6.4 BrowserScreen

Dit scherm wordt gebruikt om eenvoudig door de kanalen en items van een kanaal te bladeren.

Terwijl dit scherm wordt getoond, wordt de video verkleind getoond aan de rechterkant. De

7.6 GUI–Module 94

Browser–interface die het scherm implementeert, voorziet in twee methodes om het scherm

naar een bepaald kanaal of een bepaald item op een kanaal te brengen. Het scherm bestaat,

naast de componenten van het schermmodel, uit vier onderdelen. Er zijn twee lijsten waarin

respectievelijk de kanalen en de items van een kanaal in worden weergegeven als knoppen.

Daarnaast zijn ook twee informatievensters beschikbaar waarin informatie over een kanaal en

informatie over een item kan worden weergegeven. De componenten overlappen echter niet

om het overzicht op het scherm niet te verliezen. Afhankelijk van de component waarnaar de

gebruiker navigeert, komt deze in beeld. De gekleurde knoppen op de afstandsbediening kunnen

gebruikt worden om naar een ander scherm te navigeren of om de video af te spelen op volledige

grootte.

7.6.5 PlayerScreen

Als vanuit het browserscherm een item wordt aangevraagd, wordt dit scherm getoond. Tevens

wordt de afbeelding in de achtergrond weggehaald en video gemaximaliseerd. Het scherm im-

plementeert de Player–interface die laat toe om de status van het afspelen of een boodschap

aan de gebruiker te tonen. Indien bijvoorbeeld, terwijl een gebruiker een bepaald item aan het

bekijken is een nieuw Vodcasting–kanaal beschikbaar geworden is, wordt dit aan de gebruiker

medegedeeld. Het afspelen van een item houdt in dat het scherm een afspeellijst zal bijhouden

van de beschikbare bijlages in het item. Het scherm heeft vijf additionele componenten ten op-

zichte van het schermmodel. Dit zijn icoontjes waarmee de gebruiker controle kan uitoefenen op

het item dat afspeelt. Enkel indien het item een videobestand betreft, kan het afspelen worden

gepauzeerd, herstart of gestopt. Als een item meerdere bijlagen heeft, bijvoorbeeld meerdere

camerastandpunten bij een live–uitzending, dan kunnen deze doorlopen worden door middel

van de buitenste icoontjes. Na een instelbare tijd verdwijnt het afspeelscherm en wordt terug

zichtbaar indien de gebruiker een knop indrukt.

7.6.6 HelpScreen

Helpinformatie is voor elk scherm beschikbaar. Het helpscherm haalt de informatie bij het

betreffende scherm op met de getHelpInfo–methode en geeft de helpinformatie weer in een tekst

die door middel van de ONDER– en BOVEN –toetsen kan doorlopen worden. De applicatie

bevat slechts een helpscherm dat de helpinformatie voor alle andere schermen kan weergegeven.

Dit wordt verwezenlijkt doordat het helpscherm de NavigationListener–interface implementeert.

7.6 GUI–Module 95

Het helpscherm wordt geregistreerd als luisteraar bij elk ander scherm. Daardoor luistert dit

scherm op de achtergrond naar de navigatie en blijft zo steeds op de hoogte van het huidige

scherm en houdt de helpinformatie klaar die van toepassing is. Indien het helpscherm wordt

opgeroepen bevat het reeds de informatie betreffende het scherm van waaruit werd genavigeerd.

7.6.7 ExitScreen

Het laatste scherm tenslotte is het verlaatscherm. Net zoals voor het thuisscherm, worden hier

een aantal elementen van het schermmodel verborgen. De functionaliteit van dit scherm ligt

voor de hand. De gebruiker kan de applicatie afsluiten of terug gaan naar het vorige scherm.

CONCLUSIE 96

Hoofdstuk 8

Conclusie

In deze scriptie werd nagegaan of live event broadcasting en videoconferencing aangeboden

kunnen worden op het MHP. Voor de implementatie van beide diensten werden architecturen

ontwikkeld die gebaseerd zijn op een gemeenschappelijk principe: het gebruik van kanalen in

de broadcast waarin media kan worden geplaatst op vraag van de gebruiker. Door dit mecha-

nisme wordt op een succesvolle manier de overbrugging van een IP–netwerk naar de broadcast

gemaakt. Het kan dan ook beschouwd worden als de sleutel waarmee naast tradionele televisie

ook nieuwe media tot in de woonkamer op het televisiescherm kunnen worden gebracht.

Voor live event broadcasting werd een architectuur ontwikkeld op basis van Podcasting waarmee

op een dynamische wijze live events kunnen worden aangeboden. Bijzonder aan het ontwikkelde

systeem is dat gebruikers zelf live–uitzendingen kunnen aanbieden aan andere gebruikers. De

architectuur blijkt bovendien ook geschikt voor andere doeleinden zoals VOD.

De architectuur voor videoconferencing werd ontworpen maar bereikte de implementatiefase

niet. De reden hiervoor ligt bij de te hoge vertraging. Dit betekent echter niet dat videocon-

ferencing niet binnen de mogelijkheden van het MHP ligt. Er rest nog onderzoekswerk om de

vertraging van camera tot televisie toestel te verlagen.

Het is mijn persoonlijke mening dat het enthousiasme waarmee digitale televisie door het publiek

zal worden onthaald niet enkel bepaald zal worden door de grootte van het aanbod televisie-

kanalen of de kwaliteit van beeld en geluid. Het zullen vooral de diensten zijn op het digitale

televisieplatform die interesse zullen opwekken. Het aanbieden van communicatievormen zoals

CONCLUSIE 97

chatten en videoconferencing en de mogelijkheid om gepersonaliseerde media te publiceren zijn

slechts enkele voorbeelden die het potentieel van het MHP illustreren.

PODCAST & VODCAST FEEDS 98

Bijlage A

Podcast & Vodcast Feeds

A.1 Podcast Feed

<?xml version=”1.0” encoding=”UTF-8” ?>

<rss xmlns:itunes=”http://www.itunes.com/DTDs/Podcast-1.0.dtd”version=”2.0”>

<channel >

<title>...</title>

<link>...</link>

<description>...</description>

<generator>...</generator>

<language>...</language>

<copyright>...</copyright>

<managingEditor>...</managingEditor>

<webMaster>...</webMaster>

<pubDate>...</pubDate>

<lastBuildDate>...</lastBuildDate>

<category>...</category>

<ttl>...</ttl>

<image>h...</image>

<itunes:summary>...</itunes:summary>

<item >

<title>...</title>

<link>...</link>

A.2 Aangepaste Vodcast Feed 99


<author>...</author>


<enclosure url=”...” length=”...” type=”...” />

<pubDate>...</pubDate>

<guid>...</guid>

<source />

</item>

</channel>

</rss>

A.2 Aangepaste Vodcast Feed

<?xml version=”1.0” encoding=”UTF-8” ?>

<rss xmlns:itunes=”http://www.itunes.com/DTDs/Podcast-1.0.dtd”version=”2.0”>

<channel id=”...”>

<title>...</title>

<author>...</author>

<link>...</link>


<subtitle>...</subtitle>

<summary>...</summary>

<language>...</language>

<copyright>...</copyright>

<owner>...</owner>

<email>...</email>


<item id=”...”>

<title>...</title>


<summary>...</summary>

<start>...</start>

A.2 Aangepaste Vodcast Feed 100

<stop>...</stop>

<enclosure id=”...” url=”...” exclusive=”...”/>

<title>...</title>

<video>...</video>

<audio>...</audio>

</enclosure>

</item>

</channel>

</rss>

DISCOVER CONFIGURE COMMAND PROTOCOL 101

Bijlage B

Discover Configure Command

Protocol

Discover Configure Command Protocol (DCCP) is een protocol voor de communicatie tussen

een Capture–module, op een host in het thuisnetwerk, en de MHP–applicatie op de STB.

Het protocol is geınspireerd op het Dynamic Host Configuration Protocol (DHCP) [11]. Fi-

guur B.1 toont een scenario. Na het opstarten, zoekt de MHP–applicatie in het thuisnetwerk

naar Capture–modules door het zenden van DISCOVER–berichten. De modules antwoorden

hierop met OFFER–berichten waarin ze ook informatie over de opname–appartuur verstrekken.

De gebruiker kan via de MHP–applicatie kiezen welke Capture–module hij wil gebruiken voor

videoconferencing. De gekozen Capture–module wordt daarvan op de hoogte gebracht door een

REQUEST–bericht. De andere modules ontvangen een REJECT–bericht. Indien een video-

conferentie wordt opgezet, kan de MHP–applicatie de gereserveerde module aanspreken om de

opname te starten met een START–bericht. Dit bericht zal ook configuratieparameters voor

de module bevatten. Bij het einde van de videoconferentie wordt de opname beeindigd aan de

hand van een STOP–bericht.

DISCOVER CONFIGURE COMMAND PROTOCOL 102

Figuur B.1: Discover Configure Communication Protocol (DCCP).

KLASSENDIAGRAMMA’S 103

Bijlage C

Klassendiagramma’s

C.1 HomeScreen

Figuur C.1: HomeScreen–klasse.

C.2 BrowserScreen 104

C.2 BrowserScreen

Figuur C.2: BrowserScreen–klasse.

C.3 PlayerScreen

Figuur C.3: PlayerScreen–klasse.

C.4 HelpScreen

Figuur C.4: HelpScreen–klasse.

C.5 ExitScreen 105

C.5 ExitScreen

Figuur C.5: ExitScreen–klasse.

MOMENTOPNAMES GEBRUIKERSINTERFACE 106

Bijlage D

Momentopnames

Gebruikersinterface

D.1 HomeScreen

Figuur D.1: Thuisscherm.

D.2 BrowserScreen 107

D.2 BrowserScreen

Figuur D.2: Browserscherm met kanalen.

Figuur D.3: Browserscherm met items.

D.3 PlayerScreen 108

Figuur D.4: Browserscherm met iteminformatie.

D.3 PlayerScreen

Figuur D.5: Afspeelscherm.

D.4 HelpScreen 109

D.4 HelpScreen

Figuur D.6: Helpscherm.

BIBLIOGRAFIE 110

Bibliografie

[1] Audio Engineering Society (AES) (2003). AES3-2003: AES Recommended practice for

digital audio engineering – Serial transmission format for two-channel linearly represented

digital audio data (Revision of AES3-1992, including subsequent amendments).

[2] BASET, S. & SCHULZRINNE, H. (2004). An Analysis of the Skype Peer-to-Peer Internet

Telephony Protocol. USA, New York, Department of Computer Science, Columbia Univer-

sity.

[3] BRUNEEL, H. (2005). Wachtlijntheorie. Cursus, Gent, Faculteit Ingenieurswetenschappen,

Universiteit Gent.

[4] BUGAJSKI, M. (2004). Convergence of Video in the Last Mile: MPEG2-

TS and DOCSIS, Technical Paper for Jornadas 2004 Conference.

http://www.arrisi.com/products solutions/applications/white papers/

Convergence Video Last Mile.pdf (geconsulteerd op 22 november 2005).

[5] CableLabs (2005). OpenCable Application Platform Specification OCAP 1.0 Profile. Doc.:

OCAP1.0.

[6] CableLabs (2005). OpenCable Application Platform Specification OCAP Home Networking

Extension. Doc.: OCAP-HNEXT1.0.

[7] DekTec Digital Video BV (2005). DTAPI – C++ API for DekTec devices.

http://www.dektec.com/Products/DTAPI/Downloads/DTAPI.pdf

[8] DEMEESTER, P. (2004). Communicatienetwerken. Cursus, Gent, Faculteit Ingenieur-

swetenschappen, Universiteit Gent.

[9] DEMEESTER, P. & PICKAVET, M. (2005). Multimedianetwerken. Cursus, Gent, Faculteit

Ingenieurswetenschappen, Universiteit Gent.

BIBLIOGRAFIE 111

[10] DEMEYERE, K. (2006). Analyse & Ontwerp van een Applicatie voor Videoconferencing &

Live Event Broadcasting – JavaDoc (CD–ROM). Master of Science Thesis, Gent, Faculteit

Ingenieurswetenschappen, Universiteit Gent.

[11] DROMS, R. (1995). Dynamic Host Configuration Protocol.

http://www.ietf.org/rfc/rfc2131.txt (geconsulteerd op 7 november 2005).

[12] European Telecommunications Standards Institute (ETSI) (1996). Digital Video Broad-

casting (DVB); Support for use of scrambling and Conditional Access (CA) within digital

broadcasting systems. Doc.nr: ETSI ETR 289 October 1996.


casting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite

services. Doc.nr.: ETSI EN 300 421 v1.1.2 (1997-08).

[14] European Telecommunications Standards Institute (ETSI) (1998). Digital Video Broadcast-

ing (DVB); Framing structure, channel coding and modulation for cable systems. Doc.nr.:

ETSI EN 300 429 v1.2.1 (1998-04).


casting (DVB); Multimedia Home Platform (MHP) Specification 1.0.2. Doc.nr.: TS 101812

v1.2.1 (2002-06).


casting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1. Doc.nr.: TS 101812

v1.2.1 (2003-06).


casting (DVB); Transmission System for Handheld Terminals. Doc.nr.: ETSI EN 302 304

v1.1.1 (2004-11).


casting (DVB); Framing structure, channel coding and modulation for digital terrestrial

television. Doc.nr.: ETSI EN 300 744 v1.5.1 (2004–11).


casting (DVB); Specification for Service Information in DVB Systems. Doc.nr.: ETSI EN

300 468 v1.7.1 (2005-12).

BIBLIOGRAFIE 112

[20] FOX, G., WU, W., UYAR, A. & BULUT, H. (2004). Design and Implementation of Au-

dio/Video Collaboration System Based on Publish/subscribe Event Middleware. USA, New

York, Department of Electrical Engineering and Computer Science, Syracuse University.

[21] FOX, G., WU, W., UYAR, A. & BULUT, H. (2006). Service-Oriented Architecture for

Building a Scalable Videoconferencing System. USA, New York, Department of Electrical

Engineering and Computer Science, Syracuse University.

[22] FREYHULT, S. (2004). Streaming Video on IP Networks. Master’s Thesis in Computer

Science, Sweden, Stockholm, Department of Numerical Analysis and Computer Science,

Royal Institute of Technology.

[23] HANDLEY, M., & JACOBSON, V. (1998). SDP: Session Description Protocol.


[24] HAVi Inc. (2001). Specification of the Home Audio/Video Interoperability (HAVi) Archi-

tecture, Chapter 8 Level 2 User Interface. http://www.havi.org/techinfo/docs/Chapter8-

HAVi1.1-May15.pdf (geconsulteerd 15 november 2005).

[25] International Standards Organisation / International Electrotechnical Commission

(ISO/IEC) (1994). Information technology - Generic coding of moving pictures and as-

sociated audio: Systems. Doc.nr.: ISO/IEC 13818-1.



sociated audio: Video. Doc.nr.: ISO/IEC 13818-2.



sociated audio: Audio. Doc.nr.: ISO/IEC 13818-3.



sociated audio: Extensions for DSM-CC. Doc.nr.: ISO/IEC 13818-6.

[29] International Telecommunication Union Radiocommunication (ITU–R) (1995). Recommen-

dation ITU-R BT.601-5 Studio encoding parameters of digital television for standard 4:3

and wide–screen 16:9 aspect ratios.

BIBLIOGRAFIE 113

[30] LYTRAS, M., LOUGOS, C., CHOZOS, P. & POULOUDI, A. (2003) Interactive Television

and E-Learning Convergence: Examining the Potential of T-Learning. Greece, Athens,

Department of Management Science & Technology, Athens University of Economics and

Business.

[31] MARTENS, L. (2004). HFC–Toegangsnetwerken: case study. Cursus, Gent, Faculteit In-

genieurswetenschappen, Universiteit Gent.

[32] PARKINSON, R. (2002). Traffic Engineering Techniques in Telecommunications.

http://www.infotel-systems.com (geconsulteerd op 11 maart 2006).

[33] PIESING, J. (2006). Roadmap for MHP and Related Technologies. Presented at DVB

World 2006 - The Challenge of Choice, Dublin, March 2, 2006.

[34] RICHARDSON, I. (2002). Video Codec Design, Developing Image and Video Compression

Systems. England, Wiley.

[35] ROSENBERG, J., SCHULZRINNE, H., CAMARRILLO, G., JOHNSTON, A.,

PETERSON, J., SPARKS, R., et al. (2002). SIP: Session Initiation Protocol.


[36] SINGH, K. & SCHULZRINNE, H. (2004). Peer-to-Peer Internet Telephony using SIP. USA,

New York, Department of Computer Science, Columbia University.

[37] Sun Microsystems, Inc. (1994-2005). Abstract Window Toolkit (AWT) 1.0 API Specifica-

tions. http://java.sun.com/products/jdk/awt/.

[38] Sun Microsystems, Inc. (1994-2005). Java Media Framework (JMF) 1.0 API Specifications.

http://java.sun.com/products/java-media/jmf/1.0/.

[39] Sun Microsystems, Inc. (1994-2005). Java Stream Assembly API, Version 1.0, Community

Draft. http://www.jcp.org/aboutJava/communityprocess/pr/jsr158/index.html (geconsul-

teerd op 24 november 2005).

[40] TKACHENKO, D., & KORNET, N. (2004). Convergence of iDTV and Home Network

Platforms. Russia, St.Petersburg, Radio Engineering and Telecommunications Department,

St.Petersburg State Polytechnic University.

[41] WINNER, D. (2005). RSS 2.0 Specification. http://blogs.law.harvard.edu/tech/rss.

Vakgroep Informatietechnologie

Documents

Transcript of Vakgroep Informatietechnologie