Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: prof. dr. ir. P. Demeester
Implementatie en evaluatie van een raamwerk voor iDTV-triggering door Pieter Simoens
Promotoren: prof. dr. ir. P. Demeester, prof. dr. ir. F. De Turck Scriptiebegeleiders: ir. M. Strobbe, ir. V. Verstraete
Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur
Academiejaar 2004–2005
Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: prof. dr. ir. P. Demeester
Implementatie en evaluatie van een raamwerk voor iDTV-triggering door Pieter Simoens
Promotoren: prof. dr. ir. P. Demeester, prof. dr. ir. F. De Turck Scriptiebegeleiders: ir. M. Strobbe, ir. V. Verstraete
Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur
Academiejaar 2004–2005
Woord vooraf Bij het voltooien van deze scriptie wens ik iedereen te bedanken die rechtstreeks of onrechtstreeks heeft bijgedragen tot de realisatie ervan. In de eerste plaats richt ik een woord van dank naar mijn promotoren, prof. dr. ir. P. Demeester en prof. dr. ir. F. De Turck. Hun regelmatige en oprechte interesse in mijn vorderingen is zeker een stimulans geweest gedurende het voorbije academiejaar. Ik ben dan ook verheugd dat ik vanaf volgend jaar deel mag uitmaken van hun onderzoeksgroep. Deze scriptie verliep in samenwerking met Belgacom. Ook van hun zijde mocht ik heel wat steun en interesse ervaren. Ik wens dan ook de heer J. De Praetere en de heer D. Delcoigne uitdrukkelijk te bedanken voor het uitschrijven van dit enigszins aparte scriptie-onderwerp. Mijn begeleiders, ir. Matthias Strobbe en ir. Vincent Verstraete, verdienen uiteraard een bijzondere vermelding. Ik kon altijd bij hen terecht met allerlei kleine en grote problemen. Steeds opnieuw gingen ze snel en met veel enthousiasme op zoek naar een oplossing. Ik hoop dat ik hen met deze scriptie iets in ruil kan aanbieden en dat de resultaten nuttig kunnen zijn voor hun verder onderzoek. Tot slot wens ik mijn ouders, familie en vrienden te bedanken. Ze hebben me doorheen dit op studie- en priv´e-gebied zware jaar geholpen. Hun bijdrage mag dan misschien niet tastbaar aanwezig zijn in de voorliggende scriptie, ze is daarom niet minder waardevol gebleken voor de realisatie ervan.
Pieter Simoens, mei 2005
Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren 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.”
Pieter Simoens, mei 2005
Implementatie en evaluatie van een raamwerk voor iDTV-triggering door Pieter Simoens Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur Academiejaar 2004–2005 Promotoren: prof. dr. ir. P. Demeester, prof. dr. ir. F. De Turck Scriptiebegeleiders: ir. M. Strobbe, ir. V. Verstraete Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: prof. dr. ir. P. Demeester
Samenvatting Digitale TV zal op korte termijn zijn weg vinden naar de huiskamer. De introductie van deze nieuwe technologie maakt tal van nieuwe toepassingen mogelijk. Een van de meest veelbelovende domeinen is de mogelijkheid om interactiviteit aan de TV-kijker aan te bieden. In deze scriptie wordt een raamwerk opgesteld dat de broadcaster de mogelijkheid biedt om welbepaalde signalen, zgn. triggers, mee te sturen met de digitale TV-beelden. Bij ontvangst van de triggers onderneemt de settop-box bij de eindgebruiker welbepaalde acties of “events”. Een typisch voorbeeld is het verschijnen van een rode stip op het scherm. De scriptie is drieledig opgebouwd. In een eerste deel wordt onderzocht hoe de triggers zo effici¨ent mogelijk kunnen meegestuurd worden met de TV-beelden. Hierbij wordt de MPEG-2 Transport Stream als video-codec gebruikt. Naast de keuze van een transportmechanisme worden ook de talrijke eisen aan een triggermechanisme ge¨ıdentificeerd. In het tweede deel wordt een applicatie ontworpen om de triggers op de juiste ogenblikken in te brengen in de videostroom. Het derde deel beschrijft de bouw van een applicatie die de settop-box bij de eindgebruiker simuleert. Deze applicatie staat in voor de weergave van de events. Er worden tevens belangrijke besluiten geformuleerd om een triggermechanisme effici¨ent te kunnen implementeren zonder de vlotte weergave van de videobeelden in het gedrang te brengen.
Trefwoorden iDTV, digitale TV, MPEG2, raamwerk, trigger.
INHOUDSOPGAVE
i
Inhoudsopgave 1 Inleiding
1
2 Gedetailleerde probleemstelling
6
2.1
2.2
Eisen aan het raamwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Algemene vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.2
Do-it-now en scheduled events
. . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.3
Tijdsinformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.4
Signalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.5
Private data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 MPEG-2 Transport Stream 3.1
3.2
15
MPEG-2 Transport Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.1
Anatomie van een Transport Stream . . . . . . . . . . . . . . . . . . . . .
16
3.1.2
Tables: orde in de chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1.3
Timing en synchronisatie . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.4
Private Sections: transporteren van data . . . . . . . . . . . . . . . . . . .
21
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4 Het Multimedia Home Platform 4.1
4.2
23
Wat is MHP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.1.1
De gelaagde MHP-structuur . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.2
MHP-applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.3
Het carrouselprincipe
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Triggeren van events met MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.2.1
30
De basis: DSM-CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INHOUDSOPGAVE
ii
4.2.2
De Object Carousel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.3
Normal Playing Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2.4
Het samenspel van Stream Event Objects en Stream Event Descriptors .
34
4.3
Evaluatie van MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.4
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5 Implementatie van het raamwerk 5.1
41
De triggers in de Transport Stream . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.1.1
Transport van private data in een Transport Stream . . . . . . . . . . . .
42
5.1.2
Het protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.1.3
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.2
Het model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.3
Het raamwerk aan de zenderzijde . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.3.1
Functies van de zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.3.2
Opbouw van de zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Het raamwerk aan de ontvangerzijde . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.4.1
Functies van de ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . .
69
5.4.2
Opbouw van de ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . .
70
5.5
Voorbeeldapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.6
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.4
6 Evaluatie van het raamwerk 6.1
6.2
80
Berekening van de capaciteit van een private section . . . . . . . . . . . . . . . .
80
6.1.1
Private section met signalisatie . . . . . . . . . . . . . . . . . . . . . . . .
82
6.1.2
Private section met triggers . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
7 Conclusies
88
A Syntax van Private Section
90
A.1 Private Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.2 DSM-CC Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
B Protocol B.1 Signalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93 93
INHOUDSOPGAVE
iii
B.2 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
B.2.1 NPT-descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
B.2.2 Do-it-now descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
B.2.3 Scheduled-event descriptor
96
. . . . . . . . . . . . . . . . . . . . . . . . . .
C Handleiding
98
C.1 Installatie QuickTime for Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
C.2 Zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
C.2.1 Installatieprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
C.2.2 Gebruik van de zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . . 100 C.2.3 iDTV Foot-zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.3 Ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.3.1 Installatieprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.3.2 Gebruik van de ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . . 102 C.3.3 iDTV Foot-ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . . . . 102 D Inhoud van de CD-ROM
103
INHOUDSOPGAVE
Lijst van gebruikte afkortingen
API BIOP CPU DSLAM DSM-CC DTS DVB DVD EDT ES GUI iDTV IEC ISO JMF JNI MHP MPEG MPTS NPT OC PAT PCR PES PID PMT PS PTS QTJ SE SPTS STB STC TS
Application Programming Interface Broadcast Inter-ORB Protocol Central Processing Unit Digital Subscriber Line Access Multiplexer Digital Storage Media Command and Control Decoding Time Stamp Digital Video Broadcasting (Project) Digital Versatile Disk Event Dispatching Thread Elementary Stream Graphical User Interface interactieve Digitale TeleVisie International Electrotechnical Commission International Organisation for Standardization Java Media Framework Java Native Interface Multimedia Home Platform Moving Picture Experts Group Multi-Program Transport Stream Normal Playing Time Object Carousel Program Association Table Program Clock Reference Packetised Elementary Stream Packet IDentifier Program Map Table Program Stream Presentation Time Stamp QuickTime for Java Stream Event Single Program Transport Stream SetTop-Box System Time Clock Transport Stream
iv
INLEIDING
1
Hoofdstuk 1
Inleiding In 2003 - 2004 werd het 50-jarig bestaan gevierd van het medium televisie in Vlaanderen. Na al die jaren heeft de TV ongetwijfeld een prominente en centrale rol opge¨eist in de huiskamer, hoewel die positie recent onder druk komt te staan door de concurrentie van het internet. Op dit moment is het medium klaar voor een nieuwe stap, die minstens even ingrijpend zal zijn als de overgang van zwart-wit naar kleurentelevisie: interactieve digitale televisie. Het is belangrijk om de beide concepten digitaal en interactief goed te onderscheiden, want samen bepalen ze de kracht van deze nieuwe technologische evolutie. “Digitale” TV duidt aan dat het TV-signaal verstuurd wordt als een digitaal en niet als een analoog signaal. Het grote voordeel hiervan is de mogelijkheid om geavanceerde compressie-technieken toe te passen op de audiovisuele data, waardoor er binnen een zelfde bandbreedte onder digitale vorm veel meer informatie kan verstuurd worden dan in het analoge geval. Ook andersom is het mogelijk om binnen een zelfde bandbreedte een veel hogere beeldkwaliteit aan te bieden. Om die digitale TV-signalen te kunnen decoderen, moet er bij de eindgebruiker een settop-box (STB) geplaatst worden. De extra ruimte die vrijkomt door de verbeterde digitale compressie kan enerzijds aangewend worden om meer zenders aan te bieden, maar anderzijds geeft ze ook de kans om allerlei nieuwe toepassingen aan te bieden: “interactieve” TV. Het concept van interactieve TV kan het best gevat worden in een tweeledige omschrijving: enhanced TV: de broadcaster stuurt extra informatie door, die de gebruiker kan opvragen.
Voorbeelden zijn de elektronische programmagids en teletekst. Er is een eenrichtingsverkeer van broadcaster naar kijker. De interactiviteit van de kijker beperkt zich tot het maken van een keuze uit het (uitgebreide) aanbod van de provider.
INLEIDING
2
interactive services: de zender stuurt extra informatie door, maar de gebruiker kan daarop
actief reageren en het aanbod manipuleren. Hij stuurt hierbij ook informatie terug naar de broadcaster. Dit is dus een uitgebreidere vorm van interactiviteit. Het is in dit laatste gebied dat het onderwerp van voorliggende scriptie zich situeert. Ze werd uitgeschreven in samenwerking met de nationale telecommunicatie-operator Belgacom. Anno 2005 werd door hen een volledig digitaal TV-platform ontwikkeld dat klaar is om commercieel gelanceerd te worden. Zoals reeds vermeld zal daartoe bij de eindgebruiker een settop-box ge¨ınstalleerd worden (zie figuur 1.1).
settop-box
applicatie A
applicatie B
applicatie C
middleware
Tuner
Decoder
Conditional Acces
Figuur 1.1: Principieel schema van een settop-box
De settop-box staat in de eerste plaats in voor het selecteren en decoderen van de digitale TVsignalen, maar er kunnen ook allerlei toepassingen in opgeslagen worden die zo het concept van interactieve TV in de huiskamer introduceren. Op de settop-box is daarvoor middleware aanwezig. Dit is software die fungeert als een soort lijm tussen de verschillende applicaties, zodat die onderling kunnen samenwerken. De best gekende voorbeelden zijn de elektronische programmagids en de walled garden (te vergelijken met een portaalsite op het internet). Deze applicaties, die kunnen ondergebracht worden in de categorie van enhanced TV, hebben als gemeenschappelijk kenmerk dat ze extra mogelijkheden bieden, die weliswaar weinig of geen verband houden met het TV-programma dat op dat moment uitgezonden wordt. Ze zijn reeds ruim verspreid in de digitale TV-wereld en zullen uiteraard ook aanwezig zijn in het digitaal TV-pakket van Belgacom bij de lancering ervan.
INLEIDING
3
Een telecommunicatie-operator moet, gedreven door de sterke concurrentie, steeds opnieuw op zoek naar nieuwe toepassingen en uitbreidingen van zijn aanbod. Het is dan ook logisch dat Belgacom sterk ge¨ınteresseerd is om ook de tweede soort applicaties, de interactive services, aan te bieden. Deze applicaties vertonen, in tegenstelling tot de enhanced TV-applicaties, typisch wel een verband met het TV-programma dat op dat moment uitgezonden wordt. In deze scriptie is het de bedoeling om principieel na te gaan wat de vereisten zijn die zulke applicaties stellen en welke beperkingen en mogelijkheden zich hierbij aanbieden. Ondertussen startte het Instituut voor BreedBandTechnologie o.a. in samenwerking met Belgacom en IBCN-INTEC het MCDPproject1 , waarin ook interactive services zullen onderzocht worden [1]. In deze scriptie ligt de nadruk op de ontwikkeling van een principieel raamwerk om interactieve applicaties mogelijk te maken, eerder dan op de ontwikkeling van applicaties voor de settop-box. Om het kader van deze scriptie evenwel iets beter te schetsen, zullen twee typische voorbeelden van beoogde applicaties behandeld worden. De ge¨ınteresseerde lezer vindt tal van andere voorbeelden in [2]. Meteen zal ook de typische terminologie ge¨ıntroduceerd worden. Het eerste typevoorbeeld is een interactieve reclamespot. Op het moment dat de spot wordt uitgezonden, verschijnt ook een rode stip (de zgn. red dot) op het scherm (zie figuur 1.2). De TV-kijker weet op die manier dat hij extra informatie over het geadverteerde product kan opvragen door de rode toets op zijn afstandsbediening in te drukken. Er wordt dan bv. een pagina of zelfs een website met extra informatie over het product geopend.
Figuur 1.2: Interactieve reclamespot 1
Multimedia Content Distribution Platform.
INLEIDING
4
Een interactieve quiz is een tweede typevoorbeeld van interactive services. Zodra de quizvraag op het scherm wordt getoond, verschijnt naast elk van de mogelijkheden een gekleurde stip. De kijker kan dan zijn antwoord ingeven door de corresponderende toets op zijn afstandsbediening in te drukken. Op het einde van de quiz krijgt de kijker zijn persoonlijke score te zien en kan hij er eventueel voor kiezen om deel te nemen aan een prijsvraag.
Figuur 1.3: Interactieve quiz
Bij beide applicaties is het duidelijk dat de zender in staat moet zijn om op een of andere manier een teken te geven aan de settop-box dat die een bepaalde actie, zoals het weergeven van een rode stip, moet ondernemen. Deze tekens worden triggers genoemd en de acties die er op volgen events. Men spreekt over een event dat getriggerd wordt. Verder moet er een of andere vorm van synchronisatie of tijdsinformatie voorzien worden. De rode stip moet immers enkel tijdens die ene spot getoond worden, en de gekleurde stippen naast de mogelijke antwoorden mogen niet te vroeg verschijnen en al evenmin te laat weer van het scherm verdwijnen. Het is die synchronisatie met het TV-programma die de applicaties voor interactive services onderscheidt van die voor enhanced TV. In deze scriptie werd tot doel gesteld om een principieel raamwerk te ontwikkelen dat de triggering van settop-box applicaties mogelijk moet maken. In de volgende hoofdstukken wordt uiteengezet hoe dit probleem werd aangepakt. Hoofdstuk 2: Gedetailleerde probleemstelling In dit hoofdstuk wordt een nauwkeurige analyse gemaakt van alle vereisten waaraan het raamwerk zal moeten voldoen. Hierbij worden enkele belangrijke concepten ingevoerd, zoals het onderscheid tussen do-it-now events en
INLEIDING
5
scheduled events, en zal op zoek gegaan worden naar een geschikte tijdsbasis voor het triggermechanisme. Meteen zal ook de veelzijdigheid van een mechanisme voor de triggering van events duidelijk worden. Hoofdstuk 3: MPEG-2 Transport Stream Het digitaal TV-netwerk van Belgacom maakt gebruikt van de MPEG-2 Transport Stream videocodering. Dit hoofdstuk heeft dan ook tot doel om de lezer de nodige technische achtergrondinformatie over deze codec te bezorgen, zodat hij de uiteenzetting van het raamwerk in de volgende hoofdstukken ten volle kan begrijpen. De opbouw van een Transport Stream uit verschillende Elementary Streams wordt besproken, evenals de tables die structuur aanbrengen in deze Elementary Streams. Hoofdstuk 4: Multimedia Home Platform MHP is tot op vandaag de enige open standaard voor middleware op een settop-box en wordt in dit vierde hoofdstuk uitgebreid bestudeerd. Er wordt ingegaan op de algemene opbouw van het platform, alvorens het triggermechanisme in MHP in detail te onderzoeken. Uiteindelijk zal blijken dat deze bestaande oplossing niet afgestemd is op het netwerk van Belgacom en daarom niet voldoet om een triggermechanisme mee uit te bouwen. Hoofdstuk 5: Implementatie van het raamwerk In dit hoofdstuk wordt de structuur van het ontwikkelde raamwerk uit de doeken gedaan. In een eerste deel wordt het protocol toegelicht dat zal gebruikt worden om de triggers en de events te transporteren tussen zender en ontvanger. Vervolgens wordt de opbouw van de zend- en ontvangstmodule uit de doeken gedaan. De zendmodule staat in voor het inbrengen van de triggers in de Transport Stream, terwijl de ontvangstmodule als taak heeft om deze triggers te detecteren en hierop gepast te reageren. Beide modules werden deels in C en deels in Java ontwikkeld. Hoofdstuk 6: Evaluatie van het raamwerk Dit hoofdstuk bevat een theoretische analyse van de performantie van het raamwerk. Het transportmechanisme van de triggers kent enkele beperkingen. Dankzij de berekeningen in dit hoofdstuk kan de lezer zich een idee vormen over hoe stringent deze beperkingen zijn. In een tweede deel worden enkele gebieden aangegeven waarin verder onderzoek mogelijk is. In deze scriptie werden Engelse termen doelbewust niet uit de weg gegaan. Een vertaling van sommige termen zou voor de lezer enkel onduidelijkheid veroorzaken. Om die reden worden de meeste Engelse begrippen normaal gedrukt. Enkel als een nieuw concept wordt ingevoerd, wordt dit eenmalig cursief getoond.
GEDETAILLEERDE PROBLEEMSTELLING
6
Hoofdstuk 2
Gedetailleerde probleemstelling De Unified Modeling Language definieert een raamwerk (framework ) als “an architectural pattern that provides an extensible template for applications within a domain” [3]. Een raamwerk defini¨eren betekent dus een soort skelet of blauwdruk van een architectuur vastleggen, samen met een aantal tools voor de gebruiker die deze architectuur aan zijn eigen situatie wenst aan te passen. In het concrete kader van deze scriptie betekent dit dat het ontwikkelde raamwerk een soort software-architectuur moet implementeren die het triggermechanisme mogelijk maakt. In dit hoofdstuk wordt in detail nagegaan welke mogelijkheden een volwaardig triggermechanisme moet aanbieden aan de gebruikers ervan. Uit deze analyse vloeien meteen een aantal eisen voort waaraan het raamwerk zal moeten voldoen.
2.1
Eisen aan het raamwerk
In het vorige hoofdstuk werden een interactieve reclamespot en een quiz beschreven. Dit zijn voorbeelden van het type van applicaties dat men voor ogen dient te houden bij het ontwerp van het raamwerk. Hierbij moet natuurlijk in de eerste plaats rekening gehouden worden met de mogelijkheden, en dus ook de beperkingen, van het digitale TV-netwerk van Belgacom. Daarnaast zijn er de eisen die gedistilleerd kunnen worden uit een nauwkeurige analyse van een triggermechanisme.
2.1 Eisen aan het raamwerk
2.1.1
7
Algemene vereisten
De scriptie-opdracht kadert binnen de uitbouw van het digitale TV-project van Belgacom. Dit legt meteen enkele, weliswaar vrij algemene, randvoorwaarden op aan het raamwerk: generiek: Met het oog op een verdere uitbouw moet het raamwerk een zo breed mogelijk
spectrum aan toepassingen mogelijk maken en zo weinig mogelijk inherente beperkingen kennen. MPEG-2 TS: Het TV-netwerk van Belgacom maakt gebruik van de MPEG-2 Transport
Stream. Het raamwerk zal dus gestoeld worden op deze standaard [4], die wordt toegelicht in hoofdstuk 3. Java: De huidige middleware op de settop-box van Belgacom bevat een Java-kern. Met
het oog op maximale compatibiliteit met de bestaande infrastructuur gaat de voorkeur van Belgacom uit naar een Java-gebaseerde oplossing, maar dit is geen absolute voorwaarde.
2.1.2
Do-it-now en scheduled events
De fundamentele vereiste is natuurlijk dat het mogelijk moet zijn dat de zender - op een voorlopig nog niet nader omschreven manier - een soort sein of signaal kan geven aan de ontvanger, waarop die welbepaalde acties zal uitvoeren. Zoals reeds aangehaald zullen de signalen in het vervolg als triggers en de hieruit resulterende reacties van de (applicaties op de) settop-box als events aangeduid worden. Om het onderscheid tussen beide begrippen beter te begrijpen, zal even verder geredeneerd worden vanuit het standpunt van de broadcaster. Typisch zal zijn programmatie hoofdzakelijk bestaan uit vooraf opgenomen programma’s. Af en toe zal er echter ook een live programma, zoals het nieuws, uitgezonden worden. Aangezien het toepassingsgebied van het raamwerk zo breed mogelijk moet gehouden worden, is het belangrijk om rekening te houden met beide opties. Bij vooraf opgenomen programma’s is het een plausibele optie om de exacte tijdstippen van de events tijdens de post-productie te bepalen: men bekijkt het gemonteerde programma en bepaalt wanneer de events moeten optreden. De daarbij horende triggers kunnen dan zo gepland worden dat ze een tijdje voor het eigenlijke event doorgestuurd worden met de videostroom, zodat de settop-box tijdig de nodige voorzieningen kan treffen om het event weer te geven. De trigger kan zelfs meermaals doorgestuurd worden, zodat de settop-box hem zeker detecteert. Dit soort events worden scheduled events genoemd: de triggers geven een event in
2.1 Eisen aan het raamwerk
8
de toekomst aan, het event wordt gepland. Bij live programma’s is dit uiteraard onmogelijk. Als de regie een event wil laten optreden, zal ze een trigger doorsturen met de videostroom. Het exacte tijdstip kan echter niet op voorhand bepaald worden. Zodra de settop-box de trigger detecteert, voert hij ogenblikkelijk het corresponderende event uit. De ontvangst van de trigger en het optreden van het event vallen dus in dit geval samen. Men spreekt dan ook over do-it-now events: de trigger laat het corresponderende event onmiddellijk optreden. In figuur 2.1 worden de beide manieren om een event te triggeren ge¨ıllustreerd, evenals het conceptuele verschil tussen een trigger en een event. Het raamwerk zal beide soorten triggers moeten ondersteunen.
scheduled event tijd
trigger event
do-it-now event tijd
Figuur 2.1: Triggers voor een scheduled en een do-it-now event
Het is belangrijk op te merken dat een event op zich, bv. een rode stip weergeven, op beide manieren kan getriggerd worden. Het onderscheid tussen deze twee types van events gebeurt enkel en alleen op basis van de triggers. In hetzelfde programma kan een event dus de ene keer optreden als een do-it-now en de volgende keer als een scheduled event.
2.1.3
Tijdsinformatie
Bij do-it-now events is er geen nood aan tijdsinformatie: het event treedt op zodra de trigger ontvangen wordt. Daarentegen worden bij scheduled events de triggers vooraf doorgestuurd en moet het exacte tijdstip van de events kunnen vastgelegd worden. Bovendien moet de settop-box de tijdsinformatie correct kunnen interpreteren, zodat het event ook daadwerkelijk op het juiste ogenblik wordt weergegeven. Het probleem is overigens nog iets uitgebreider. In een digitaal TV-netwerk is het mogelijk om een programma te pauzeren en terug- of door te spoelen, net zoals bij het streamen van een video over het internet. Uiteraard moeten de events steeds
2.1 Eisen aan het raamwerk
9
weer op de gepaste ogenblikken optreden, hoe vaak de gebruiker ook van deze mogelijkheden gebruik maakt. Het is duidelijk dat er een of andere tijdsbasis zal moeten voorzien worden in het raamwerk. In een multimediale datastroom is er steeds tijdsinformatie aanwezig. Dankzij die informatie kan een correcte decodering en synchronisatie van de audio en video gegarandeerd worden. Zo vermijdt men situaties zoals het over- en onderlopen van buffers of het optreden van lip sync, waarbij het geluid achterloopt op de video. In deze scriptie wordt de MPEG-2 Transport Stream gebruikt. In hoofdstuk 3 wordt in detail uitgelegd hoe de tijdsinformatie bij die codec gestructureerd wordt. Voorlopig volstaat het te weten dat er gebruik wordt gemaakt van een klok die gesynchroniseerd wordt tussen zender en ontvanger: de System Time Clock (STC). Op het moment dat een video- of audioframe gecodeerd wordt, krijgt deze een “tijdsstempel” mee, die de waarde van de STC op dat ogenblik bevat. Op basis van deze stempels bepaalt de decoder wanneer de frames moeten gedecodeerd worden. Op het eerste zicht lijkt deze klok voldoende informatie te bieden voor triggers van scheduledevents: de triggers bevatten dan de STC-waarde van het frame dat moet worden weergegeven op het ogenblik dat het event optreedt. De STC is evenwel een absolute, monotoon oplopende klok. Als de TV-kijker het programma kan terug- of doorspoelen, is er geen eenduidig verband meer tussen de STC-klok en het weergegeven videoframe. Dit wordt ge¨ıllustreerd in figuur 2.2.
tijd A
B
C
B
15 0
16 1
17 2
18 1
A
B
server
netwerk
19 0
A
B
C
B
15 0
16 1
17 2
18 1
20 1
A
STC NPT
B
TV 19 0
Figuur 2.2: Onderscheid tussen STC en NPT
20 1
STC NPT
2.1 Eisen aan het raamwerk
10
Veronderstel dat er een film bekeken wordt, die bestaat uit een aantal opeenvolgende frames A-BC1 . Achtereenvolgens worden de frames A, B en C getoond. De server stuurt die frames door en voorziet ze van de gepaste STC-waarde, die het moment aangeeft waarop ze moeten weergegeven worden. Opeens beslist de kijker om terug te spoelen naar frame A, waarbij uiteraard eerst nog frame B moet gepasseerd worden. Er wordt een boodschap naar de server gestuurd, die achtereenvolgens de frames B en A opnieuw doorstuurt. Op basis van de STC-waarden weet de ontvanger dat hij, tijdens het terugspoelen, eerst frame B en dan frame A moet weergeven. Meteen is duidelijk dat de STC niet kan voldoen voor een triggermechanisme. Indien er bv. bij frame B een event moet optreden, dan is het wenselijk dat dit gebeurt ´elke keer als frame B wordt getoond. Uit de figuur is evenwel op te maken dat frame B steeds een andere STC-waarde heeft, zodat het niet duidelijk is welke tijdswaarde de triggers voor het scheduled event moeten aangeven. Eventueel zou de server elke keer samen met frame B een do-it-now trigger voor het event kunnen doorsturen, maar deze oplossing voldoet bv. niet indien de Transport Stream wordt opgeslagen op de lokale harde schijf van de settop-box. De server komt dan bij het opnieuw bekijken immers niet meer tussen. Het is een betere oplossing om een soort klok te voorzien die net zoals de videobeelden kan gepauzeerd en terug- of doorgespoeld worden. Zo’n klok kan wel een nauwkeurig verband met de onderliggende videoframes behouden. Een dergelijke klok is een soort analogon van de timer op een DVD- of videotoestel. In het vervolg van deze scriptie wordt zo’n tijdsbasis Normal Playing Time (NPT) genoemd. De oorsprong van deze term zal in hoofdstuk 4 duidelijk worden. De NPT wordt eveneens weergeven in figuur 2.2 en is duidelijk beter geschikt voor een triggermechanisme: frame B heeft elke keer het getoond wordt dezelfde NPT-waarde. De STC geeft aan wanneer een bepaald frame moet weergegeven worden, terwijl de NPT aangeeft welk frame er getoond wordt. De NPT is dus veel nauwer verweven met de frames. Toch biedt de NPT in deze vorm nog steeds niet de flexibiliteit die mag ge¨eist worden van een generiek raamwerk. Het is nu wel mogelijk om de positie van de events voor een programma ondubbelzinnig vast te leggen, maar dat programma mag later niet meer gewijzigd worden. Dit wordt verduidelijkt in figuur 2.3. Daarin wordt uitgegaan van een situatie waarin het ene productiehuis een interactieve quiz met enkele events heeft opgenomen en een ander een interactieve reclamespot. Elk programma heeft een eigen tijdsbasis voor de positionering van de events. De broadcaster wenst de quiz te onderbreken voor de commercial. In de figuur 1
Men kan de frames ook beschouwen als aparte sc`enes.
2.1 Eisen aan het raamwerk
11
is aangeduid wat er zou gebeuren mocht er voor beide programma’s een gemeenschappelijke tijdsbasis gehanteerd worden en de triggers niet aangepast worden. De events treden op op totaal verkeerde ogenblikken.
Interactieve quiz
0
3
commercial
NPT voor quiz contentID = 1
7
quiz, deel A
0 0
2
3 3
0
commercial
5
7
15
13 5 2
6
NPT voor commercial contentID = 2
quiz, deel B
5 0
2
7
6
NPT, niet gepauzeerd NPT contentID = 1 NPT contentID = 2
Figuur 2.3: Het gebruik van meerdere tijdsbases
Figuur 2.3 toont meteen ook een mogelijke oplossing. Op het ogenblik dat de commercial uitgezonden wordt, start men een nieuwe tijdsbasis. De tijdsbasis van de quiz wordt bevroren tot het einde van de commercial. Elke tijdsbasis krijgt een uniek nummer, het contentID. Dankzij de signalisatie (zie verder) zullen de NPT-waarden in de triggers dan verbonden kunnen worden met de juiste tijdsbasis. Het nesten van meerdere tijdsbases heeft dus voordelen voor de productiehuizen: de events en hun triggers kunnen ingebracht worden zonder te moeten rekening houden met andere programma’s. Ook de broadcaster kan zo flexibel programma’s onderbreken en na elkaar monteren zonder de triggers te moeten aanpassen.
2.1.4
Signalisatie
In dit hoofdstuk werden al heel wat vereisten voor het raamwerk ge¨ıdentificeerd. In het voorgaande werd echter doelbewust voorbijgegaan aan de vraag hoe de settop-box van de ontvanger precies ge¨ınformeerd wordt over al deze mogelijkheden. Zo kan men zich de vraag stellen hoe de settop-box weet welke events er kunnen optreden en welke NPT-tijdsbasis de verschillende events
2.1 Eisen aan het raamwerk
12
gebruiken. De triggers bevatten immers wel een NPT-waarde, maar geen contentID. Wanneer er meerdere tijdsbases ondersteund worden, moet het mogelijk zijn om ondubbelzinnig te bepalen op welke tijdsbasis de NPT-waarde in de trigger betrekking heeft. Het raamwerk zal dus een of andere vorm van signalisatie moeten voorzien, die de settop-box de nodige informatie verschaft over hoe de triggers in de Transport Stream moeten ge¨ınterpreteerd en verwerkt worden. In hoofdstuk 1 werd al aangehaald dat deze scriptie zich concentreert op de ontwikkeling van een triggermechanisme en niet op de definitie van een protocol om nieuwe applicaties te downloaden naar de settop-box. In wat volgt wordt daarom steeds uitgegaan van het model in figuur 1.1, waarbij er op de settop-box een of meer applicaties aanwezig zijn die de triggers correct kunnen interpreteren. Het raamwerk mag uiteraard geen beperkingen opleggen die het downloaden van nieuwe applicaties onmogelijk zou maken. Op het eerste zicht lijkt het voldoende dat elk event aangeduid wordt met een uniek nummer, een eventID. De triggers voor dat event bevatten dit nummer en aan de hand hiervan kan de middleware bepalen welk event er getriggerd wordt en voor welke applicatie(s) de trigger bestemd is2 . Bij de ontwikkeling van een nieuwe applicatie zal de programmeur onmogelijk kunnen voorspellen welke andere applicaties (met hun eigen events) er tegelijkertijd op de settop-box aanwezig zullen zijn. De kans is dan re¨eel dat twee applicaties dezelfde nummers gebruiken voor hun events. Om dit te vermijden, moet een extra vorm van signalisatie ge¨ıntroduceerd worden. Het lijkt beter om de events te kunnen onderscheiden op basis van een naam, eerder dan een nummer. Mits een doordachte naamkeuze3 kunnen zo conflicten tussen verschillende applicaties vermeden worden. De triggers zullen echter nog steeds enkel een nummer dragen. Met elke trigger een (lange) naam doorsturen is immers niet echt effici¨ent. De signalisatie zal daarom de ontvanger van de nodige informatie moeten voorzien om de identificatie tussen de naam en het nummer van een event mogelijk te maken. De toewijzing van de nummers kan dynamisch bij de broadcaster gebeuren, op basis van alle events die op dat ogenblik moeten gesignaleerd worden. Dit varieert immers doorheen de tijd. Samengevat omvat de signalisatie: events: de middleware op de settop-box moet een overzicht hebben van welke events er
kunnen optreden. De applicaties kunnen zich dan registreren bij de middleware om de 2 3
De applicaties registreren zich vooraf als zgn. listener voor de triggers bij de middleware. Men kan bv. het voorbeeld van de Java-packages overnemen, waarbij de naam telkens start met de url van
de website van de auteur.
2.2 Besluit
13
triggers voor die events te ontvangen. Elk event krijgt een uniek ID, het eventID. De triggers van dat event dragen eveneens dit eventID. Merk dus op dat de signalisatie geen uitsluitsel geeft over het karakter van een event (scheduled event of do-it-now), dit wordt enkel en alleen bepaald op basis van het type van de ontvangen triggers. Dit kwam reeds aan bod op het einde van paragraaf 2.1.2. naam-nummer omzetting: In de code van de applicaties wordt de naam gebruikt van
de events, de triggers bevatten enkel een nummer. De applicaties registeren zich op basis van de naam bij de middleware, die de vertaling maakt tussen eventID en naam. verschillende tijdsbases: Dit kwam reeds aan bod in de vorige paragraaf. Er kun-
nen verschillende tijdsbases tegelijk ondersteund worden. Uiteraard moeten deze allemaal gesignaleerd worden en een uniek contentID toegewezen krijgen.
2.1.5
Private data
De flexibiliteit van het raamwerk wordt sterk vergroot indien het mogelijk is om aan de triggers private data toe te voegen. Dit is data waarvan de syntax vrij te kiezen is. Op basis hiervan kan een event in verschillende vormen optreden. Als voorbeeld kan een voetbalwedstrijd beschouwd worden. Indien een doelpunt gescoord wordt, treedt het event “Update het scorebord” op. De trigger voor dit event geeft aan wanneer er een doelpunt gescoord wordt en er een update van het scorebord moet gebeuren. De private data bij die trigger specificeert dan wie er precies gescoord heeft. Uiteraard hadden ook twee aparte events (thuis- en uitdoelpunt) kunnen gedefinieerd worden, die dan elk hun eigen trigger zouden hebben. Het is duidelijker en eenvoudiger om slechts ´e´en event aan te maken en het eigenlijke gedrag ervan te sturen met de private data.
2.2
Besluit
In dit hoofdstuk werden allerlei opties opgesomd die het raamwerk zal moeten ondersteunen. Het Belgacom-netwerk legt enkele algemene randvoorwaarden op. Verder moeten er twee types van triggers voorzien worden. Bij scheduled events worden de triggers voorafgaand aan het event verstuurd, bij een do-it-now event treedt het event ogenblikkelijk op zodra de trigger gedetecteerd wordt.
2.2 Besluit
14
Het invoeren van scheduled events maakte duidelijk dat er voldoende tijdsinformatie moet voorzien worden in de videostroom. Omdat de System Time Clock in MPEG-2 niet voldoet, werd het concept van de Normal Playing Time ge¨ıntroduceerd. De NPT is een tijdsbasis die kan gepauzeerd worden, versneld oplopen, achteruit lopen... Op die manier kan een tijdsindicatie ondubbelzinnig verbonden worden met een videoframe. Bovendien is het mogelijk om meerdere tijdsbases te gebruiken, wat de onafhankelijke ontwikkeling van interactieve programma’s bevordert. Om al deze opties te ondersteunen, moet er voldoende signalisatie voorzien worden. Deze moet een overzicht bieden van de mogelijke events, een vertaling maken tussen het eventID en de naam van het event en ook de verschillende tijdsbases signaleren. Tot slot werd nog aangeduid dat de flexibiliteit van het raamwerk sterk toeneemt indien het mogelijk is om samen met de triggers private data mee te sturen. Op basis van deze private data kan de precieze manier waarop het event optreedt, gestuurd worden.
MPEG-2 TRANSPORT STREAM
15
Hoofdstuk 3
MPEG-2 Transport Stream Het acroniem MPEG staat voor Moving Picture Experts Group. Dit is een werkgroep binnen ISO/IEC die instaat voor het ontwikkelen van standaarden voor de codering en compressie van digitale audio en video. De laatste jaren is het belang van een goede compressie sterk toegenomen. Hierbij worden er steeds strengere eisen gesteld op het gebied van kwaliteit en compressie-effici¨entie. Deze twee eisen leiden tot tegengestelde voorwaarden. De gebruiker wenst immers een steeds betere kwaliteit van het aangeboden audiovisuele materiaal, zonder daarbij te maken te krijgen met lange wachttijden wegens de beperkte bandbreedte die hij ter beschikking heeft op het netwerk. Deze twee eisen weerspiegelen meteen ook de gebieden waarop een goede codec1 zich kan onderscheiden. De MPEG-2 standaard beantwoordt aan deze eisen en is op dit moment de de facto standaard in de digitale TV-wereld. MPEG-2 bestaat uit verschillende delen, waarvan de volgende 3 de belangrijkste zijn: Video: handelt over de decodering van de videobeelden en beschrijft een referentie-
decoder. De fabrikant van MPEG-2 compatibele apparatuur heeft de volledige vrijheid bij het ontwerp van een encoder, multiplexer... op voorwaarde dat de beschreven referentiedecoder de resulterende videostroom kan decoderen [5]. Audio: is het analogon van het deel Video, maar voor de audio [6]. Systems: beschrijft hoe de gecodeerde audio en video, volgens de principes uit de eerste
twee delen, moet opgeslagen worden op een digitale drager of verstuurd moet worden over een netwerk [4]. 1
COmpressor/DECompressor.
3.1 MPEG-2 Transport Stream
16
De standaard werd in de loop der jaren nog uitgebreid met enkele aanvullingen. In dit hoofdstuk wordt enkel een kort overzicht gegeven van het deel Systems [4]. Binnen het kader van deze scriptie heeft de precieze codering van de audio en de video geen belang, vermits er steeds zal vertrokken worden van een bestaande MPEG-2 videostroom. Het doel van dit hoofdstuk is de lezer voldoende technische achtergrondinformatie te geven over de MPEG-2 standaard om de volgende hoofdstukken en de daarin uiteengezette oplossing ten volle te begrijpen.
3.1
MPEG-2 Transport Stream
Een videostroom wordt typisch opgedeeld in pakketten alvorens hij verstuurd wordt over een netwerk. De manier waarop dit gebeurt, met name de lengte en indeling van de pakketten, kan echter drastisch verschillen naargelang de gevolgde standaard. In MPEG-2 wordt onderscheid gemaakt tussen twee fundamentele types van videostromen: de Program Stream (PS) en de Transport Stream (TS). Elk type werd ontworpen met een specifiek toepassingsgebied voor ogen. Een PS is geschikt voor gebruik in omgevingen die relatief weinig fouten introduceren. Het is o.a. het formaat waarin de data wordt weggeschreven op een DVD. De pakketten van een PS zijn variabel in lengte en kunnen vrij groot zijn. Een TS is daarentegen ontworpen voor gebruik in fout- en verliesgevoelige toepassingen. De TS wordt typisch gebruikt voor het versturen van audiovisuele data over een netwerk. De pakketten zijn vrij kort, omdat dit een effici¨entere foutcorrectie mogelijk maakt. Ze hebben een vaste lengte (188 byte), wat de verwerking door het netwerk vereenvoudigt. In de meeste digitale TV-netwerken, ook in dat van Belgacom, wordt de MPEG-2 Transport Stream aangewend. Andere toepassingen van de MPEG-2 TS zijn (vooralsnog) eerder beperkt. Er is dan ook weinig literatuur beschikbaar over het onderwerp. In [7] vindt de lezer evenwel een goed vertrekpunt.
3.1.1
Anatomie van een Transport Stream
Een TS komt in meerdere stappen tot stand, zoals ge¨ıllustreerd wordt in figuur 3.1. Men vertrekt steeds van een of meerdere elementary streams (ES). Een elementary stream is een zuivere datastroom die de output van een encoder vormt, en die conform de MPEG-2 standaard gecodeerde audio of video bevat. Elke elementary stream krijgt een eigen nummer, de Packet IDentifier
3.1 MPEG-2 Transport Stream
17
elementary stream
PES pakketten
audio encodering
packetiser
transport pakketten
mupitle lxer
video
Single Program Transport Stream
packetiser
Figuur 3.1: Van Elementary tot Transport Stream
(PID) 2 . Bij het coderen van een videofragment zullen typisch twee elementary streams geproduceerd worden: een met de gecodeerde audio en een met de gecodeerde video. Beide streams moeten op een of andere manier gesynchroniseerd worden, om zogenaamde lip sync, waarbij het geluid voor- of achterloopt op de beelden, te vermijden. Op deze synchronisatie wordt in paragraaf 3.1.3 dieper ingegaan. Het gegeven voorbeeld met twee elementary streams is niet beperkend. Een TV-programma kan bijvoorbeeld in verschillende talen uitgezonden worden. Elke taal vormt dan een aparte audio-elementary stream. Ook de verschillende mogelijke taalkeuzes bij een DVD steunen op dit principe3 . In de tweede stap worden de bitstromen van de elementary streams door een packetiser opgesplitst in pakketten. Zo wordt een packetised elementary stream (PES) bekomen. PES-pakketten hebben een variabele grootte, die bepaald wordt door de achterliggende codering van de audio en de video4 . Bovendien zijn PES-pakketten meestal te groot om te versturen over een fouten verliesgevoelig medium. Daarom worden de PES-pakketten door een tweede packetiser opgesplitst in kleinere transport pakketten met een vaste grootte van 188 byte5 . Elk pakket krijgt in zijn header de PID van de oorspronkelijke elementary stream. De transport pakketten van de 2 3
Er is evenwel slechts sprake van pakketten vanaf de volgende stap in het encodeerproces. Zoals vermeld, maakt een DVD gebruik van een Program Stream. Een Program Stream is eveneens opgebouwd
uit verschillende elementary streams. Het verschil tussen PS en TS wordt pas ge¨ıntroduceerd in een latere stap. 4 PES-pakketten vormen een logische opdeling: een pakket bevat het kleinst mogelijke datablok dat een zinvol geheel vormt, een zgn. Access Unit. Alle data van dit blok moet tegelijk gedecodeerd worden. Typisch bevat een Access Unit een audio- of videoframe. 5 Deze tweede opsplitsing gebeurt niet in een PS. Dit is dus het ogenblik waarop het verschil tussen TS en PS wordt ge¨ıntroduceerd.
3.1 MPEG-2 Transport Stream
18
verschillende elementary streams worden gemultiplexeerd en vormen zo een Transport Stream. Niet elke elementary stream zal een zelfde bitrate krijgen in de resulterende TS. Zo zullen er per tijdseenheid typisch veel meer video-pakketten dan audio-pakketten verstuurd worden. Een program of service wordt gedefinieerd als een verzameling van bij elkaar horende elementary streams. In het voorbeeld van een TV-programma in verschillende talen behoren de video-stream en de verschillende audio-streams tot dezelfde service. Het aantal elementary streams van zo’n service hoeft niet constant te zijn in de tijd. Blijven we in de sfeer van het gegeven voorbeeld, dan kan een videofragment bv. verschillende TV-programma’s bevatten, waarbij echter niet alle TV-programma’s in meerdere talen worden uitgezonden. De term program is dus geen synoniem voor een TV-programma en is daarom allicht een beetje ongelukkig gekozen. In wat volgt zal enkel de term service gehanteerd worden, als synoniem voor een TV-kanaal met meerdere TVprogramma’s. Als we al deze concepten concreet toepassen op de digitale TV-wereld, kunnen we stellen dat een TS alle gecodeerde video-, audio- en bijhorende controle-informatie (zie verderop) bevat die nodig is om bij de ontvanger ´e´en bepaalde TV-zender weer te geven. In de MPEG-2 standaard wordt gesproken over een Single Program Transport Stream (SPTS) [4]. Door twee of meer SPTS te multiplexeren wordt een Multi-Program Transport Stream (MPTS) bekomen. Deze MPTS bevat nog meer controle-informatie dan de SPTS.
3.1.2
Tables: orde in de chaos
De decoder heeft controle-informatie nodig over de verschillende elementary streams in de TS. Er zal dus een soort boekhouding moeten bijgehouden worden, die een overzicht geeft van de verschillende elementary streams en hun PID-nummer. Deze controle-informatie wordt verzonden onder de vorm van tables. De tabellen vormen, net zoals de audio en de video, een bitstroom en krijgen eveneens een PID-nummer toegewezen. In tegenstelling tot de elementary streams worden ze niet eerst opgesplitst in PES-pakketten, maar komen ze rechtstreeks in transport pakketten terecht. Als een tabel te groot is om in ´e´en transport pakket te passen, wordt ze opgesplitst in meerdere sections. Elke sectie wordt in een apart transport pakket verstuurd. In wat volgt worden enkel de twee tabellen besproken die het meest relevant zijn binnen het kader van dit afstudeerwerk. De belangrijkste tabel is de Program Association Table (PAT). Ze heeft altijd dezelfde PID (nl. 0x00) zodat een decoder zonder voorafgaande informatie deze tabel
3.1 MPEG-2 Transport Stream
19
kan terugvinden in de TS. Ze vormt dan ook het startpunt van de decodering. In de PAT staan de PID-nummers van een tweede tabel, de Program Map Table (PMT). Elke service in de TS heeft een eigen een PMT. In zo’n PMT staan de PID-nummers van de audio- en video-streams die samen de service uitmaken. We herinneren eraan dat een service een logische verzameling is van bij elkaar horende elementary streams. Dit afstudeerwerk behandelt enkel het geval van een SPTS. In dit verband is het belangrijk op te merken dat er in een SPTS wel degelijk een PAT aanwezig is, hoewel dit op het eerste zicht overbodig lijkt. Een SPTS bevat immers maar 1 service en in de PMT is dus voldoende informatie aanwezig voor de decodering. De standaard wenst echter de uniformiteit te bewaren tussen MPTS en SPTS, zodat ook in deze laatste een PAT wordt opgenomen. Een overzicht van de samenhang tussen de tabellen wordt gegeven in figuur 3.2.
Service 1
Transport Stream
PAT 0x00
PMT 0x20
PCR 0x67 video 0x67 audio 0x145
PAT - 0x00 video/PCR - 0x11 Service 2
PMT - 0x20 video/PCR - 0x67
PMT 0x123
audio - 0x88 PMT - 0x123 audio - 0x145
PCR 0x11 video 0x11 audio 0x88
Figuur 3.2: Tabellen in de Multi-Program Transport Stream
Op de figuur zijn de verschillende elementary streams van een TS te vinden. Op PID = 0 vinden we de Program Association Table. In deze PAT vinden we twee verwijzingen terug naar PMT’s. Deze TS is dus een Multi-Program Transport Stream, die bestaat uit twee services. De PMT van elke service geeft de PID-nummers van de audio en de video aan, alsook de PID van de PCR. Hiervoor verwijzen we naar de volgende paragraaf.
3.1 MPEG-2 Transport Stream
3.1.3
20
Timing en synchronisatie
In paragraaf 3.1.1 werd reeds aangehaald dat het mogelijk moet zijn om verschillende elementary streams te synchroniseren. Typisch wordt hierbij gedacht aan de synchronisatie van audio en video. In de TS wordt daarom uitgebreide tijdsinformatie meegestuurd, teneinde de decoder in staat te stellen om de data correct te verwerken. In wat volgt zal enkel ingegaan worden op de details die relevant zijn voor dit afstudeerwerk. Het is daarbij verhelderend om eerst even de problemen te belichten die optreden op het gebied van timing bij het versturen van een datastroom over een netwerk. We zullen daarbij het pad van de datastroom volgen van encoder tot decoder. De audio en de video worden elk door een encoder gecodeerd. Zoals figuur 3.1 toonde, genereert elke encoder een elementary stream, die wordt gebufferd en in pakketten wordt gesplitst. Deze pakketten worden daarna gemultiplexeerd met die van de andere elementary streams en vormen zo een TS. Een multiplexering is eigenlijk een serieel-parallel omzetting. Op die manier komen audio- en videodata die tegelijk moeten weergegeven worden, toch op verschillende ogenblikken in de TS terecht. Bovendien kunnen de buffers nog extra verschil introduceren: de verblijfstijd van de data in de buffer kan immers vari¨eren doorheen het encoderingsproces en tussen de verschillende buffers onderling. In een digitaal TV-netwerk wordt de datastroom gestreamd over het netwerk. Eerst het volledige programma downloaden op de settop-box om het dan te bekijken, is uiteraard geen optie. Het netwerk introduceert dus een bijkomende vertraging, die bovendien variabel is in de tijd. Eventueel kunnen de pakketten zelfs in de verkeerde volgorde arriveren bij de decoder. De decoder moet over voldoende informatie beschikken zodat hij voor elk pakket kan bepalen wanneer (en hoe) het moet gedecodeerd en weergegeven worden. Uit de voorgaande bespreking is gebleken dat het tijdstip van aankomst absoluut geen indicatie kan zijn voor het ogenblik van decodering en weergave. Daarom worden door de encoder in de header van elk (PES-)pakket zogenaamde tijdsstempels geplaatst6 . Deze tijdsstempels worden afgeleid van de interne klok van de encoder, de System Time Clock. Er zijn twee stempels: de Decoding Time Stamp (DTS) en de Presentation Time Stamp (PTS), die respectievelijk het tijdstip van decodering en weergave aangeven voor het corresponderende PES-pakket. Pakketten die tegelijk moeten weergegeven 6
Een PES-pakket, evt. opgesplitst over meerdere transport pakketten, bevat immers data die tegelijk moet
weergegeven worden, zoals een audio- of video-frame. E´en tijdsstempel voor het volledige PES-pakket volstaat, zodat niet in elk transport pakket een tijdsstempel zal voorkomen.
3.1 MPEG-2 Transport Stream
21
worden, bv. een pakket met audio en ´e´en met video, zullen dezelfde (decodeer)tijdsstempel dragen. Zo wordt de synchronisatie bij de weergave gegarandeerd. Opdat de decoder de tijdsstempels correct zou interpreteren, moet zijn interne klok gesynchroniseerd worden met die van de encoder. Om die reden wordt er nog een derde tijdsindicatie meegestuurd in de TS: de Program Clock Reference (PCR). Net zoals de DTS en de PTS is ook de PCR een soort momentopname van de STC van de encoder. De PCR wordt periodiek verzonden (minstens eenmaal per 0.1 s) in een apart veld in een transport pakket. Bij ontvangst van het eerste transport pakket van de stream zal de decoder zijn interne klok gelijk zetten met de waarde van de PCR. In het ideale geval komen de volgende transport pakketten dan aan op het ogenblik dat de interne klok van de decoder de waarde aangeeft die als PCR is opgenomen in het ontvangen pakket. Indien dit niet zo is, spreekt men over jitter. Als gevolg hiervan kan de ontvangstbuffer onder- of overlopen, met storing van het beeld tot gevolg. Eventueel zal de decoderklok aangepast worden. In de Program Map Table staat het PID-nummer vermeld van de transport pakketten die een PCR bevatten7 .
3.1.4
Private Sections: transporteren van data
Er werd al kort vermeld dat de tabellen met de controle-informatie opgesplitst worden in een of meerdere sections, die in aparte transport pakketten verstuurd worden. Dit principe wordt in de MPEG-2 standaard verder uitgebreid met private sections, zodat het mogelijk is om private data te versturen. Onder private data worden alle extra data verstaan die geen gecodeerde audio of video voorstellen. Dit sluit aan bij de definitie gegeven in paragraaf 2.1.5, vermits de codering van de private data vrij kan gekozen worden. We merken hierbij op dat de PAT en de PMT eigenlijk ook een soort private data zijn. De private section heeft een eigen syntax, die opgenomen werd in bijlage A. Deze private section zal voor dit afstudeerwerk van groot belang blijken te zijn. 7
De transport pakketten met een PCR vormen echter geen aparte elementary stream. Typisch wordt de PCR
meegestuurd in elk pakket met video-data. Dit werd ook getoond in figuur 3.2: de PID van de PCR is dezelfde als de PID van de elementary stream met de video.
3.2 Besluit
3.2
22
Besluit
De MPEG2-standaard [4, 5, 6] is een heel performante standaard voor audio- en videocodering. In dit hoofdstuk werden de belangrijkste zaken uit de standaard voor dit afstudeerwerk kort toegelicht. Een Single Program Transport Stream is opgebouwd uit meerdere elementary streams, die elk een eigen PID-nummer hebben. Deze elementary streams worden opgesplitst in transport pakketten en verstuurd over het netwerk. De “boekhouding” van de TS wordt gedaan met tabellen, meer bepaald de Program Association Table en de Program Map Table. De PAT bevat de PID-nummers van de PMT van elke service in de TS. De PAT zelf heeft altijd PID = 0 en vormt het startpunt van de decodering. Een service (of program) is een logische verzameling van bij elkaar horende elementary streams en in de PMT staan de PID-nummers van de elementary streams die er deel van uitmaken. Een tabel bestaat uit een of meerdere secties, waarbij elke sectie verstuurd wordt in een apart transport pakket. In de MPEG-2 standaard is het bovendien mogelijk om via zgn. private sections ook private data op te nemen in de TS. Verder in dit afstudeerwerk zal van deze mogelijkheid uitgebreid gebruik worden gemaakt.
HET MULTIMEDIA HOME PLATFORM
23
Hoofdstuk 4
Het Multimedia Home Platform De ontwikkeling van een volledig nieuw raamwerk voor het triggeren van events is een veelzijdige opdracht die slechts verantwoord kan worden indien de bestaande oplossingen niet voldoen aan de eisen uit hoofdstuk 2. Een grondige en kritische evaluatie van alle beschikbare alternatieven dringt zich op. Hoewel de digitale TV-revolutie nog volop aan de gang is, zijn er toch al heel wat middleware-platformen voor settop-boxen ontwikkeld, elk met een eigen triggermechanisme. Een ervan is het Multimedia Home Platform (MHP) [8]. Dit is een open standaard voor middleware die ontwikkeld werd door het Digital Video Broadcasting Project (DVB) [9]. DVB is een vereniging van fabrikanten, TV-broadcasters, netwerkoperatoren en software-ontwikkelaars die als doel heeft om globale standaarden vast te leggen voor de digitale TV-wereld. Op deze manier hoopt men een horizontaal marktmodel te introduceren, met verschillende spelers (concurrenten) in elke schakel van de keten tussen de opname van het programma en de weergave op het TV-toestel. Er zijn standaarden die de transmisie, signalisatie en modulatie van TVsignalen over een specifiek medium behandelen: DVB-C voor kabel [10], DVB-S voor satelliet [11], DVB-H voor mobiele (handheld ) toestellen [12], DVB-IPI voor IP-gebaseerde netwerken [13]... Daarnaast worden er ook standaarden gepubliceerd op andere gebieden zoals teletekst [14] en ondertiteling [15]. Met het Multimedia Home Platform wou de DVB-groep een open-source middleware op de markt brengen, in de hoop om zo ook op dit vlak een horizontaal marktmodel te kunnen invoeren. Naast MHP zijn er nog veel andere middleware-platformen op de markt. Myrio [16], MediaHighway [17], Liberate [18], OpenTV [19]... zijn slechts enkele van de talloze voorbeelden. Hoewel sommige van deze platformen ook (gedeeltelijke) MHP-compatibiliteit claimen, zijn ze
4.1 Wat is MHP?
24
allemaal closed-source en dus niet geschikt voor een grondige evaluatie. MHP is de enige open standaard voor middleware op de digitale TV-markt, wat rechtvaardigt waarom er een volledig hoofdstuk aan wordt gewijd. Het is niet de bedoeling om alle details van MHP te behandelen. Er zal enkel een globaal beeld geschetst worden, met bijzondere aandacht voor de gelaagde structuur van het platform. De ge¨ınteresseerde lezer wordt voor een grondigere behandeling verwezen naar [20]. Het carrouselprincipe, een belangrijk concept om extra data samen met de video en de audio te transporteren, en de Normal Playing Time worden wel uitgebreider belicht, vermits ze beide een belangrijke rol spelen in het triggermechanisme van MHP. Daarna wordt ingezoomd op het eigenlijke triggermechanisme. Uiteindelijk zal blijken dat MHP niet voldoet aan alle eisen die geformuleerd werden in hoofdstuk 2.
4.1
Wat is MHP?
Middleware vervult een intermedi¨erende rol tussen het besturingssysteem van een settop-box en de eigenlijke applicaties. De toepassingen worden door de middleware losgekoppeld van de details van de hard- en software van de terminals waarop ze draaien. Ontwikkelaars hoeven op die manier niet voor elk type settop-box een andere applicatie te bouwen. Dit horizontaal marktmodel vereist wel dat de specificaties van de middleware publiek beschikbaar zijn: alleen op die manier weten de fabrikanten hoe ze de middleware moeten bouwen, en de ontwikkelaars van de applicaties hoe ze de middleware kunnen aanspreken. Naast deze intermedi¨erende functie, zorgt de middleware er ook voor dat twee of meer applicaties, die op zich zelfstandige programma’s vormen, met elkaar kunnen communiceren. Dit werd reeds getoond in figuur 1.1. De kern van MHP bestaat uit de DVB-J, een Java Virtual Machine die door de DVB-groep aangepast en uitgebreid werd voor de digitale TV-wereld [8]. De keuze voor Java werd ongetwijfeld be¨ınvloed door de wens tot platformonafhankelijkheid. Zoals figuur 4.1 toont, heeft men rond deze DVB-J heel wat Application Programming Interfaces (API’s) gedefinieerd, waar de MHP-applicaties (geschreven in Java1 ) gebruik kunnen van maken. Deze API’s bestaan uit een verzameling functies waarvan enkel de syntax door de standaard wordt vastgelegd. De concrete implementatie wordt overgelaten aan de fabrikant die het MHP-platform in zijn settop-box 1
In paragraaf 4.1.2 zal uiteengezet worden dat er ook HTML-applicaties zijn. Deze maken eveneens gebruik
van de DVB-J.
4.1 Wat is MHP?
25
applicaties
ss
DVB-J Virtual Machine an
de
re
S
ec u
rit y
e Ja va
ac ce AP I
n a tiv
d a ta
A PI
presentation API
AP I
Figuur 4.1: Enkele van de API’s gedefinieerd rond de DVB-J
wenst op te nemen. De ontwikkelaar van nieuwe toepassingen hoeft zich hierover geen zorgen te maken en weet welke functies hij via welke methode-oproep kan aanspreken. Zijn applicatie zal werken op elke settop-box met MHP-middleware. Verder werden in MHP voorzieningen getroffen om nieuwe applicaties op de settop-box te kunnen downloaden. De functionaliteit van de settop-box wordt zo niet beperkt tot de toepassingen die erop aanwezig zijn bij het verlaten van de fabriek en kan dus later nog uitgebreid worden.
4.1.1
De gelaagde MHP-structuur
De functie van MHP als middleware komt nog sterker naar voor indien we de gelaagde structuur van het platform bekijken. Figuur 4.2 toont hoe MHP gezien wordt als een verbinding tussen de twee bovenste lagen van een drielagige structuur, nl. de toepassingen en het besturingssysteem van de settop-box. Via de gestandaardiseerde (en publieke) MHP-interface kunnen de applicaties toegang krijgen tot de systeemsoftware. De DVB-J zorgt voor de correcte omzetting van de functie-oproepen naar specifieke instructies voor het besturingssysteem. De drie lagen zijn: Resources: omvat alle bronnen van de settop-box, typisch hardware-componenten. Voor-
beelden zijn de MPEG-2 decoder, het geheugen, I/O apparaten en de eventuele harde schijf van de settop-box. System Software: het besturingssysteem van de settop-box. Deze beheert alle bronnen
van de settop-box en abstraheert ze voor de bovenliggende laag. In deze laag bevindt zich
4.1 Wat is MHP?
26
Application layer
Application
Application
Application
MHP System Software layer
Resource layer
DVB-J
System Software
Application Manager
MPEG-2 decoder geheugen
Resources
graphics input/output
broadcast channel interaction channel remote
screen
Figuur 4.2: MHP in het drielagig model
ook de DVB-J. Verder is er een Application Manager aanwezig. Deze staat in voor het beheer van alle applicaties op de settop-box, wijst hen de nodige bronnen toe en maakt ze opnieuw vrij wanneer een applicatie afgesloten wordt. Applications: dit zijn de applicaties die gebruik maken van de MHP-API’s.
In figuur 4.2 zijn ook de verbindingen met buitenwereld aangegeven. Er zijn zowel uni- als bidirectionele verbindingen. Het broadcast channel is unidirectioneel en is het kanaal langswaar de TV-programma’s (of applicaties en hun triggers, zie paragraaf 4.1.3) de settop-box bereiken. Het interaction channel of terugkeerkanaal is bidirectioneel en kan dus zowel gebruikt worden om gegevens op de settop-box te downloaden als om gegevens van de gebruiker/TV-kijker terug te sturen naar de broadcaster. Tot slot zijn er nog twee unidirectionele kanalen, screen en remote control, waarvan de naam voor zich spreekt. We merken nog op dat de gebruiker via zijn afstandsbediening eventueel kan reageren op applicaties (cfr. het voorbeeld van de interactieve quiz uit hoofdstuk 1).
4.1.2
MHP-applicaties
Alle MHP-applicaties worden beheerd door de Application Manager, die zich situeert in de System Software-laag. Deze Manager is verantwoordelijk voor het opstarten en afsluiten van de applicaties en het verdelen van de beschikbare bronnen. MHP-applicaties kunnen op twee
4.1 Wat is MHP?
27
manieren ontwikkeld worden. Een eerste groep zijn de applicaties in DVB-HTML. Ze bestaan uit een aantal met elkaar verbonden pagina’s die opgemaakt zijn in X-HTML [21], de XML-versie van HTML. Daarnaast maken deze applicaties gebruik van Cascading Style Sheets [22], voor het formaat en de lay-out van de HTML-pagina’s, en ECMAScript [23], de gestandaardiseerde versie van JavaScript. Figuur 4.3 toont de twee manieren waarop deze applicaties kunnen weergegeven worden. De X-HTML code wordt ofwel rechtstreeks in de browser op de settop-box weergegeven, ofwel wordt ze eerst door de server omgezet in Java-code voor de DVB-J.
head-end (server)
X-HTML
settop-box
browser
DVB-J Virtual Machine
head-end (server)
X-HTML
settop-box
convertor Java code
DVB-J Virtual Machine
Figuur 4.3: Twee manieren om DVB-HTML applicaties weer te geven
Ten tweede zijn er de applicaties die geschreven zijn in Java. Omdat MHP eigenlijk een uitbreiding vormt van JavaTV2 , worden deze applicaties XLet’s genoemd. Een XLet is het JavaTVanalogon voor een applet in een webpagina. Net zoals een applet doorlopen ze tijdens hun levenscyclus verschillende toestanden. De overgang van de ene naar de andere toestand wordt geregeld door de Application Manager. Figuur 4.4 toont de mogelijke overgangen tussen de verschillende toestanden en de functies die de Application Manager hiervoor moet oproepen. Tot op de dag van vandaag wordt het grootste gedeelte van de applicaties nog steeds geschreven in Java. Toch winnen de toepassingen in HTML langzaam maar zeker veld, zeker bij de operatoren die TV over een IP-netwerk wensen aan te bieden. Niet alleen heeft HTML zijn compatibiliteit op een IP-netwerk reeds overvloedig bewezen, op hun settop-box is bovendien al een browser aanwezig die HTML-code probleemloos kan interpreteren. Verder blijkt voor sommige applicaties HTML een eenvoudigere keuze te zijn dan Java. Een typisch voorbeeld is de elektronische programmagids, die bestaat uit een aantal pagina’s waartussen gebladerd wordt. De analogie met het surfen op een website (in HTML) ligt voor de hand. Anderzijds kan 2
JavaTV [24] is de oplossing van Sun voor een digitaal TV-platform. Toch blijken enkele essenti¨ele zaken voor
de broadcast-wereld niet, of niet rechtstreeks, ondersteund te worden. Het belangrijkste voorbeeld is ongetwijfeld het ontbreken van een carrouselsysteem.
4.1 Wat is MHP?
28
loaded
destroyXLet()
startXLet()
initXLet()
initialised
started
destroyed
pauseXLet()
Figuur 4.4: Het toestandsdiagram van een XLet
men zich de vraag stellen of een statische taal zoals HTML wel voldoende performant is voor complexere applicaties. De toekomst zal duidelijk moeten maken of een type de overhand zal halen, of integendeel beide types complementair naast elkaar zullen blijven bestaan.
4.1.3
Het carrouselprincipe
Naast de talrijke API’s om applicaties te bouwen, voorziet MHP ook in een uitgebreid mechanisme om extra data en zelfs volledige applicaties te downloaden naar de settop-box. Het maakt hierbij gebruik van een zgn. carrousel3 , waarin de bestanden met de informatie sequentieel en op periodieke basis verstuurd worden. Elke periode worden dezelfde bestanden ´e´en na ´e´en verstuurd. De inhoud van de carrousel kan wijzigen in de tijd, maar de bestanden blijven typisch vele perioden lang in de carrousel. De kijker die een bepaald bestand opvraagt, moet dus wachten op de volgende “passage” van het deel van de carrousel met dit bestand. Het schoolvoorbeeld van een carrousel is teletekst. Als een gebruiker een pagina wenst te raadplegen, moet hij even wachten. Pas bij de eerstvolgende verzending kan de pagina weergegeven worden. De wachttijd (latency) die zo ontstaat is onvermijdelijk bij een carrousel, maar kan beperkt worden voor veelgevraagde pagina’s door deze meermaals per carrouselperiode te versturen. Bij teletekst zal dit bijvoorbeeld het geval zijn voor de pagina met nummer 100, het startpunt voor iedereen die teletekst raadpleegt. In figuur 4.5 wordt het carrouselprincipe en het ontstaan van wachttijden visueel voorgesteld. Elke pagina wordt ´e´en maal per periode verstuurd. De gebruiker wenst pagina 750 te raadplegen. Op dat ogenblik wordt echter pagina 500 doorgestuurd, zodat hij even moet wachten. In het slechtste geval moet de gebruiker precies ´e´en 3
In de tekst worden de Nederlandse en Engelse spellingswijze voor het woord carrousel door elkaar gebruikt.
De Engelse spelling wordt enkel gehanteerd voor specifieke termen.
4.1 Wat is MHP?
29
200
100
300
900
tijd 400
800 500 700
600
huidige ontvangen pagina
Wachttijd voor pagina 750
Figuur 4.5: Het carrouselprincipe en het ontstaan van wachttijden
periode wachten. In de figuur zou dit het geval geweest zijn indien men pagina 499 had opgevraagd. Zoals gezegd kan de maximale wachttijd voor een bepaalde pagina verminderd worden door ze meermaals per periode te verzenden. Dit vergroot dan wel de periode van de carrousel. De carrousel ontstond in de unidirectionele broadcast-wereld, waar er enkel een kanaal is om informatie te versturen van broadcaster naar TV-kijker, maar niet omgekeerd. Omdat er geen kanaal is om verzoeken te versturen naar de broadcaster is het uiteraard onmogelijk dat de gebruiker expliciet informatie opvraagt bij de broadcaster. Hij moet genoegen nemen met hetgeen de broadcaster doorstuurt. Veronderstel nu dat een TV-programma gebruik maakt van een nieuwe applicatie. Die moet dus eerst gedownload worden naar de settop-box. De broadcaster kan autonoom beslissen om alle bestanden van deze applicatie door te sturen (push-model ). De applicatie wordt automatisch opgeslagen in het cache-geheugen van de settop-box. De kijkers die pas overschakelen naar dat TV-kanaal nadat de applicatie is verstuurd, hebben die echter niet ontvangen. Bovendien kunnen ze geen expliciet verzoek voor een retransmissie naar de broadcaster sturen. De broadcaster kan deze situatie vermijden door de applicatie op regelmatige basis opnieuw te verzenden. Door de beperkte bandbreedte is het echter onmogelijk om alle bestanden tegelijk te versturen. Het carrouselprincipe, het herhaaldelijk doorsturen van in delen opgesplitste informatie, komt zo automatisch naar voor. De pas overgeschakelde TV-kijkers moeten dan enkel wachten op de volgende carrouselperiode alvorens ze kunnen genieten van de nieuwe applicatie.
4.2 Triggeren van events met MHP
4.2
30
Triggeren van events met MHP
MHP heeft zijn triggermechanisme grotendeels overgenomen uit de DSM-CC standaard [25]. Er wordt daarom gestart met een bespreking van deze standaard. Vervolgens worden twee aspecten belicht die van belang zijn voor de triggering: de Object Carousel en de Normal Playing Time. In een vierde paragraaf wordt het eigenlijke triggermechanisme besproken, waarna een voorbeeld wordt gegeven om alles te concretiseren. Er zal daarbij uitgebreid gebruik gemaakt worden van de begrippen en structuren die in de eerste drie paragrafen werden ge¨ıntroduceerd.
4.2.1
De basis: DSM-CC
DSM-CC staat voor Digital Storage Media - Command and Control en is een ISO/IEC-standaard [25] die ontwikkeld werd voor het toeleveren van multimediale breedbanddiensten. Een eerste versie ervan vormde slechts een annex bij de MPEG-2 standaard [4], waarin een simpel protocol werd opgebouwd voor het streamen van Transport Streams. DSM-CC is echter verder ge¨evolueerd tot een apart deel van MPEG-2 [25] en beschrijft nu de nodige protocollen voor volwaardige diensten zoals Video On Demand of Home Shopping. Het resultaat is overigens een heel complexe en moeilijk te doorgronden standaard. Een introductie kan gevonden worden in [26, 27]. Het functioneel model van DSM-CC wordt weergegeven in figuur 4.6 en gaat uit van een client-
User-Network Connection User-User Connection
Computer
client
Server server
NETWERK Computer
client
Computer Server server
client
Figuur 4.6: Het client-server model van DSM-CC
4.2 Triggeren van events met MHP
31
server model. Servers en clients zijn beide gebruikers van een netwerk dat communicatie tussen hen mogelijk maakt. Clients consumeren multimediale data en maken gebruik van de diensten die aangeboden worden door de servers. Alle communicatie gebeurt onder de vorm van boodschappen, zowel om de nodige verbindingen op te zetten als voor het eigenlijke transport van de data. Men onderscheidt DSM-CC User-User en User-Network boodschappen. Het onderliggende transportprotocol is hierbij niet van belang. DSM-CC is compatibel met uiteenlopende types transportnetwerken, gaande van een puur MPEG-2 TS-netwerk, over een ATM4 -netwerk met een willekeurig access network tot een volledig ATM end-to-end netwerk. Eens de connectie tussen server en client opgezet is, kan de multimediale data gedownload worden van de server. De data wordt hiervoor opgesplitst in modules, die op hun beurt ingedeeld worden in blokken. Dit komt verder nog terug bij de bespreking van figuur 4.7. De grootte van de blokken wordt vooraf onderhandeld tussen client en server. Elk blok wordt verstuurd in een aparte boodschap, een Download Data Message. Tijdens het downloaden worden verder nog Download Control Messages met de nodige controle-informatie uitgewisseld. DSM-CC ondersteunt twee downloadmechanismes. Enerzijds is er de traditionele interactieve download, waarbij de client op regelmatige tijdstippen bevestigingen stuurt naar de server dat hij de data correct heeft ontvangen. Anderzijds wordt er een downloadprotocol voorzien voor situaties waarin er enkel een unidirectioneel kanaal van server naar client is en de gebruiker geen bevestigingen kan terugsturen. Dit tweede protocol, de DSM-CC Data Carousel, is een concrete implementatie van het in paragraaf 4.1.3 uiteengezette carrouselprincipe. De blokken, verpakt in een Download Data Message, worden op de carrousel geplaatst en Download Control Messages zorgen er dan voor dat de ontvanger over voldoende informatie beschikt om de inhoud van de carrousel correct te interpreteren.
4.2.2
De Object Carousel
De Object Carousel (OC) vormt een verdere uitbreiding van de Data Carousel. De OC biedt extra functionaliteit aan om gemakkelijker een groep bestanden gestructureerd te ordenen, zo is het o.a. mogelijk om de bestanden te organiseren in een directorystructuur. Op deze manier vormt de OC een soort extra (weliswaar read-only) data-opslagmedium, dat gemount wordt in de directorystructuur van de settop-box. 4
Asynchronous Transfer Mode.
4.2 Triggeren van events met MHP
32
De Object Carousel bevat enkel objecten van ´e´en van de vijf volgende types: Directory Object: bevat de nodige informatie omtrent de directorystructuur van de
bestanden in de carrousel. ServiceGateway Object: is een speciaal Directory Object. Het bevat de rootdirectory
van de directorystructuur. File Object: een object dat een bestand bevat. Stream Object: geeft informatie over andere elementary streams in de Transport Stream.
Het geeft bijvoorbeeld de elementary stream aan die de informatie over de Normal Playing Time bevat. Dit wordt verder nog behandeld in paragraaf 4.2.3. Stream Event Object: geeft informatie over de mogelijke events die kunnen optreden.
Dit object wordt in paragraaf 4.2.4 in detail besproken.
Het transport van een Object Carousel in een Transport Stream De Object Carousel verstuurt meerdere objecten op een periodieke wijze. In deze paragraaf gaan we dieper in op hoe deze objecten een plaats krijgen in een Transport Stream. Zoals reeds aangehaald, vormde DSM-CC oorspronkelijk een deel van de MPEG-2 TS standaard en is hij dus geoptimaliseerd voor het transport in een TS. Vooraleer een object verstuurd wordt, worden er tal van headers aan toegevoegd. Een overzicht wordt gegeven in figuur 4.7. In deze figuur zien we duidelijk de hi¨erarchie waarin de Object Carousel gedefinieerd werd als een laag bovenop de Data Carousel. Een object wordt verpakt in een BIOP-boodschap5 . Verschillende BIOP-boodschappen samen vormen een module van de Data Carousel. Deze modules zijn enkel logische indelingen, maar kunnen een belangrijke invloed hebben op de performantie. Het cache-geheugen van de settopbox slaat steeds volledige modules op, ook al is er slechts ´e´en object opgevraagd. Het is dus nuttig om bestanden die samen gebruikt worden in dezelfde module te stoppen. De modules worden voor de verzending opgesplitst in de hoger reeds genoemde blocks. Elk block krijgt een header en vormt zo een Download Data Block Message. Elk van die berichten wordt verstuurd in een zogenaamde DSM-CC section. Deze section is een private section uit de MPEG-2 standaard, zoals besproken in paragraaf 3.1.4, maar waarvan de syntax nog met enkele extra velden 5
Broadcast Inter-ORB Protocol, een eigen specificatie uit DSM-CC consistent met ORB [28].
4.2 Triggeren van events met MHP
Obj 1 (Directory)
Object Carousel BIOP Message
33
Obj 2 (Stream Event)
Download Data Carousel
Obj 3 (File)
Module
Modules & Blocks BLOCK
DSM-CC sections
SECTION 1
transport pakketten
BLOCK
SECTION 2
BLOCK
SECTION 3
BLOCK
SECTION 4
SECTION 5
stuffing bytes
Figuur 4.7: De verschillende stappen om een Object te versturen
is uitgebreid. Tot slot worden transport pakketten opgevuld met ´e´en of meerdere DSM-CC Sections, eventueel aangevuld met stuffing bytes aangezien de transport pakketten een vaste grootte hebben. De Object Carousel vormt dus eigenlijk een datastroom die, net zoals de encoders, transport pakketten genereert. Deze pakketten worden ten slotte gemultiplexeerd met de (audio- en video-)pakketten. Ze hebben een eigen PID-nummer, dat opgenomen wordt in de Program Map Table. Dit verzekert een correcte interpretatie door de ontvanger.
4.2.3
Normal Playing Time
In hoofdstuk 2 werd uitvoerig het concept van een tijdsbasis uiteengezet die, net zoals de timer op een videotoestel, kan gepauzeerd en door- en teruggespoeld worden. Zonder in te gaan op de oorsprong ervan hebben we zo’n tijdsbasis toen Normal Playing Time gedoopt. De term NPT is afkomstig uit de DSM-CC standaard [25] en wordt daarin als volgt omschreven: Intuitively NPT is the clock a viewer associates with a program. It is often digitally displayed on a VCR. De NPT in DSM-CC werd in de eerste plaats ontwikkeld om ondersteuning te bieden voor het streamen van een video over het netwerk. DSM-CC geeft nl. aan de gebruiker de mogelijkheid om deze video te pauzeren en terug- of door te spoelen. In paragraaf 2.1.3 werd aangetoond dat
4.2 Triggeren van events met MHP
34
een tijdsbasis zoals de NPT ook nuttig (en overigens noodzakelijk) is bij de implementatie van een triggermechanisme. MHP heeft de NPT daarom overgenomen als tijdsbasis om de events in de tijd te kunnen positioneren. De ontvanger beschikt over de correcte NPT omdat er zgn. NPT-descriptors worden verstuurd in de Transport Stream. In paragraaf 3.1.3 werd de System Time Clock besproken. Dit is de klok die gebruikt wordt door de ontvanger om de tijdstippen van decodering en weergave te bepalen. De codering van de NPT gebeurt op basis van deze STC. In de NPT-descriptor worden hiervoor twee velden voorzien. Het eerste veld bevat de waarde van de NPT op het ogenblik dat de STC van de ontvanger de waarde aanneemt die in het tweede veld is aangegeven. Naast deze twee velden bevat de NPT-descriptor ook nog de verhouding waarmee de NPT oploopt t.o.v. de STC, deze kan zowel positief, negatief als nul zijn. Bij een waarde nul is de NPT gepauzeerd, een negatieve verhouding geeft aan dat er teruggespoeld wordt. Op basis van de coderingen in de ontvangen NPT-descriptoren kan de klok indien nodig bijgestuurd worden. De descriptor bevat tot slot ook nog een veld voor het contentID, dat aangeeft welke tijdsbasis deze descriptor behandelt. Het is dus mogelijk om meerdere tijdsbases tegelijk te ondersteunen.
4.2.4
Het samenspel van Stream Event Objects en Stream Event Descriptors
In deze paragraaf wordt het eigenlijke triggermechanisme van MHP belicht. In figuur 4.1 werd de relevante API, nl. de Data Access API, reeds aangegeven. In de onderstaande discussie zal er evenwel enkel ingegaan worden op het onderliggende principe en niet op de eigenlijke syntax van de functie-aanroepen. Die biedt immers geen nieuwe inzichten die relevant zijn binnen het kader van deze scriptie. De triggering van events wordt verwezenlijkt door een combinatie van Stream Event Descriptors en Stream Event Objects. Die laatste is ´e´en van de vijf mogelijke types objecten in de Object Carousel. Beide structuren worden besproken in de volgende paragrafen. De reeds hoger ingevoerde concepten van de Object Carousel en de NPT-descriptor zullen bij de bespreking opnieuw aan bod komen. In figuur 4.8 op pagina 37 wordt een handig overzicht gegegeven van alle begrippen uit de twee volgende paragrafen.
4.2 Triggeren van events met MHP
35
Stream Event Objects Deze objecten worden verstuurd in de Object Carousel en bevatten drie belangrijke zaken. Ten eerste is er een lijst met events die mogelijk kunnen optreden. Elk event wordt gekenmerkt door een naam en heeft een uniek identificatienummer, het eventID. De applicaties op de settop-box registreren zich voor het event via deze naam. Het eventID wordt gebruikt door de Stream Event Descriptors, die in de volgende paragraaf besproken worden. MHP laat op deze manier een dynamische koppeling toe tussen de naam en een uniek identificatienummer van een event. Deze extra vorm van flexibiliteit kwam al aan bod in de analyse van paragraaf 2.1.4. Ten tweede bevat een Stream Event Object ´e´en (en maximum ´e´en) verwijzing6 naar de elementary stream die de NPT-tijdsbasis bevat die door alle events in de lijst gebruikt wordt. Die elementary stream bevat m.a.w. de NPT-descriptoren van die tijdsbasis, zoals besproken in paragraaf 4.2.3. Het feit dat alle events in de lijst dezelfde tijdsbasis gebruiken, kan een ernstige restrictie lijken. NPT biedt immers de mogelijkheid om meerdere tijdsbases tegelijk te signaleren. Dit is voordelig voor het triggermechanisme, zoals getoond werd in figuur 2.3. De restrictie tot ´e´en tijdsbasis per Stream Event Object (SE Object) moet evenwel gezien worden in het kader van de toepassing waarvoor DSM-CC origineel ontwikkeld is7 , nl. het transporteren van een stream van server naar client. Een stream wordt hierbij beschouwd als een blok audiovisuele data dat samenhoort en dus slechts ´e´en tijdsbasis nodig heeft. Typisch wordt hierbij gedacht aan een video die moet gedownload worden, of indien de analogie wordt doorgetrokken naar de TV-wereld, een apart TV-programma of commercial. Een SE Object geeft informatie over de events die in die stream kunnen optreden. Het zou dus niet consistent zijn mocht dat object informatie geven over andere streams (andere programma’s, commercials). Om meerdere tijdsbases te gebruiken moeten er meerdere SE objecten in de carrousel worden opgenomen. Zo zijn er toch meerdere tijdsbases mogelijk, nl. ´e´en per Stream Event Object. In MHP is het echter niet toegestaan dat twee of meer tijdsbases tegelijk oplopen. Er is op elk ogenblik slechts ´e´en tijdsbasis actief, terwijl de andere “gepauzeerd” zijn. Het derde belangrijk onderdeel van een Stream Event Object is een verwijzing naar een elemen6
Deze verwijzing bevat niet de PID van de elementary stream, maar een zgn. tap. Het gebruik van taps
i.p.v. PID-nummers vergemakkelijkt een eventuele latere remultiplexering, waarbij de PID’s worden gewijzigd [25]. 7 Zoals reeds aangehaald werd het MHP-triggermechanisme gebaseerd op DSM-CC, waarin o.a. het SE Object wordt gedefinieerd.
4.2 Triggeren van events met MHP
36
tary stream waarin de Stream Event Descriptors optreden. Deze vormen de eigenlijke triggers voor de events en worden besproken in de volgende paragraaf.
Stream Event Descriptor Een descriptor is een speciale structuur met een vaste syntax die op verschillende plaatsen in de Transport Stream kan voorkomen. Hij wordt gebruikt in de MPEG-2 standaard om allerlei informatie door te geven over zaken zoals de System Time Clock, copyright-informatie, de bitrate, eventuele voorwaardelijke toegang... Elke descriptor heeft een eigen tag. Descriptors worden verstuurd in tabellen zoals de PMT of de PAT, die op hun beurt verdeeld worden in een of meerdere sections. De Stream Event Descriptor is een DSM-CC descriptor en wordt, net zoals het Stream Event Object, verstuurd in een DSM-CC Section. Dit is een verdere specificatie van de MPEG-2 Private Section (zie paragraaf 3.1.4). De Stream Event Descriptors komen, in tegenstelling tot de Stream Event Objects, niet terecht in de carrousel maar vormen een aparte elementary stream. De Stream Event Descriptors zijn de eigenlijke triggers van de events. Elke trigger bevat het eventID (niet de naam) van het event dat het laat optreden. De koppeling tussen naam en eventID gebeurt op basis van de informatie in het Stream Event Object. Er zijn twee types triggers, en dus twee types descriptoren: do-it-now. Als zo’n descriptor ontvangen wordt, dan treedt het corresponderende event
onmiddellijk op. scheduled event. Deze descriptor bevat naast een eventID ook nog een NPT-waarde,
die aangeeft wanneer het event moet optreden. Deze triggers worden ontvangen een tijdje v`o`or het eigenlijke event optreedt. Eventueel kunnen zelfs meerdere triggers voor hetzelfde event verstuurd worden. Elke trigger/descriptor kan nog eventuele extra data, private data, bevatten die meer informatie kan geven omtrent de eigenlijke trigger. Ook dit was een vereiste die aan bod kwam in hoofdstuk 2.
4.2 Triggeren van events met MHP
37
Voorbeeld Om het complexe samenspel tussen Stream Event Objects en Stream Event Descriptors beter te duiden, wordt een concreet voorbeeld uitgewerkt. Het bevat niet alle finesses en is hier en daar vereenvoudigd, maar laat toch toe om het principe te illustreren. In figuur 4.8 wordt een momentopname getoond van een Transport Stream. Bemerk dat het om een logische opdeling
Elementary Stream #1 DSM-CC Section * NPT Reference Descriptor 1 - contentID = 7 - NPT-value = 4 (actief)
* NPT Reference Descriptor 2 - contentID = 3 - NPT-waarde = 12 (gepauzeerd)
Elementary Stream #2 DSM-CC Stream Event Object 1 * timebase: contentID = 7 * eventList: event1 (id = 1); event2 (id = 2) * referentie naar ES met Event Descriptors
DSM-CC Stream Event Object 2 * timebase: contentID = 3 * eventList: event3 (id = 3); event4 (id = 4) * referentie naar ES met Event Descriptors
Elementary Stream #3 DSM-CC Section * Stream Event Descriptor - do-it-now: eventID = 1 - scheduled: eventID = 2 @ NPT = 6; eventID = 4 @ NPT = 14
Elementary Stream #4
Elementary Stream #5
AUDIO
VIDEO
Figuur 4.8: Stream Event Objects en Stream Event Descriptors
gaat en dat de feitelijke opdeling in transport pakketten niet behandeld wordt. De Transport Stream bestaat uit vijf elementary streams. Twee elementary streams (#4 en #5) bevatten de audio en de video. In een derde elementary stream (#2) wordt de Object Carousel verstuurd, opgedeeld in DSM-CC sections (niet getoond op de figuur). Deze bevat momenteel slechts twee objecten, elk van het type Stream Event Object. Elk Stream Event Object bevat de drie zaken die in supra beschreven werden: een lijst met de mogelijke events, ´e´en (en slechts ´e´en) verwijzing naar de elementary stream met de NPT-descriptors (#1) van de gebruikte tijdsbasis
4.3 Evaluatie van MHP
38
en een verwijzing naar de elementary stream die de triggers (Stream Event Descriptors) bevat voor de events (#3). Er worden twee tijdsbases gebruikt, met contentID = 3 en 7. Zoals vereist door MHP is slechts ´e´en tijdsbasis actief (nl. 7), terwijl de overige (hier enkel 3) gepauzeerd zijn. Op het ogenblik van het snapshot werd er ook een Stream Event Descriptor gedetecteerd. Deze bevat triggers voor drie events: event 1 moet onmiddellijk optreden, events 2 en 4 treden pas op bij de gespecificeerde NPT-waarde. Om te weten op welke tijdsbasis deze triggers betrekking hebben, moet gebruik gemaakt worden van de informatie in de Stream Event Objects. Via die objecten weten we dat events 1 en 2 gebruik maken van de NPT met contentID = 7; en dat de events 3 en 4 de NPT met contentID = 3 gebruiken. Event 2 treedt op zodra de (momenteel actieve) tijdsbasis 7 de waarde 6 bereikt; event 4 zal slechts optreden als de (momenteel gepauzeerde) tijdsbasis 3 geactiveerd wordt en de waarde 14 bereikt.
4.3
Evaluatie van MHP
In de voorgaande bespreking is duidelijk naar voor gekomen dat het triggerprincipe in MHP heel complex is. Het samenspel van Stream Event Objects en Stream Event Descriptors levert desalniettemin een mechanisme op dat aan nagenoeg alle vereisten voldoet die opgesomd werden in hoofdstuk 2: het gebruik van NPT als tijdbasis, meerdere tijdsbases, mogelijk transport van private data met de triggers, de ontkoppeling tussen de naam van een event en zijn eventID... Anderzijds komen er ook talrijke nadelen aan de oppervlakte wanneer het mechanisme wordt toegepast op de specifieke context van deze scriptie. Het carrouselprincipe werd initieel ontwikkeld voor de broadcast-wereld, waar er enkel een unidirectioneel kanaal van server naar client aanwezig is. Om toe te laten dat gebruikers op elk moment kunnen inloggen en toch nog kunnen genieten van de applicaties, is de carrousel zonder twijfel een elegante en logische oplossing. Het is echter duidelijk dat het carrouselprincipe bijzonder complex is. Denken we bv. alleen al maar aan de verschillende stappen die moeten doorlopen worden in figuur 4.7 alvorens een Stream Event Object kan verstuurd worden. In deze scriptie wordt op zoek gegaan naar een raamwerk specifiek voor het digitaal TV-netwerk van Belgacom. Dit netwerk is IP-gebaseerd en inherent bidirectioneel. Het is dus logisch dat oplossingen gezocht worden die ten volle gebruik maken van de voordelen van deze bidirectionaliteit. Een carrousel past duidelijk niet in dit kader. Om deze stelling te staven bekijken we nog eens in detail voor welke twee zaken de carrousel aangewend wordt: het (meermaals) versturen
4.3 Evaluatie van MHP
39
van applicaties naar de settop-box en het verzenden van Stream Event Objects voor de triggering. Wat betreft het versturen van applicaties, merken we op dat zodra een TV-gebruiker zijn toestel inschakelt, of overschakelt op een ander TV-kanaal, er een signaal wordt verzonden naar de dichtsbijzijnde DSLAM8 . Deze reageert door de gewenste Single Program Transport Stream door te sturen9 . De DSLAM zou op dat ogenblik meteen ook alle nieuwe applicaties voor die Transport Stream naar de settop-box kunnen doorsturen. Zo wordt bandbreedte gespaard, want de applicaties moeten slechts ´e´en keer verzonden worden. In een xDSL-omgeving met beperkte capaciteit is dit ongetwijfeld een belangrijk argument. Er blijft dan enkel nog de tweede functionaliteit van de carrousel over: het versturen van de Stream Event Objects. In feite is het voldoende dat deze objecten, of een analoge structuur met dezelfde informatie, op regelmatige wijze verzonden worden naar de ontvanger. Het volstaat niet om die, net zoals de applicaties, eenmalig door te sturen op het moment dat de gebruiker overschakelt. Het aantal events kan immers wijzigen in de tijd. Het herhaaldelijk versturen van informatie kan echter evengoed verwezenlijkt worden zonder de complexe structuur van een carrousel; af en toe een transport pakket met de gewenste informatie tussenvoegen, zorgt voor precies dezelfde functionaliteit en is veel eenvoudiger. Het is duidelijk dat een carrouselsysteem kan vermeden worden in het Belgacom-netwerk. Deze opmerking kan evenwel ge¨extrapoleerd worden naar het volledige Multimedia Home Platform. Tot op de dag van vandaag ontbreken de nodige aanpassingen om voluit gebruik te kunnen maken van de voordelen van de bidirectionaliteit van een IP-netwerk voor digitale TV. In dit verband publiceerde Belgacom in april 2004 een open brief naar de Europese Gemeenschap, waarin ze de nadelen van MHP in een IP-wereld opsomde [29]. De belangrijkste zijn: Het MHP-raamwerk is niet volledig geschikt om optimaal gebruik te maken van de moge-
lijkheden in een IP-netwerk. Het carrouselprincipe illustreert dit ten volle. De complexiteit om sommige applicaties zoals een elektronische programmagids te ont-
wikkelen in Java-MHP is niet steeds gerechtvaardigd, aangezien er mark-up talen bestaan waarin dit veel eenvoudiger kan ge¨ımplementeerd worden. DVB-HTML wordt niet als een volwaardig alternatief beschouwd. Tot op heden is er nog steeds geen volwaardige standaard voor MHP in de IP-wereld. Er
zijn echter wel al heel wat closed-source middleware-platformen op de markt gebracht. Dit 8 9
Digital Subscriber Line Acces Multiplexer. In een xDSL-netwerk is er een punt-tot-punt verbinding tussen eindgebruiker en DSLAM.
4.4 Besluit
40
zet het draagvlak voor MHP onder druk. De telecombedrijven wensen immers niet langer te wachten om de markt te betreden. Uit het bovenstaande kunnen we concluderen dat MHP om verschillende redenen ongeschikt is voor toepassingen in een IP-omgeving. Ook het triggerprincipe zelf, met het complexe samenspel van Stream Event Descriptors en Stream Event Objects, kan veel effici¨enter ge¨ımplementeerd worden.
4.4
Besluit
In dit hoofdstuk werd het Multimedia Home Platform uitgebreid besproken, als enige opensource middleware op de markt. Eerst werden de drielagige structuur van MHP en de twee types van MHP-applicaties (Java en X-HTML) belicht. Daarna kwam het triggermechanisme gedetailleerd aan bod. MHP maakt hiervoor gebruik van enkele concepten uit DSM-CC, zoals de Object Carousel en de Normal Playing Time. De triggering wordt verwezenlijkt door een combinatie van Stream Event Objects en Stream Event Descriptors. De objecten worden verstuurd in de Object Carousel en geven een overzicht van de mogelijke events die kunnen optreden. De descriptoren vormen de eigenlijke triggers. Dit samenspel resulteerde in een triggermechanisme dat voldeed aan veel eisen uit hoofdstuk 2: het gebruik van de NPT, meerdere tijdsbases, toevoegen van private data aan de triggers, de ontkoppeling tussen nummer en naam van een event... Na een iets diepere studie werd vastgesteld dat het triggermechanisme uit MHP niet geschikt is om toe te passen op het netwerk van Belgacom. Een carrousel bleek een bijzonder omslachtige manier om alle informatie te versturen. Er werd aangetoond dat in een bidirectioneel netwerk een carrousel kan vermeden worden om applicaties (voor nieuw ingelogde gebruikers) en de meest recente signalisatie repetitief te versturen. Het is duidelijk dat er een totaal nieuw raamwerk zal moeten opgezet worden, aangepast aan de noden en typische kenmerken van het Belgacom netwerk. De nuttige elementen uit MHP zullen hierbij uiteraard worden overgenomen.
IMPLEMENTATIE VAN HET RAAMWERK
41
Hoofdstuk 5
Implementatie van het raamwerk In dit hoofdstuk wordt dieper ingegaan op de structuur en implementatie van het ontwikkelde raamwerk. Het is niet de bedoeling om alle details en elke lijn code te verklaren. Zo’n overzicht zou enkel langdradig en verwarrend overkomen. Er werd daarom geopteerd voor een aanpak waarbij een globaal doch grondig beeld van de structuur van het raamwerk zal geschetst worden. De meeste aandacht zal gaan naar het belichten van de verbanden tussen de verschillende onderdelen van de code, de gemaakte keuzes en de implementatie en uitwerking van sommige algoritmes. Zo kan de lezer/programmeur zich ongetwijfeld sneller een weg banen doorheen de talrijke regels code. De code werd overvloedig van commentaar voorzien en is terug te vinden op de meegeleverde CD-ROM. Dit hoofdstuk is opgebouwd uit drie delen en geeft meteen een overzicht van de geleverde inspanningen voor deze scriptie. In een eerste deel wordt een protocol ontwikkeld voor de triggers en de bijhorende signalisatie. Naast de syntax wordt ook uitgebreid ingegaan op het eigenlijke transportmechanisme van die informatie in de TS. Tot slot zullen de uitbreidbaarheid en brede toepasbaarheid van het protocol geduid worden. Terwijl het eerste deel eerder de structuur van het raamwerk belicht, behandelen het tweede en derde deel het implementatie-aspect uit de titel van deze scriptie. Er werd een zend- en ontvangstmodule gebouwd. Met de zendmodule, besproken in het tweede deel, worden de triggers ge¨ınserteerd in de TS. Het derde deel belicht de ontvangstmodule, die een TS met triggers correct interpreteert en de getriggerde events op het gepaste ogenblik weergeeft. Deze module simuleert de settop-box bij de ontvanger.
5.1 De triggers in de Transport Stream
5.1
42
De triggers in de Transport Stream
Bij de uitbouw van het raamwerk moeten twee fundamentele zaken vastgelegd worden. Ten eerste moet onderzocht worden hoe de triggers in de TS kunnen getransporteerd worden. Het is immers de bedoeling om deze extra data zo effici¨ent mogelijk te laten meeliften met de gecodeerde audio en video. Deze effici¨entie kan gemeten worden in termen van beschikbare ruimte (het aantal bytes) voor de triggers, de vrijheid om een eigen syntax te defini¨eren, en de vereiste ingrepen om de triggers tussen de audio- en videodata te voegen. Het tweede deel omvat het protocol waarmee de zender (de broadcaster) en de ontvanger (TVkijker/settop-box) met elkaar zullen communiceren. Een protocol legt de volgorde en indeling vast van de berichten die worden uitgewisseld tussen de communicerende entiteiten, evenals de reacties van de partijen na het verzenden of ontvangen van een bericht [30]. Het protocol bepaalt dus meteen de mogelijkheden die het raamwerk zal bieden.
5.1.1
Transport van private data in een Transport Stream
Bij de ontwikkeling van de MPEG-2 standaard [4] was een van de uitgangspunten dat er voldoende mogelijkheden moesten ingebouwd worden om ook toekomstige evoluties (en de bijhorende eisen aan een codec) te kunnen ondersteunen. Er werden daarom talrijke opties voorzien om zogenaamde private data toe te kunnen voegen aan de TS. Dit kwam reeds aan bod in paragraaf 3.1.4 en wordt in de standaard omschreven als user defined data, het is m.a.w. data waarvan het formaat en de syntax door de gebruikers zelf kan en mag vastgelegd worden. De triggers en bijhorende signalisatie zijn uiteraard zo’n vorm van extra data die moet toegevoegd worden aan de Transport Stream. Omdat het transportmechanisme een belangrijke rol kan spelen voor de performantie van het triggermechanisme, volgt hieronder een grondig overzicht van de transportmogelijkheden voor private data. De in hoofdstuk 3 ingevoerde begrippen en afkortingen zullen hierbij veelvuldig aangewend worden.
PES-pakketten In hoofdstuk 3, in het bijzonder in figuur 3.1, werd uiteengezet hoe de video en audio in PESpakketten worden gecodeerd, die daarna over transport pakketten worden verdeeld. In de syntax van een PES-pakket is ook ruimte voorzien om private data toe te voegen. Dit kan zowel in de header als in de payload. In de header kunnen slechts 16 bytes toegevoegd worden, wat uiteraard
5.1 De triggers in de Transport Stream
43
ontoereikend is om een protocol te implementeren. In de payload is er geen beperking op het aantal bytes en kunnen er twee syntaxes gevolgd worden. De ene syntax legt een groter aantal velden vast dan de andere. De ruimte vormt bij het toevoegen van private data in de payload dus geen beperkende factor en deze optie is zeker valabel indien de triggers toegevoegd worden op het moment dat de PES-pakketten gegenereerd worden (d.i. bij de codering). Vermits een video-PES typisch 1 frame bevat, lijkt frame-nauwkeurige synchronisatie van de triggers haalbaar. Deze optie is evenwel niet geschikt als vertrokken wordt van een bestaande TS, waar de triggers nog moeten aan toegevoegd worden. Het wijzigen van de PES-pakketten is dan een heel complexe taak die veel verder gaat dan het louter inbrengen van de extra data. Zo zal de indeling van het gewijzigde PES-pakket in transport pakketten (cfr. figuur 3.1) opnieuw moeten gebeuren, wat dan weer betekent dat de tijdsstempels in de header van het PES-pakket moeten herberekend worden. Een van de eisen uit hoofdstuk 2 was een algemeen en generiek toepassingsgebied voor het raamwerk, zodat de triggers ook gemakkelijk en effici¨ent moeten kunnen toegevoegd worden aan een bestaande TS. Dit is niet haalbaar met deze optie.
Adaptation Field Sommige transport pakketten bevatten naast een header en de payload ook nog een Adaptation Field. Figuur 5.1 toont hoe dit veld tussen de header en de payload in komt. Het bevat o.a. de signalisatie om de System Time Clock van zender en ontvanger te synchroniseren. De payload
.
STC
.
header
Adaptation Field FF FF FF FF FF FF FF FF
payload tabelsectie of PES
Figuur 5.1: Een transport pakket met een Adaptation Field
bevat een deel van een PES-pakket of een sectie van een tabel. De grootte van een PES-pakket is variabel en is meestal geen exact veelvoud van de vaste grootte van een transport pakket. Bij de opdeling van een PES-pakket in transport pakketten kan het nodig zijn om stuffing bytes toe te voegen aan het laatste transport pakket. Ook als de payload een sectie van een tabel bevat,
5.1 De triggers in de Transport Stream
44
kunnen stuffing bytes nodig zijn. Die bytes worden in het Adaptation Field gecodeerd en komen dus v`o`or de payload. Het Adaptation Field kan ook private data bevatten. In principe kan het tot 184 bytes groot zijn, indien het pakket geen verdere nuttige data (gecodeerde video of audio) bevat. Het transport pakket (188 bytes) bevat dan behalve het Adaptation Field enkel de standaard 4-byte header. Deze situatie komt in praktische situaties zelden of nooit voor, zodat het Adaptation Field, en dus de ruimte voor de private data, typisch minder groot zal zijn. Het grootste nadeel is echter dat de beschikbare ruimte sterk variabel is, vermits de PES-pakketten vari¨eren in grootte en het aantal stuffing bytes dus telkens wijzigt. Hoewel deze optie, in tegenstelling tot de vorige (private data in PES-pakketten), geen herverdeling van de data over de transport pakketten vereist, is ze toch niet geschikt om het protocol op te baseren. Het is immers niet zeker hoe vaak en vooral hoeveel ruimte er beschikbaar is om private data door te sturen.
Descriptors Descriptoren kwamen reeds aan bod bij de bespreking van de Stream Event Descriptor op pagina 36. Ze bevatten nuttige informatie voor de decoder, zoals de frame rate, de bitrate, het audioformaat... Er is ook een private descriptor gedefinieerd die private data kan bevatten. De descriptors mogen in tal van pakketten ingevoegd worden en de syntax ervan legt weinig restricties op. Indien deze data wordt toegevoegd op het moment dat de transport pakketten gegenereerd worden, is deze optie zeker een valabele keuze. Net zoals bij de PES-pakketten is het problematischer wanneer de triggers en de signalisatie moeten toegevoegd worden aan een bestaande TS. De descriptors moeten tussengevoegd worden in de bestaande pakketten, wat nogal wat overhead met zich kan meebrengen. De kans bestaat immers dat de payload van ´e´en transport pakket door het toevoegen van de descriptors te groot is geworden en moet worden opgesplitst over meerdere transport pakketten. Aangezien het raamwerk ook een effici¨ent mechanisme moet aanbieden voor bestaande TS kan deze optie dus verworpen worden.
Transport Pakketten Het is eveneens mogelijk om volledige transport pakketten te vullen met private data. Die pakketten dragen dan een PID dat in de Program Map Table wordt aangegeven als user private. Bij deze optie kan er per transport pakket een maximale hoeveelheid private data toegevoegd worden en zijn er geen beperkingen op het gebied van syntax. Enkel de eerste 4 bytes moeten
5.1 De triggers in de Transport Stream
45
de standaard header vormen, zoals die in alle transport pakketten voorkomt. Bij deze optie worden extra transport pakketten gegenereerd, die door een remultiplexering in een bestaande TS kunnen opgenomen worden. Een remultiplexering is een complexe operatie waarbij de tijdsstempels in de TS moeten aangepast worden. Zoals uiteengezet in paragraaf 3.1.3, geven die stempels de ogenblikken aan waarop de pakketten ontvangen en gedecodeerd moeten worden. Door extra pakketten tussen te voegen wordt de relatieve positie in de TS gewijzigd, zodat de stempels moeten herberekend worden. Indien slechts enkele pakketten zouden tussengevoegd worden, zouden de dejitter-buffers van de ontvanger dit nog voldoende kunnen opvangen, zelfs bij ongewijzigde tijdsstempels. Bij een triggermechanisme zullen echter op regelmatige basis pakketten ingevoegd worden, alleen al om de signalisatie steeds up-to-date te houden en het mogelijk te maken dat gebruikers op elk ogenblik kunnen inloggen op de TS. Het herberekenen van de tijdsstempels is dan noodzakelijk.
Private Sections In paragraaf 3.1.4 werd deze transportwijze voor private data reeds besproken. Ter herinnering vermelden we dat de tabellen (PAT, PMT) in de TS opgesplitst worden in secties voor ze verstuurd worden. Volgens hetzelfde principe werden ook private sections gedefinieerd. Er zijn twee syntaxes mogelijk, waarbij de ene meer velden vastlegt dan de andere. Private sections zijn de aangewezen manier als private data over meerdere transport pakketten moet verstuurd worden met een absoluut minimum aan structuur. Hoewel de private sections deel uitmaken van een service (cfr. paragraaf 3.1.1), moet er geen extra vermelding in de Program Map Table komen. Ze gebruiken immers hetzelfde PID als de Program Map Table zelf. Figuur 5.2 illustreert de twee manieren waarop een private section kan toegevoegd worden aan de TS: ofwel in hetzelfde pakket als een (sectie van een) Program Map Table, ofwel in een apart transport pakket. De overige transport pakketten, in het bijzonder die met de PES-pakketten, worden ongemoeid gelaten. Een remultiplexering, met bijhorende aanpassing van de tijdsstempels, is enkel nodig als de private sections in aparte transport pakketten verstuurd worden.
PMT FF FF FF FF FF FF FF FF FF
46
PMT private section
remup tilelxer
5.1 De triggers in de Transport Stream
private section
Figuur 5.2: Het transport van een private section in een bestaande Transport Stream
Metadata Sections Recent, in 2003, werd door de MPEG2-groep een uitbreiding op de standaard gepubliceerd [31], waarin het principe van de private sections verder uitgediept werd en het concept van metadata werd ingevoerd. Metadata is private data die de audiovisuele inhoud van de stream beschrijft en dus verband houdt met de overige data in de TS. Bij ‘gewone’ private data is dit niet noodzakelijk het geval. De metadata wordt opgesplitst in metadata services, verzamelingen van logisch bij elkaar horende metadata1 . Een program kan meerdere metadata services bevatten. De uitbreiding voorziet in allerlei descriptors om de metadata te structureren en te signaleren. Daarnaast werd er ook expliciet aandacht geschonken aan de synchronisatie tussen de metadata en de audiovisuele data die deze beschrijft. Zo wordt o.a. de Normal Playing Time ondersteund. Deze werd besproken in paragraaf 4.2.3. In de uitbreiding worden vijf mechanismen beschreven voor het transport van metadata. Twee methoden zijn synchroon, wat betekent dat ze gebruik maken van de System Time Clock. Deze sluiten a priori het gebruik van de Normal Playing Time uit en zijn dus niet bruikbaar, om redenen die eerder uiteengezet werden in hoofdstuk 2. De overige drie methoden zijn asynchroon. Twee ervan maken gebruik van de DSM-CC Data Carousel die werd besproken in paragraaf 4.2.1 en die, zoals toen vermeld, bijzonder veel overhead met zich meebrengt. Bij de derde asynchrone methode wordt gebruik gemaakt van metadata sections. Deze methode sluit eigenlijk heel nauw 1
Bemerk de analogie met de indeling van bij elkaar horende elementary streams in services (of programs).
5.1 De triggers in de Transport Stream
47
aan bij de private sections (de syntax is nagenoeg dezelfde), maar biedt heel wat meer structuur aan de metadata. Een nadeel van dit mechanisme is het feit dat talrijke descriptors op vele plaatsen in de TS moeten toegevoegd worden. Dit maakt deze methode ongeschikt voor het toevoegen van triggers aan een bestaande TS. Hoewel de gepubliceerde uitbreiding bedoeld is om een antwoord te bieden op de vraag naar een gesynchroniseerd transport van metadata, moeten we besluiten dat geen van de vijf opties echt aan onze verwachtingen voldoet.
Besluit In het bovenstaande werden alle opties om private data in een TS te transporteren behandeld. De meeste van de opties werden ongeschikt bevonden omdat ze ofwel teveel ingrepen op verschillende plaatsen in de TS vergen (toevoegen van descriptors, al dan niet in combinatie met metadata sections) ofwel omdat ze enkel praktisch haalbaar zijn indien de triggers worden toegevoegd op het moment van coderen (PES-pakketten, Adaptation Field). Slechts twee opties lijken haalbaar: het gebruik van volledig aparte transport pakketten en het mechanisme met de private sections. Beide opties zijn sterk verwant en bieden een gelijkaardig scala aan mogelijkheden: ze hebben weinig opgelegde structuur en syntax. In beide gevallen kan echter een complexe remultiplexering, met aanpassing van de tijdsstempels, nodig zijn. Indien aparte transport pakketten gebruikt worden, is dit zelfs niet te vermijden. Binnen deze scriptie werd er uiteindelijk voor gekozen om het principe van de private sections te weerhouden en dit omwille van de volgende redenen: Het gebruik van private sections sluit het gebruik van aparte transport pakketten niet uit.
Het is immers mogelijk om een transport pakket te versturen dat enkel een private section bevat. Zo’n pakket draagt dezelfde PID als de Program Map Table in de TS en er is geen extra vermelding voor nodig in de PMT. Bij het gebruik van volledig private transport pakketten, zonder de syntax van een private section, krijgen die wel een eigen PID. Die moet dan gesignaleerd worden in de PMT. Private sections kunnen ook verstuurd worden in hetzelfde pakket als een Program Map
Table. Een transport pakket kan in welbepaalde gevallen meerdere sections bevatten. De MPEG-2 standaard laat o.a. toe dat een PMT-section en een private section in hetzelfde pakket wordt opgenomen. In paragraaf 5.1.2 wordt nog even dieper ingegaan op dit argument.
5.1 De triggers in de Transport Stream
48
Wanneer volledig private transport pakketten gebruikt zouden worden, zou sowieso nog een
syntax/header moeten ontwikkeld worden. Die zou heel sterk lijken op, of toch ten minste dezelfde functies implementeren als de header bij private sections: een volgnummer om de sections te kunnen ordenen, een veld dat de lengte van de payload aangeeft, eventueel een foutcontrole... Dit is nodeloos werk, aangezien de syntax van de private sections al die functies biedt zonder al te veel complexiteit te introduceren. De keuze voor private sections heeft enkel voordelen t.o.v. het gebruik van transport pakketten en zorgt niet voor beperkende keuzes: de PMT moet niet aangepast worden en het blijft mogelijk om volledige transport pakketten met triggerdata te versturen. In dit laatste geval is er wel een remultiplexering vereist, met aanpassing van de tijdsstempels. Gezien de eis voor een generieke toepasbaarheid en uitbreidbaarheid lijkt de optie met de private sections dus de aangewezen keuze.
5.1.2
Het protocol
In de vorige paragraaf werd de keuze voor private sections als transportmechanisme voor de triggers en de signalisatie uitvoerig geargumenteerd. E´en van de belangrijkste argumenten was de mogelijkheid om de private sections zowel toe te voegen na een Program Map Table als in een apart transport pakket. In deze scriptie werd er voor geopteerd om te vertrekken van een bestaande TS i.p.v de triggers in te brengen op het moment van de encodering. Het includeren van de private sections zal dus, afhankelijk van het gekozen mechanisme uit figuur 5.2, ofwel een remultiplexering vereisen, ofwel een aanpassing van de pakketten die een Program Map Table bevatten. Een effici¨ente remultiplexering implementeren om de transport pakketten op de gepaste ogenblikken in te voegen, is geen eenvoudige zaak en zeker niet binnen het beperkte tijdskader van een scriptie. Het proces wordt bovendien sterk gecompliceerd door het feit dat de tijdsstempels in de TS moeten aangepast worden. De meeste op de markt aanwezige remultiplexers zijn grotendeels in hardware ge¨ımplementeerd om het complexe rekenwerk uit te voeren. Een implementatie van een remultiplexer voor een TS vindt men terug in [32]. In deze scriptie werd er daarom voor gekozen om een remultiplexering te vermijden en de private sections enkel toe te voegen aan transport pakketten die al een PMT bevatten. Hierdoor wordt uiteraard een beperking ingevoerd op de beschikbare ruimte en de frequentie waarmee de trigger-
5.1 De triggers in de Transport Stream
49
informatie kan verstuurd worden. Het ontwikkelde raamwerk vereist echter geen aanpassingen indien men later wenst over te schakelen op aparte transport pakketten. Bij de analyse van enkele Single Program Transport Streams bleek dat de Program Map Table slechts heel weinig ruimte inneemt en dat het overgrote deel van het transport pakket, typisch meer dan 2/3 van de 188 bytes, uit stuffing bytes bestaat. Door hier een private section in te voegen kan van deze ruimte, die ruimschoots voldoet voor de triggers en de signalisatie, nuttig gebruik gemaakt worden. De frequentie van de PMT’s in de stream blijft echter nog steeds een beperking en legt een ondergrens op de nauwkeurigheid waarmee de triggers kunnen toegevoegd worden. Hierop wordt teruggekomen in de paragraaf Uitbreidbaarheid op pagina 53. In wat volgt, zullen achtereenvolgens de signalisatie en de eigenlijke triggering besproken worden. Meteen worden de mogelijkheden van het raamwerk en de hierbij gemaakte keuzes uiteengezet. Om dit deel te be¨eindigen, wordt de uitbreidbaarheid van het protocol belicht.
Signalisatie De signalisatie is een essentieel onderdeel van het triggermechanisme. Op basis van deze informatie kan de ontvanger de triggers correct interpreteren. Door de signalisatie regelmatig te herhalen, beschikt de ontvanger steeds over de meest recente informatie en kunnen gebruikers op elk ogenblik op de TS afstemmen en de triggers ontvangen. De private section kan zowel een eenvoudige als een uitgebreide syntax hebben. Voor de signalisatie wordt gebruik gemaakt van de eenvoudige syntax, aangevuld met enkele nuttige velden uit de uitgebreide syntax. In bijlage B wordt de exacte syntax voor de signalisatie gegeven, in figuur 5.3 wordt een globaal beeld geschetst. Grosso modo zijn er drie delen te onderscheiden. Het eerste deel is de header van de private section. Die bevat o.a. een volgnummer en een versienummer. Mocht niet alle informatie in ´e´en private section passen, dan kan de ontvanger dankzij het volgnummer de volledige signalisatie terug samenstellen. Op basis van het versienummer kan de gebruiker updates in de informatie gemakkelijk detecteren, zonder steeds de ganse private section te moeten ontleden. Het tweede deel van de private section geeft informatie over de tijdsbases die door de events gebruikt worden. Meer concreet bevat dit deel een of meerdere NPT-descriptoren, analoog aan wat besproken werd in paragraaf 4.2.3. Het derde en laatste deel is een overzicht van alle events die kunnen optreden. De events zijn hierbij gegroepeerd per tijdsbasis.
5.1 De triggers in de Transport Stream
50
Transport Pakket Private Section HEADER NPT-descriptoren voor contentID = 1 en 2 contentID = 1 event1: eventID, naam event2: eventID, naam contentID = 2 event3: eventID, naam
Figuur 5.3: Private Section voor de signalisatie
We zetten nog even de belangrijkste kenmerken van de signalisatie op een rij. De lezer zal merken dat onderstaande opsomming volledig beantwoordt aan de eisen voor de signalisatie die opgesomd werden in paragraaf 2.1.4. Normal Playing Time. Het raamwerk maakt gebruik van de Normal Playing Time. Ter
herinnering vermelden we dat de NPT kan vergeleken worden met de timer op een videotoestel. Zoals naar voor kwam bij de bespreking van figuur 2.2, is het een noodzakelijke voorwaarde om zo’n tijdsbasis te voorzien, want alleen op deze manier kunnen triggers op ondubbelzinnige wijze gesynchroniseerd worden met de audiovisuele data. De tijdsbasis wordt doorgegeven via de NPT-descriptoren die besproken werden in paragraaf 4.2.3. Er is geen beperking op het aantal NPT-descriptoren per private section en typisch zal er ´e´en descriptor zijn per tijdsbasis. De syntax van de descriptoren werd wel licht aangepast t.o.v. die in DSM-CC en enkele velden werden ingekort. De NPT-descriptoren komen ook voor in de private section met de triggers en zullen daar uitgebreider besproken worden. De volledige syntax is terug te vinden in bijlage B. meerdere tijdsbases. Het raamwerk maakt uiteraard gebruik van de mogelijkheid die
de NPT biedt om meerdere tijdsbases tegelijk te ondersteunen. Elke tijdsbasis krijgt een uniek identificatienummer, het contentID, en heeft zijn eigen NPT-descriptoren. In het voorbeeld van figuur 5.3 zijn er twee tijdsbases. Op deze manier kan elk programma zijn eigen tijdsbasis krijgen en komt de timing van de triggers niet in het gedrang.
5.1 De triggers in de Transport Stream
51
koppeling tussen eventID en naam. Elk mogelijk event heeft naast een naam ook een
eigen identificatienummer, het eventID. De triggers voor een event bevatten dan enkel het corresponderende nummer. De applicaties op de settop-box registreren zich voor events op basis van de naam. De signalisatie moet er voor zorgen dat de vertaling tussen eventID en naam kan gebeuren. compactheid. Er werd voor gezorgd dat alle informatie op een zo compact mogelijke
wijze wordt verstuurd, zonder aan flexibiliteit of mogelijkheden in te boeten. Zo worden de mogelijke events gegroepeerd per contentID aangegeven, eerder dan voor elk event apart het contentID mee te geven. Dit zou niet alleen voor redundante informatie zorgen maar ook de interpretatie aan de ontvanger vertragen. Compactheid is overigens ook de reden waarom de eenvoudige syntax van de private section verkozen werd boven de uitgebreide syntax, en de syntax van de NPT-descriptoren licht werd aangepast.
Triggers Zodra er events moeten optreden, zullen er private sections met triggerinformatie doorgestuurd worden. Er zijn triggers gedefinieerd voor do-it-now events en scheduled events. Het onderscheid tussen beide werd ge¨ıllustreerd in figuur 2.1. Net zoals voor de signalisatie werd voor de private section met de triggerinformatie gekozen voor de eenvoudige syntax. Figuur 5.4 geeft een schematisch overzicht; de volledige syntax is te vinden in bijlage B. De header van de private section is minder uitgebreid dan die bij de signalisatie. De rest van de section wordt opgevuld met een willekeurige combinatie van drie types descriptoren, zonder restrictie op volgorde of aantal. Er zijn descriptoren voor een trigger van een do-it-now en een scheduled event. De derde soort descriptor is de NPT-descriptor, die ook gebruikt wordt in de private section met de signalisatie-informatie. Het eerste veld van elke descriptor bestaat uit een 3-bit tag. De ontvanger kan op basis van deze tag het type van elke descriptor in de private section bepalen. Aangezien een 3-bit tag aanleiding geeft tot 8 mogelijke descriptoren, is er nog ruimte om in de toekomst tot 5 nieuwe descriptoren te defini¨eren, bv. voor nieuwe types van triggers of tijdsbases. De do-it-now descriptor bevat enkel het eventID van het ogenblikkelijk op te treden
event. De ontvanger geeft deze trigger door aan de applicaties die zich voor dit event (via de naam) hebben geregistreerd. Het is mogelijk om extra data mee te geven, die de
5.1 De triggers in de Transport Stream
52
Transport Pakket Private Section HEADER
do-it-now trigger NPT-descriptor, contentID = 1 scheduled event trigger NPT-descriptor, contentID = 2
Figuur 5.4: Private section met triggers
eigenlijke vorm van het optreden van het event kan be¨ınvloeden. Zo kan het bv. de kleur bepalen van de stip die moet weergegeven worden. De scheduled-event descriptor bevat naast een eventID ook een veld met het ogenblik
(i.e. de NPT-waarde) waarop het event moet optreden. Via de signalisatie kan de ontvanger bepalen welke tijdsbasis dit event gebruikt. Ook hier is de mogelijkheid voorzien om extra data mee te geven. De NPT-descriptor kwam reeds aan bod bij de bespreking van de signalisatie. Toen
werd echter niet dieper ingegaan op de syntax ervan. Elke descriptor bevat eerst en vooral een contentID om aan te geven op welke tijdsbasis deze descriptor betrekking heeft. De eigenlijke codering gebeurt op basis van twee velden. De NPT bereikt de waarde uit het eerste veld op het ogenblik dat de System Time Clock van de ontvanger de waarde bereikt die in het tweede veld is aangegeven. De descriptor geeft ook de verhouding aan waarmee de NPT evolueert t.o.v. de systeemklok. Zo laat een verhouding 1:1 beide klokken even snel lopen, geeft een verhouding 2:1 aan dat de NPT dubbel zo snel voortschrijdt als de systeemklok en bij een verhouding -1:1 loopt de NPT terug aan een zelfde snelheid als waarmee de systeemklok oploopt. De plaats van een descriptor in het pakket is variabel en voor elke private section zal de volgorde en de soort van de descriptoren verschillen. Het mechanisme van de descriptoren biedt dus precies die flexibiliteit die gevraagd wordt voor het toevoegen van de triggers. Zo zullen er niet
5.1 De triggers in de Transport Stream
53
altijd evenveel tijdsbases gesignaleerd worden en is het aantal NPT-descriptoren dus variabel. Verder moet een descriptor met een trigger voor een do-it-now event ogenblikkelijk en slechts eenmalig doorgegeven worden. Voor scheduled events moeten de triggers pas in de TS voorkomen tot op het moment dat het event effectief moet optreden.
Uitbreidbaarheid In het voorgaande werd de syntax van de private sections voor de signalisatie en de triggers uiteengezet. Regelmatig werd daarbij aangegeven hoe het raamwerk voldeed aan de eisen uit hoofdstuk 2. In deze paragraaf is het de bedoeling om toe te lichten hoe het raamwerk voldoet aan een andere belangrijke eis, nl. die van de generieke toepasbaarheid. Hieruit vloeit automatisch voort dat het raamwerk geen beperkingen mag bieden voor toekomstige uitbreidingen. Zoals vermeld in de paragraaf Signalisatie op pagina 49, werd er bij de implementatie voor gekozen om enkel private sections toe te voegen aan bestaande pakketten met een Program Map Table en geen extra pakketten te remultiplexeren met de TS. Dit beperkt de frequentie waarmee extra data kan worden meegegeven tot de frequentie waarmee de PMT’s verzonden worden. De standaard legt geen grenzen vast, maar het is uiteraard zo dat de PMT’s op voldoend regelmatige basis moeten verzonden worden2 . Een settop-box die afstemt op de TS kan immers pas beginnen met de eigenlijke decodering zodra hij een PAT ´en een PMT heeft teruggevonden. Voor de triggers heeft deze beperkte frequentie onder meer als gevolg dat de nauwkeurigheid waarmee een do-it-now trigger kan doorgegeven worden, beperkt is. Op het moment dat het do-it-now event moet optreden, wordt idealiter meteen een trigger doorgestuurd naar de ontvanger. Met het principe uit deze scriptie moet de trigger evenwel wachten op het eerstvolgende pakket met een PMT alvorens hij kan verstuurd worden. Al van bij de zender wordt dus een extra delay ingebouwd. In het besluit van paragraaf 5.1.1 kwam reeds aan bod dat private sections ook in aparte transport pakketten kunnen verzonden worden en dan niet hoeven te wachten op een pakket met een PMT. Op deze manier kan de nauwkeurigheid van do-it-now triggers wel gegarandeerd worden, vermits een transport pakket op gelijk welk ogenblik kan en mag tussengevoegd worden. Indien vertrokken wordt van een bestaande TS, vereist dit wel de kost van een complexe remultiplexeringsoperatie. Het raamwerk kan echter zonder enige aanpassing toegepast worden in de situatie 2
In de standaard [4] staat letterlijk: Each TS shall contain one or more TS packets with PID values which
are labelled [...] as TS packets containing program map table sections.
5.1 De triggers in de Transport Stream
54
waarbij de triggers toegevoegd worden op het moment van de encodering. Het mechanisme kan verder gemakkelijk uitgebreid worden tot Multi-Program Transport Streams. Elke service (program) in zo’n stream heeft immers een eigen Program Map Table met een unieke PID. Per service kunnen de private sections eenvoudig toegevoegd worden bij de gepaste PMT. Bij de decodering moeten evenmin extra aanpassingen gebeuren. De extra informatie kan eenvoudigweg ge¨ıdentificeerd worden met de gepaste service op basis van het PID-nummer. Ook de uitbreiding naar aparte transport pakketten, waarbij een transport pakket dan het PID draagt van de PMT van de service waartoe het behoort, blijft in dit geval mogelijk. Een laatste mogelijke uitbreiding situeert zich bij de descriptoren die gebruikt werden. Zoals vermeld, heeft elk type descriptor een unieke 3-bit tag. Van de 8 verschillende tags werden er nog maar 3 vastgelegd. De 5 overige kunnen gebruikt worden indien men i.p.v. de NPT een ander/nieuw soort tijdsbasis wenst te gebruiken of indien men nieuwe types triggers wenst te defini¨eren.
5.1.3
Besluit
In deze subsectie werd het protocol toegelicht, dat de kern vormt van het ontwikkelde raamwerk. In een eerste deel werd onderzocht hoe de extra data, nl. de triggers en de signalisatie, kunnen verstuurd worden in een TS. Uiteindelijk werd de optie met de private sections weerhouden. De private sections worden toegevoegd aan transport pakketten die een Program Map Table bevatten. Er bleek immers nog veel ongebruikte ruimte te zijn in zulke pakketten. Bovendien werd een complexe remultiplexering vermeden. Toch is het principe zonder problemen uitbreidbaar en kunnen de private sections in aparte transport pakketten tussengevoegd worden. Indien de triggers bijgevoegd worden op het moment van coderen, is dit zelfs de beste keuze. In een tweede luik werd ingegaan op de syntax van de private sections voor de signalisatie en de triggering. Meteen werden de mogelijkheden van het raamwerk toegelicht. Zo wordt gebruik gemaakt van het concept van de Normal Playing Time en is het mogelijk om meerdere tijdsbases tegelijk te signaleren. De signalisatie zorgt verder voor een ontkoppeling tussen eventID en de naam van het event, die gebruikt wordt door de applicaties op de settop-box. Bij de triggering werd gebruik gemaakt van 3 types descriptoren om zo maximale flexibiliteit te garanderen. Er zijn zowel do-it-now als scheduled events mogelijk. Tot slot werden de mogelijke uitbreidingen van het ontwikkelde protocol belicht. De evolutie
5.2 Het model
55
naar Multi-Program Transport Streams of een preciezere synchronisatie voor do-it-now events stelt geen problemen. Er kunnen ook nieuwe types descriptoren bijgevoegd worden.
5.2
Het model
In deze scriptie wordt enkel de situatie beschouwd waarin een programma vooraf opgenomen werd. De volledige TS is beschikbaar op een lokaal medium bij de partij die triggers voor events wenst toe te voegen. Het programma wordt tijdens de post-productie met de zendapplicatie bekeken om de tijdstippen van de events te bepalen. Als het volledige programma doorlopen is, worden de triggers aan de gepaste pakketten in de TS toegevoegd. Het real-time aspect is in deze scriptie dus op twee gebieden uitgeschakeld. Ten eerste worden de triggers voor de events pas toegevoegd nadat het volledige programma bekeken werd. Strikt genomen zijn er enkel scheduled-events, want de tijdstippen van alle events in het programma zijn voor de eigenlijke uitzending ervan gekend. Toch werd de mogelijkheid om do-it-now events te simuleren mee opgenomen bij de ontwikkeling van zend- en ontvangstapplicatie. Het versturen over het netwerk van de TS is een tweede gebied waar het real-time aspect verlaten werd. Bij de bouw van de ontvangstmodule gaan we er eveneens vanuit dat de volledige TS met triggers aanwezig is op een lokaal medium. In deze scriptie wordt de verzending over het netwerk niet behandeld. Eventueel kan de streamer ontwikkeld in [33] gebruikt worden. Door het real-time aspect achterwege te laten, kon meer tijd gespendeerd worden aan het uitbouwen van een zend- en ontvangstapplicatie die alle mogelijkheden van het raamwerk ten volle kan gebruiken en demonstreren. Bij de ontwikkeling werd er wel steeds op gelet dat een uitbreiding naar het real-time geval zo gemakkelijk en vlot mogelijk kan verlopen.
5.3
Het raamwerk aan de zenderzijde
De implementatie van het raamwerk bestaat uit twee luiken. Enerzijds moet er een applicatie gebouwd worden voor de zenderzijde die de triggers en de signalisatie genereert en inserteert in de TS3 . De applicatie vormt een interface naar de partij die aan de oorsprong van de TS ligt. Dit kan zowel het productiehuis van het programma als de eigenlijke verdeler of content distributor zijn. In wat volgt zal deze applicatie steeds omschreven worden als de zender of 3
Een eventuele uitbreiding kan vertrekken van een TV-programma in een ongecomprimeerd videoformaat.
5.3 Het raamwerk aan de zenderzijde
56
de zendmodule. Anderzijds is er de ontvangstzijde, waar de triggers en de signalisatie correct moeten ge¨ınterpreteerd worden door de middleware op de settop-box. In deze scriptie wordt dit gesimuleerd door een applicatie op PC en zal er gesproken worden over de ontvanger of de ontvangstmodule. De zendmodule wordt in deze sectie besproken, de ontvangstmodule komt aan bod in de volgende sectie.
5.3.1
Functies van de zendmodule
Om de functies te bepalen die de zendmodule moet implementeren, dient men zich in de plaats te stellen van de partij die aan de oorsprong ligt van de TS en zich de vraag stellen welke opties er vereist zijn om een performant en compleet triggermechanisme op te zetten. Het antwoord werd reeds geformuleerd in hoofdstuk 2 en komt neer op de fundamentele tweedelige opsplitsing tussen signalisatie en eigenlijke triggering van de events. Signalisatie. Het moet mogelijk zijn om op eenvoudige wijze nieuwe events te defini¨eren,
die door de zendmodule automatisch een uniek eventID toegewezen krijgen. Ook het beheer van de verschillende NPT-tijdsbases en het toewijzen van een contentID aan elk van hen behoort tot de taken van de signalisatie. Al deze informatie moet met de TS doorgegeven worden volgens de syntax die in paragraaf 5.1.2 uiteengezet werd. Triggering. De belangrijkste taak van dit onderdeel van de zendmodule is natuurlijk het
inbrengen van de triggers in de TS. Dit zal in nauwe samenwerking met de signalisatie moeten gebeuren. Zo mogen er geen triggers in de TS komen zolang ze niet gesignaleerd werden, vermits de decoder deze anders niet correct kan interpreteren. Verder hoeven de triggers voor een scheduled event slechts verstuurd te worden tot het event optreedt en is het dus belangrijk om te kunnen beschikken over de tijdsinformatie die beheerd wordt door de signalisatie. Aangezien de triggers slechts een eventID bevatten, moet op het moment van versturen eerst nog de omzetting gebeuren tussen de naam van het op te treden event en het corresponderende eventID. Ook hiervoor moet beroep gedaan worden op de informatie van de signalisatie. Het versturen zelf moet gebeuren volgens de syntax opgezet in paragraaf 5.1.2.
5.3 Het raamwerk aan de zenderzijde
5.3.2
57
Opbouw van de zendmodule
De zendmodule moet vrij uiteenlopende taken vervullen. Het invoegen van de extra informatie in de TS impliceert dat toegang moet verkregen worden tot de bits en bytes van een bestand. Een programmeertaal als C is hiervoor de aangewezen keuze. Als low-level taal is ze speciaal ontworpen om te werken op bitniveau. Anderzijds zijn er ook taken die een grotere vorm van intelligentie vereisen. Zo moet de broadcaster het videobestand kunnen bekijken wanneer hij de juiste ogenblikken van de events bepaalt. Er zouden ongetwijfeld talrijke regels code nodig zijn om een videobestand te laten afspelen met behulp van zuivere C-code. Andere, meer highlevel programmeertalen zoals Java of C++ hebben een grotere ingebouwde functionaliteit. Het weergeven van video kan in die talen met slechts enkele functie-aanroepen verwezenlijkt worden. Om aan deze uiteenlopende eisen te voldoen, werd besloten om de zendmodule (en ook de ontvangstmodule) deels in C en deels in Java te implementeren. Op die manier kan optimaal gebruik gemaakt worden van de voordelen die beide programmeertalen bieden. De keuze voor Java en bv. niet voor C++ om de meer intelligente taken te laten vervullen, werd vooral ingegeven door de wens om zoveel mogelijk de analogie te bewaren met de ontvangstmodule. Java bleek voor de ontvangstmodule de geschikte keuze. Dit komt aan bod in paragraaf 5.4.2. Het C-gedeelte zal instaan voor de low-level operaties en het eigenlijke inbrengen van de private sections met de triggers en de signalisatie. Het deel in Java zal gebruikt worden om een grafische gebruikersinterface aan te bieden. De communicatie tussen beide delen zal opgezet worden met behulp van de Java Native Interface (JNI). Figuur 5.5 illustreert dit. De interface fungeert als een doorgeefluik om programma’s in Java en andere “native” talen zoals C, C++ of Assembler met elkaar te laten communiceren. JNI werkt in twee richtingen: het is zowel mogelijk om vanuit Java C-methodes en C-bibliotheken aan te roepen, als om vanuit C gebruik te maken van Java-methodes, -objecten en -klassen. Vanuit C kunnen zelfs Java-objecten aangemaakt worden. Via de Java-GUI kan de gebruiker nieuwe events defini¨eren en tijdens het bekijken van de video de ogenblikken bepalen waarop eventuele events moeten optreden. Deze informatie wordt via de JNI doorgegeven aan het C-gedeelte. Op basis hiervan worden de juiste private sections aangemaakt en toegevoegd aan de TS. In wat volgt, wordt gestart met de bespreking van het deel in C. Dit vormt een fundamenteel deel van de implementatie van het raamwerk en is zodoende het hoofddoel van deze scriptie.
5.3 Het raamwerk aan de zenderzijde
58
JAVA GRAFISCHE GEBRUIKERSINTERFACE
JAVA NATIVE INTERFACE
C INBRENGEN TRIGGERS & SIGNALISATIE
Figuur 5.5: Java Native Interface als doorgeefluik tussen Java en C
Het deel in Java dient eerder beschouwd te worden als een grafische gebruikersinterface om een demo-applicatie te kunnen ontwerpen. Zodoende zal dit deel slechts beknopt besproken worden.
C-schil Het C-luik omvat de functies die nodig zijn voor het opvullen van de private sections, het genereren van de triggers en het inserteren in de TS. Het bestaat uit een 10-tal bestanden4 , waarvan de onderlinge samenwerking verduidelijkt wordt in figuur 5.6. De functionaliteit is tweeledig. Enerzijds is er het input/output gedeelte, waarin de TS ingelezen, gebufferd, ontleed en opnieuw weggeschreven wordt. Anderzijds is er de logica van het triggermechanisme, die de private sections met de signalisatie en de triggers aanmaakt. Het bestand processTS.c neemt de verwerking van de TS en het toevoegen van de private sections op zich. addTriggers.c vormt de interface naar het Java-gedeelte. In de nu volgende bespreking wordt een top-down benadering gevolgd. Eerst wordt de globale samenhang tussen de twee grote delen en de rol van processTS.c5 en addTriggers.c daarin verduidelijkt. Daarna wordt dieper ingegaan op de concrete implementatie van beide delen. 4 5
Aangevuld met de nodige header-files. In wat volgt wordt de bestandsnaam gebruikt als een verzamelnaam voor de functionaliteit van de erin
gedefinieerde methoden. Op die manier kan het soms lijken of een bestand een soort module vormt die op zichzelf functioneert. C is evenwel geen object-georienteerde taal. “Bestand X.c” dient men daarom eerder te lezen als “de functies in bestand X.c”.
5.3 Het raamwerk aan de zenderzijde
59
Java Native Interface
addtriggers.c
processTS.c
ts.c - ontleed PAT - ontleed PMT - ontleed STC
bue f r.c
inputoutput.c
bue f r.c
I/O-gedeelte
inputoutput.c
toevoegen private section triggerlogica triggercontrol.c
event.c
signaling.c bytes voor private section
Figuur 5.6: Opbouw van het C-luik van de zendmodule
Globale werking Het C-programma is grotendeels gebouwd op twee structuren, de TSDescriptor en de fileHandler. Ze worden gebruikt om informatie tussen methodes onderling uit te wisselen en maken het op die manier mogelijk dat het I/O-gedeelte en de triggerlogica met elkaar communiceren. In de TSDescriptor wordt alle nuttige informatie over de TS bijgehouden. Hij bevat o.a. de STCwaarde van het laatst verwerkte transport pakket, de huidige waarde van alle NPT-tijdsbases6 , een PMTDescriptor en een PATDescriptor. Naar analogie met de TSDescriptor bevatten die laatste twee structuren alle relevante informatie uit de PMT of de PAT. Elke keer een nieuwe tabel in de TS voorkomt, wordt de corresponderende descriptor bijgewerkt. De TSDescriptor zal ook gebruikt worden door de triggerlogica om informatie (over o.a. de tijdsbases) op te halen en weg te schrijven. We merken nog op dat deze structuur de weg open laat naar bv. een uitbreiding tot Multi-Program Transport Streams. Het volstaat om elke service in die stream 6
Er is slechts 1 tijdsbasis actief, de overige zijn gepauzeerd.
5.3 Het raamwerk aan de zenderzijde
60
een eigen TSDescriptor te geven. De fileHandler is de tweede fundamentele structuur en bevat pointers naar het in- en uitvoerbestand en de corresponderende in- en uitgangsbuffers. Zodra de gebruiker via de grafische Java-interface de opdracht gegeven heeft om de triggers toe te voegen aan de TS, wordt alle relevante informatie vanuit Java doorgegeven aan addTriggers.c. Dit bestand is het C-deel van de JNI-interface en vormt het toegangspunt voor de Java-GUI naar het eigenlijke C-programma. Vanuit addTriggers.c worden dan de nodige C-functies verder opgeroepen. In eerste instantie wordt alle Java-informatie ge¨ınterpreteerd: welke events zijn er gedefinieerd, wanneer treedt welk event op en hoe moeten de triggers in de stream terecht komen (als do-itnow of als scheduled-event)? Deze informatie wordt doorgegeven aan triggercontrol.c, zodat die module de gepaste bytes kan genereren die in de private sections moeten terechtkomen. Vervolgens wordt de controle overgedragen aan processTS.c, die de eigenlijke verwerking van de TS op zich neemt. processTS.c laat het I/O-gedeelte pakket per pakket inlezen. Op basis van het PID-nummer van dat pakket wordt beslist welke verdere acties moeten ondernomen worden. Bevat het pakket een STC-waarde, dan wordt die ingelezen in de TSDescriptor. Bij een pakket met een PAT of een PMT wordt de PAT- of PMT-descriptor ge¨ updated. De meeste pakketten worden daarna ongewijzigd terug weggeschreven naar het uitvoerbestand door het I/O-gedeelte. Enkel indien een pakket met een PMT wordt gedetecteerd, wordt een bijkomende actie ondernomen en zal een private section worden toegevoegd, volgens het principe ge¨ıllustreerd in figuur 5.2. processTS.c bepaalt autonoom of die private section signalisatie of triggers zal bevatten. Vervolgens vraagt processTS.c de nodige bytes op bij de triggerlogica om deze private section aan te maken. Na het toevoegen van de private section wordt ook dit pakket weggeschreven. Zodra alle pakketten op deze manier verwerkt zijn, krijgt het Java-programma opnieuw de controle en zal een bevestigingsboodschap getoond worden aan de gebruiker. I/O-gedeelte Dit deel staat in voor het in- en uitlezen van de TS en het ontleden van de informatie in de pakketten. Het maakt intensief gebruikt van de fileHandler-structuur. In deze scriptie wordt vertrokken van een bestaande TS. Hoewel het bestand dus al volledig op een lokaal medium aanwezig is, werd er toch een invoer- en uitvoerbuffering ge¨ımplementeerd. Dit heeft niet alleen een gunstig effect op de performantie [34], het laat ook de weg open voor een eventuele uitbreiding waarin de TS gestreamd wordt over het netwerk en de triggers in real-time moeten toegevoegd
5.3 Het raamwerk aan de zenderzijde
61
worden. In zo’n geval is een invoerbuffer noodzakelijk om de inkomende pakketten op te vangen tot ze kunnen verwerkt worden. De verwerkte pakketten worden opgeslagen in de uitvoerbuffer vooraleer ze verder verzonden worden naar de ontvanger. De nodige logica voor de buffers werd reeds voorzien en kan gemakkelijk worden overgenomen en aangepast. Naast de logica om bestanden in- en uit te lezen, bevat dit deel de nodige functies om de (originele) TS pakket per pakket te ontleden en te interpreteren. Dit proces wordt gestuurd door processTS.c. Per pakket wordt op basis van het PID-nummer de gepaste functie opgeroepen. Hieronder worden de verschillende c-bestanden apart besproken, zonder daarbij in het grootste detail te gaan. buffer.c Dit bestand bevat alle nodige functies voor het beheer van de buffers. Er zijn functies voorzien om nieuwe data in de buffer te laden, om een of meerdere bytes op te vragen, of om data rechtstreeks van de invoer- naar de uitvoerbuffer te kopi¨eren. Met elke buffer wordt een index verbonden, die de positie bijhoudt van de volgende uit te lezen byte (invoerbuffer) of weg te schrijven byte (uitvoerbuffer). Elke keer een byte uit de invoerbuffer wordt opgevraagd, wordt deze automatisch gekopieerd naar de uitvoerbuffer. Hierbij is de mogelijkheid voorzien om deze byte te vervangen door een andere byte. Deze functie zal intensief gebruikt worden om stuffing bytes in de pakketten met een Program Map Table te vervangen door private sections. In dit bestand zijn verder nog functies voorzien die de gepaste acties ondernemen wanneer alle data in de invoerbuffer is ingelezen of de uitvoerbuffer volledig gevuld is. De invoerbuffer wordt dan gevuld met nieuwe data, de uitvoerbuffer volledig weggeschreven naar het uitvoerbestand. inputoutput.c Dit bestand bevat functies om bestanden correct te openen en te sluiten. Bij het openen van een nieuw invoer- of uitvoerbestand wordt automatisch een invoer- resp. uitvoerbuffer aangemaakt en worden de nodige pointers naar de bestanden en de buffers aangevuld in de fileHandler. Bij het sluiten van een uitvoerbestand wordt er voor gezorgd dat de uitvoerbuffer eerst volledig wordt weggeschreven. ts.c Dit is het meest uitgebreide bestand in de bibliotheek. Het bevat alle functies om de TS volledig te ontleden. Allereerst moeten de individuele transport pakketten onderscheiden worden in de bytestroom van de TS. Dit is mogelijk via een functie die op zoek gaat naar de speciale synchronisatiebyte die de start van elk nieuw transport pakket aangeeft. Na deze synchronisatie
5.3 Het raamwerk aan de zenderzijde
62
kan de eigenlijke ontleding van elk pakket in de TS starten. Er is daarbij enkel geweten dat het startpunt van de decodering te vinden is in een transport pakket met PID 0x00 en dat dit pakket een PAT bevat. Zodra de eerste PAT in de stream ontdekt is, is het PID van de PMT bekend en kan op zoek gegaan worden naar het eerstvolgende pakket met een PMT. Voor al deze taken werden de nodige functies ontwikkeld. Er werd daarbij aandacht geschonken aan mogelijke synchronisatieproblemen: wanneer door een fout in het bestand (of de transmissie) de opeenvolgende transport pakketten niet exact 188 byte na elkaar volgen, dient de synchronisatie eerst opnieuw hersteld te worden alvorens de verwerking kan verdergaan. Eens de PAT en de PMT teruggevonden en geanalyseerd zijn, is alle nodige informatie voor een correcte interpretatie beschikbaar en kan overgegaan worden naar de tweede fase waarbij pakket per pakket wordt ingelezen en ontleed. Er werden functies toegevoegd die de nodige acties ondernemen wanneer een PAT, een PMT of een transport pakket met een STC gedetecteerd wordt. Telkens wordt de relevante informatie uit deze pakketten opgespoord en bijgewerkt in de TSDescriptor. De functie-oproepen worden geco¨ordineerd door processTS.c, op basis van het PID-nummer. Triggerlogica Het tweede grote deel van het C-programma bevat alle logica om het volledige triggermechanisme te beheersen. Het heeft als primaire taak om de bytes aan te maken die in de private sections moeten terechtkomen, zowel voor de signalisatie als voor de eigenlijke triggers. Hier komt heel wat bij kijken. Ten eerste moet de informatie, doorgegeven vanuit het Java-programma, correct ge¨ınterpreteerd worden. Verder moeten de nodige tijdsbases (NPT) ondersteund worden. Indien een do-it-now event optreedt, moet de corresponderende trigger op het juiste moment, en enkel dan, aan de TS toegevoegd worden. Bij een scheduled-event mogen de triggers slechts verstuurd worden tot het event is opgetreden. Het is de taak van processTS.c om de private sections correct op te vullen, volgens de syntax uit paragraaf 5.1.2. Hiervoor wordt beroep gedaan op de functies die aangeboden worden in triggercontrol.c. Ze bieden een antwoord op al de opgesomde kwesties. triggercontrol.c is het eigenlijke brein van de triggerlogica en steunt op twee andere modules, signaling.c en event.c. Zoals hun naam doet vermoeden, bevatten zij de nodige functies voor het beheer van de signalisatie respectievelijk het optreden van de events. triggercontrol.c Deze module vormt een interface die de onderliggende complexe structuur van signaling.c en event.c afschermt voor de gebruikers. De functies ervan zullen worden gebruikt door addTrig-
5.3 Het raamwerk aan de zenderzijde
63
gers.c bij het verwerken van de Java-informatie en door de module processTS.c bij het eigenlijke toevoegen van de triggerinformatie. Ze laten o.a. toe om nieuwe events te defini¨eren en nieuwe tijdsbases toe te voegen of de actieve tijdsbasis te wijzigen. Verder beheert deze module het toewijzen van de eventID’s aan nieuwe events en zorgt ze ervoor dat de geschikte bytes gemakkelijk kunnen worden opgevraagd bij het opvullen van een nieuwe private section. signaling.c De belangrijkste taak van deze module is het bijhouden van een lijst met alle gedefinieerde events. Figuur 5.7 toont hoe deze lijst is samengesteld uit twee types gelinkte lijsten.
ContentID = 1 # events = 3
ContentID = 2 # events = 1
ContentID = 3 # events = 2
EventID = 5
EventID = 3
EventID = 6
signalisatie bytes
signalisatie bytes
signalisatie bytes
EventID = 2
Lijst eerste type
signalisatie bytes
Lijst tweede type
EventID = 4
EventID = 1
signalisatie bytes
signalisatie bytes
Figuur 5.7: Opbouw van de signalisatie op basis van twee types gelinkte lijsten
Een gelinkte lijst is een gekende structuur in C. De elementen bevatten elk een pointer naar het volgende element in de lijst. Zo kunnen gemakkelijk elementen tussengevoegd of verwijderd worden. De gedefinieerde events worden geordend per tijdsbasis. De elementen van de gelinkte lijst van het eerste type stellen elk ´e´en tijdsbasis voor, met een uniek contentID-nummer. Naast dit contentID bevatten ze ook het aantal events dat die tijdsbasis gebruikt en twee pointers. De eerste pointer refereert naar het volgende element in de contentID-lijst (volgens het principe van
5.3 Het raamwerk aan de zenderzijde
64
de gelinkte lijst), de tweede verwijst naar het eerste element van een gelinkte lijst van het tweede type. Per contentID is er een lijst van het tweede type. Elk element ervan stelt een ander event voor en bevat o.a. de bytesequentie die in de private section moet komen. Bij het opvullen van de private sections met signalisatie zijn het deze sequenties die gekopieerd worden. Deze ingewikkelde structuur met twee types gelinkte lijsten, kan misschien wat “overkill” lijken, maar ze bouwt wel heel wat flexibiliteit in. Door een eenvoudige aanpassing van enkele pointers kunnen gedefinieerde events of niet meer ondersteunde tijdsbases verwijderd worden uit de lijst. Verder laat de ordening per tijdsbasis toe dat de private sections met de signalisatie effici¨enter kunnen opgevuld worden. Zoals aan bod kwam in paragraaf 5.1.2 worden de events daarin immers eveneens gegroepeerd per tijdsbasis. Het bestand signaling.c bevat de nodige functies om een nieuw event toe te voegen aan de lijst, een nieuwe contentID aan te maken of een event uit de lijst te verwijderen. Verder houdt het een index bij die telkens het volgende event aanwijst dat zal gesignaleerd worden. Zodra de bytes van dat event in de private section zijn opgenomen, wordt de index verplaatst naar het volgende element. event.c Deze module is het analogon van de module signaling.c, maar dan voor de triggering i.p.v. de signalisatie van de events. Ze houdt o.a. de bytes bij van de triggers die in de private sections moeten terecht komen. De triggers voor de do-it-now events komen terecht in een First Come First Serve-wachtlijn (FCFS-queue). Zodra een do-it-now event optreedt, komt een trigger in deze wachtrij terecht. Op het ogenblik dat een nieuwe private section met triggerbytes moet gevuld worden, wordt deze rij geledigd. Er kunnen ondertussen immers nog do-it-now events zijn gegenereerd7 . Voor de scheduled events wordt gebruik gemaakt van een (enkelvoudige) gelinkte lijst. Net zoals bij de lijsten in signaling.c wordt een index bijgehouden, die de volgende trigger (het volgende element in de lijst) aanwijst die in de private section zal terechtkomen. Dit hoeft in dit geval echter niet lineair te gebeuren. Elke trigger heeft een prioriteit, die kan gebruikt worden bij het verplaatsen van de index. Triggers met een hogere prioriteit worden dan vaker aangewezen. Een wijziging van de prioriteit van een trigger is zelfs mogelijk tijdens het programma. Men kan bijvoorbeeld een aantal seconden voor het optreden van een event de 7
Er werd reeds vermeld dat het wachten op het eerstvolgende pakket met een PMT een delay veroorzaakt.
In een eventuele uitbreiding kan er meteen een pakket met een private section tussengevoegd worden zodra een do-it-now event optreedt. In zo’n geval wordt een wachtlijn overbodig.
5.3 Het raamwerk aan de zenderzijde
65
prioriteit van de trigger verhogen, zodat de settop-box van een TV-kijker die net voor het event inschakelt, toch nog de triggers voor dit event correct kan interpreteren en de gepaste actie kan ondernemen8 . In paragraaf 5.2 werd uitgelegd dat deze scriptie zich niet concentreert op het real-time aspect. Er werd toen aangehaald dat bij zo’n model zuivere do-it-now events niet kunnen voorkomen. Het programma is immers vooraf opgenomen en alle tijdstippen van events zijn dus gekend. Een trigger voor een do-it-now event bevat echter geen tijdsindicatie. Om toch do-it-now events te simuleren werd in het C-luik van de zendmodule een tweede wachtrij voorzien. In die rij komen alle triggers van do-it-now events terecht, in volgorde van optreden. Hoewel het om een do-itnow event gaat, wordt voor elke trigger toch de NPT-waarde bepaald van het ogenblik waarop het bijhorende event moet optreden. Telkens de NPT-tijd wordt bijgewerkt9 , wordt op basis van die tijdswaarde bepaald of de trigger naar de FCFS-queue in event.c moet overgebracht worden. Dit proces wordt herhaald voor de volgende triggers in de rij. De triggers verhuizen naar de FCFS-queue, tot er met de volgende trigger in de rij een NPT-waarde verbonden is die groter is dan de huidige NPT. Die trigger en de volgende in de rij worden pas later in de FCFS-queue opgenomen.
Java-GUI De grafische gebruikersinterface van de zender werd in Java geprogrammeerd. In figuur 5.8 wordt een screenshot getoond. Het hoofdvenster bestaat uit twee delen: in het ene wordt de video weergeven, het andere bevat knoppen om de events te genereren op de gewenste ogenblikken. Via een compact menu kan de gebruiker een videobestand openen en nieuwe events defini¨eren. Hij geeft hierbij een naam voor het event op, evenals welke tijdsbasis dit event zal gebruiken. Verder moet aangegeven worden hoe het event moet getriggerd woden. Bij een do-it-now event wordt slechts ´e´en maal een trigger verstuurd, nl. op het moment dat het event moet optreden; bij een scheduled-event wordt de trigger een aantal keer voorafgaand aan het ogenblik van optreden doorgestuurd. Er kan ook een overzicht van de gedefinieerde events opgevraagd worden. De gebruiker bekijkt de videobeelden en op het ogenblik dat hij een event wenst te laten optreden, drukt hij op de corresponderende knop. Onder elke knop is een veld voorzien waarin de 8
De ontvanger moet wel eerst de signalisatie van een event ontvangen hebben vooraleer hij de triggers correct
kan interpreteren. 9 Dit is elke keer een pakket met een STC-waarde wordt gedetecteerd.
5.3 Het raamwerk aan de zenderzijde
66
genereren events
Figuur 5.8: Een screenshot van de zendmodule
gebruiker private data met de triggers van dit event kan meegeven. Dit veld kan dus elke keer een event optreedt, een andere inhoud hebben. Eens het volledige programma is bekeken en alle tijdstippen van de events zijn bepaald, kan de gebruiker de triggers laten toevoegen aan de TS. Op dat ogenblik wordt alle nodige informatie doorgegeven aan het C-gedeelte, die op basis hiervan de gepaste private sections met de triggers en de signalisatie inserteert. Er wordt een bevestigingsboodschap getoond indien dit succesvol verlopen is. Er zijn twee mogelijkheden om videobeelden in Java weer te geven: het Java Media Framework [35] en QuickTime for Java (QTJ) [36]. In de zendmodule moet de video enkel kunnen afgespeeld worden en zijn beide opties aanvaardbaar. QTJ bleek evenwel beter geschikt te zijn voor de ontvangstmodule, waar nog extra eisen aan de videospeler gesteld worden. Dit komt aan bod bij de bespreking van het Java-gedeelte van de ontvangstmodule in de paragraaf Java-GUI op pagina 71. Om de analogie te bewaren tussen zend- en ontvangstmodule werd ook in de zendmodule QTJ gebruikt. Het Java-gedeelte is louter een grafische gebruikersinterface en bevat niet echt fundamenteel belangrijke functionaliteit voor de implementatie van het raamwerk. Een uitvoerige bespreking zou weinig relevant zijn en wordt daarom beknopter gehouden dan bij het C-luik. Voor de implementatie werd gebruik gemaakt van de Swing-bibliotheek. Dit is een onderdeel van de Java Foundation Classes, een verzameling klassen die alle nodige instrumenten bevat om grafische
5.3 Het raamwerk aan de zenderzijde
67
omgevingen en gebruikersinteractiviteit aan te bieden. Swing bevat de nodige componenten om een grafische omgeving te bouwen, zoals knoppen, invulvelden en menubalken. Wat het triggermechanisme betreft, staat het luik in Java enkel in voor de definitie van de mogelijke events en het cre¨eren van objecten die het optreden van deze events voorstellen. De bijhorende triggers worden opgesteld door het C-programma, op basis van de informatie die het krijgt vanuit het Java-gedeelte. Hieronder worden de belangrijkste eigenschappen en functies van elke klasse kort besproken. De samenhang tussen de verschillende klassen van de zendmodule wordt verduidelijkt in figuur 5.9.
geef overzicht gedefinieerde events
Sender
OverviewDialog
knop ingedrukt NPT
nieuw event gedefinieerd
parameters nieuw event
maak nieuwe knop aan
EventDialog
doorgevensjilt
definieer nieuw event
SignalledEvent EventButton
TriggeredEvent
aanmaken nieuwe knop
Java Native Interface
Figuur 5.9: Samenhang tussen de Java-klassen van de zendmodule
Sender Deze klasse vormt de kern van de grafische gebruikersinterface en staat in voor de opbouw en lay-out van het frame van de applicatie. Vanuit de klasse Sender worden de overige klassen op de gepaste ogenblikken opgeroepen. Wanneer de gebruiker een nieuw event wenst te defini¨eren, maakt Sender een object aan van de klasse EventDialog. Als hij een overzicht wil van alle gedefinieerde events, wordt een object van de klasse OverviewDialog gecre¨eerd.
5.3 Het raamwerk aan de zenderzijde
68
Indien een event wordt gegenereerd door een druk op de knop, wordt een object uit de klasse TriggeredEvent aangemaakt. OverviewDialog Een object uit deze klasse stelt het dialoogvenster voor dat wordt weergegeven wanneer de gebruiker een overzicht wenst van alle gedefinieerde events. Het overzicht wordt opgesteld op basis van een lijst met alle mogelijke events in de klasse SignalledEvent. Per event worden naam, contentID en eventID weergegeven. EventDialog Een object uit deze klasse stelt het dialoogvenster voor dat wordt weergegeven wanneer de gebruiker een nieuw event wenst te defini¨eren. Zodra alle gegevens ingevuld zijn en de gebruiker heeft bevestigd, worden deze data doorgegeven aan de klasse Sender. Die maakt op basis hiervan een object aan uit de klasse SignalledEvent. Op basis van dat object wordt vervolgens een object uit de klasse EventButton aangemaakt. Er verschijnt een extra knop in het hoofdvenster, verbonden met dit laatste object. EventButton De objecten van deze klasse vertegenwoordigen de knoppen uit het hoofdvenster om events te genereren. Zodra de gebruiker via een dialoogvenster (EventDialog) een event gedefinieerd heeft, wordt een EventButton-object aangemaakt en verschijnt een knop in het hoofdvenster. Zo’n object bevat niet alleen een SignalledEvent-object, maar ook een JTextField. Dit tekstvak wordt gebruikt om eventuele private data mee te geven met de triggers. SignalledEvent Een object uit deze klasse stelt een gedefinieerd event voor. Elk object krijgt een naam, eventID en contentID en bevat dus de nodige informatie voor de signalisatie en de triggers van dit event. De klasse houdt een lijst bij van alle aangemaakte objecten. Op basis hiervan kan de klasse OverviewDialog een overzicht weergeven van alle gedefinieerde events. Deze lijst wordt ook geraadpleegd door het C-programma om de gepaste data op te vragen. Hiervoor werd een specifieke methode toegevoegd om de lijst op een veilige10 manier te doorlopen. Het is logischer om de toegang tot een Java-object te laten beheren door het Java-luik dan door het C-luik. Het doorgeven van de lijst tussen Java en C kan op die manier effici¨enter verlopen. TriggeredEvent Terwijl de objecten van de klasse SignalledEvent de mogelijke events vertegenwoordigen die 10
De index die gebruikt wordt bij het doorlopen van de lijst mag zijn onder- en bovengrens niet overschrijden.
5.4 Het raamwerk aan de ontvangerzijde
69
moeten gesignaleerd worden, stelt een object uit de klasse TriggeredEvent eerder het eigenlijke optreden van een event voor. Naast een tijdstip van optreden heeft een TriggeredEventobject nog een eventID en eventueel extra private data. Op basis van deze objecten zal het C-programma de gepaste triggers aanmaken en in de TS inbrengen. Telkens een knop in het hoofdvenster wordt ingeduwd, wordt een object aangemaakt. Op dat ogenblik bepaalt de klasse Sender de mediatijd (NPT), zodat samen met de datavelden van het EventButton-object van de ingedrukte knop een TriggeredEvent kan worden geconstrueerd. Dit object wordt dan toegevoegd aan de lijst met do-it-now of scheduled events. Net zoals in de klasse SignalledEvent werden enkele methodes voorzien die het voor het C-programma vergemakkelijken om deze lijsten te raadplegen.
5.4
Het raamwerk aan de ontvangerzijde
De ontvangstmodule is het tweede deel van de ontwikkelde principi¨ele implementatie. Bij de bespreking wordt grotendeels dezelfde opbouw gevolgd als bij de zendmodule. Na een opsomming van de vereisten wordt de eigenlijke implementatie behandeld. Bij het ontwerp van de ontvangstmodule werd er van uitgegaan dat er al een TS met triggers op een lokaal medium beschikbaar is, cfr. paragraaf 5.2. Het streamen over een netwerk wordt niet beschouwd. Daardoor is er ook geen on-the-fly verwerking van de pakketten. De TS wordt eerst helemaal ontleed om de triggers te detecteren en pas daarna wordt het bestand een tweede maal ingelezen om de video weer te geven.
5.4.1
Functies van de ontvangstmodule
De module moet in staat zijn om de private sections met triggers en signalisatie in de TS te detecteren. Uiteraard moeten ook de video en de gepaste events kunnen weergegeven worden. Filteren van de triggers. De module moet een soort filter bevatten om de private
sections in de TS te detecteren en te interpreteren. Bij het ontvangen van signalisatieinformatie dienen de nodige updates te gebeuren. Do-it-now triggers moeten meteen doorgegeven worden naar de grafische omgeving om het event te kunnen weergeven. Triggers voor scheduled-events vragen iets meer werk. Aangezien meerdere triggers voor hetzelfde event verzonden worden, moet bij ontvangst van zo’n trigger eerst nagegaan worden
5.4 Het raamwerk aan de ontvangerzijde
70
of de trigger reeds eerder gedetecteerd werd. Mocht elke ontvangen trigger zonder meer doorgegeven worden aan de grafische omgeving, dan zou een event op hetzelfde ogenblik meermaals optreden. De grafische interface geeft de events weer enkel op basis van de ontvangen triggers en kijkt zelf niet na of de trigger een duplicaat is van een eerder ontvangen trigger. Een vergelijking met vroegere triggers louter op basis van het eventID volstaat overigens niet. Hetzelfde event kan nl. meermaals, op verschillende ogenblikken, optreden tijdens het programma. Er moet een ondubbelzinnige detectie gebeuren op basis van het eventID ´en de NPT-waarde in de trigger. Weergeven van de events. De ontvangstmodule wordt gezien als een soort simulator
voor de combinatie van TV en settop-box bij de eindgebruiker. Naast het weergeven van de videobeelden moet ook logica voorzien worden om de events op het gepaste ogenblik te laten optreden. Dit vereist een nauwkeurige synchronisatie met de NPT-tijdsbasis en een geavanceerde grafische omgeving. Een event manifesteert zich typisch als het verschijnen van een bepaalde figuur bovenop de videobeelden, zoals een rode stip. Deze ogenschijnlijk eenvoudige operatie blijkt echter door weinig grafische omgevingen stabiel te worden ondersteund.
5.4.2
Opbouw van de ontvangstmodule
Uit de bespreking van de vorige paragraaf blijkt dat de taken van de ontvangstmodule heel divers zijn. Net zoals bij de zendmodule is de opbouw tweeledig opgevat. Het filteren van de private sections is ge¨ımplementeerd in C, het weergeven van de video en de events gebeurt in een Java-omgeving. Beide onderdelen zullen ook hier communiceren via de Java Native Interface. In tegenstelling tot de zendmodule, ligt het zwaartepunt van de ontwikkeling nu bij het Javagedeelte. Voor het luik in C kon de code van de zendmodule gemakkelijk overgenomen en aangepast worden. Omwille van deze analogie zal de bespreking van het C-luik beknopt gehouden worden. Het luik in Java wordt uitgebreider besproken wegens de grotere complexiteit. Naast het weergeven van de video moet er immers ook voor gezorgd worden dat de events op de juiste ogenblikken optreden. Zoals reeds vermeld in de vorige paragraaf is dit een complexe grafische operatie. C-schil Dit luik is identiek opgebouwd als het input/output-deel van de C-schil van het zendgedeelte
5.4 Het raamwerk aan de ontvangerzijde
71
(cfr. figuur 5.6). Het leest pakket per pakket in en onderneemt de gepaste acties op basis van het PID-nummer. De nodige informatie wordt net zoals bij de zendmodule opgeslagen in een TSDescriptor-structuur. De enige aanpassingen t.o.v. het I/O-gedeelte van de zendmodule zijn de toegevoegde functies om private sections te kunnen ontleden. Bij de zendmodule kwam op deze plaats de triggerlogica tussen om de private sections toe te voegen. Als een private section gedetecteerd wordt, maakt het C-programma - via de Java Native Interface - de gepaste Java-objecten aan. Een gesignaleerd event resulteert in een SignalledEventobject en een trigger wordt voorgesteld door een Trigger-object. Met deze objecten worden dan de events op het gepaste ogenblik weergegeven. Het C-programma werd verder nog voorzien van de gepaste beveiliging: triggers worden pas effectief verwerkt indien de nodige signalisatie ontvangen werd. Java-GUI Figuur 5.10 toont een screenshot van de ontvangstmodule. De gebruiker kan een videobestand
weergave tekst weergave figuren
eventkeuze afspeelsnelheid
Figuur 5.10: Een screenshot van de ontvangstmodule
openen en de triggerinformatie in de bijhorende TS wordt automatisch ingelezen. Er kunnen gedetailleerde statistieken opgevraagd worden van alle events die de applicatie ondersteunt en van de events die daadwerkelijk optreden tijdens het programma. Niet alle events hoeven immers in elke TS voor te komen. In de controlebalk onderaan zijn knoppen voorzien om de video te
5.4 Het raamwerk aan de ontvangerzijde
72
starten, te stoppen en terug te spoelen. Ook de snelheid waarmee de video afgespeeld wordt, kan ingesteld worden. Zo kan de gebruiker er zich van vergewissen dat de relatieve tijdspositie van de events behouden blijft als de video bv. aan dubbele snelheid wordt afgespeeld11 . Daarnaast kan de gebruiker in een menu kiezen welke events hij wenst weer te geven. Op die manier kan een applicatie gesimuleerd worden die zich slechts inschrijft voor enkele van de gesignaleerde events in de TS. De keuze voor Java als programmeertaal voor de GUI werd ingegeven door de wens van Belgacom om te beschikken over een Java-gebaseerde applicatie, zoals beschreven in paragraaf 2.1.1. Er kwam reeds aan bod dat de grafische omgeving twee taken moet kunnen vervullen. Het videobestand moet kunnen weergegeven worden, maar belangrijker is dat het mogelijk moet zijn om een soort laag bovenop de video te defini¨eren waarop de events getoond worden. Dit kunnen zowel tekst als figuren zijn. Figuur 5.11 illustreert dit.
Figuur 5.11: De events worden weergegeven op een laag boven de video
Voor het weergeven van MPEG-2 videobeelden bestaan twee mogelijkheden: QuickTime for Java (QTJ, [36]) en het Java Media Framework (JMF, [35]). JMF is het door Sun ontwikkelde multimediaplatform voor Java. Dankzij een meerlagenmodel kan gebruik gemaakt worden van deze API voor het verwerken van multimedia binnen een Java-programma, zonder verlies aan flexibiliteit en uitbreidbaarheid. Dit is nodig voor de ondersteuning van geavanceerde applicaties en toekomstige technologie¨en. De functionaliteit kan nog uitgebreid worden door het toevoegen van eigen componenten zoals codecs of multiplexers. JMF is beschikbaar in vier versies: een platformonafhankelijke versie en platformafhankelijke versies voor Solaris, Windows en Linux. De implementatie van die laatste versies steunt gedeeltelijk op het onderliggende besturingssys11
Dit was precies een van de redenen om een NPT-tijdsbasis te voorzien.
5.4 Het raamwerk aan de ontvangerzijde
73
teem om een betere performantie en functionaliteit te garanderen12 . In JMF wordt standaard MPEG-1 ondersteund, maar geen MPEG-2. De platformafhankelijke versies kunnen gebruik maken van externe codecs. Door de installatie van bv. de Elecard Codec [37] kunnen toch MPEG-2 Program en Transport Streams weergegeven worden. In principe kunnen met een JLayeredPane grafische objecten boven elkaar weergegeven worden. Uit testen bleek echter dat het onmogelijk is om een object bovenop een JMF video-object weer te geven. De video verschijnt steeds bovenop alle andere objecten. Een verklaring daarvoor is allicht de (voorlopig nog) beperkte compatibiliteit tussen JMF en de Swing-bibliotheek. Een tweede reden kan het gebruik van de externe codec zijn. De tweede optie is QuickTime, het bekende platform voor de weergave van multimedia. Het werd ontwikkeld door Apple. Dankzij QuickTime for Java wordt dit platform ook toegankelijk voor ontwikkelaars van Java-applicaties. De technologie bestaat uit twee lagen. Een eerste laag biedt toegang tot de volledige QuickTime C bibliotheek. Een tweede laag vormt een objectgeori¨enteerd raamwerk bestaande uit een aantal klassen die het gebruik van QuickTime sterk vereenvoudigen. Methode-oproepen vanuit Java worden door die laag automatisch omgezet naar een standaard C-oproep. QTJ is om die reden duidelijk performanter dan het JMF, zelfs wanneer gebruik gemaakt wordt van een platformafhankelijke versie van JMF. QuickTime kan enkel MPEG-2 bestanden weergeven na de installatie van een aan te kopen plug-in. Deze codec is aanwezig bij de vakgroep INTEC, maar ondersteunt enkel Program Streams, geen Transport Streams. Dankzij het Compositor-object in QTJ kunnen grafische objecten op eenvoudige wijze boven elkaar weergegeven worden. Het is zelfs mogelijk om tekst bovenop de videobeelden te laten verschijnen. Bij de uiteindelijke keuze voor QTJ is dit laatste argument doorslaggevend gebleken. Het niet kunnen weergeven van een TS weegt niet op tegen de mogelijkheid om de events grafisch bovenop de videobeelden te kunnen tonen. Om toch videobeelden te kunnen tonen, maakt de ontvangstapplicatie gebruik van twee bestanden. Enerzijds is er de TS met de triggerinformatie, anderzijds moet er in dezelfde directory een MPEG-1 of een MPEG-2 PS bestand aanwezig zijn met dezelfde naam, op de extensie na. Dit laatste bestand wordt bekomen door een conversie van het TS-bestand. Deze werkwijze stelt voor deze scriptie geen problemen omdat enkel lokaal aanwezige bestanden beschouwd worden. Ondanks deze beperking kan zo toch onderzocht wor12
Merk overigens op dat deze platformafhankelijkheid indruist tegen de oorspronkelijke Java-filosofie om plat-
formonafhankelijk te zijn.
5.4 Het raamwerk aan de ontvangerzijde
74
den waar zich problemen voordoen bij het correct weergeven van de events. Dit is binnen deze scriptie van groter belang dan de weergave van een TS. Implementatie van het eventmechanisme In de volgende paragrafen wordt de implementatie van het eventmechanisme grondig besproken. De problemen die bij de ontwikkeling van de applicatie voorkwamen, worden behandeld. Bovendien worden enkele zaken gesignaleerd waarop moet worden gelet bij een professionelere uitbouw van een triggermechanisme. De triggers in de TS zorgen ervoor dat een applicatie op de settop-box bepaalde acties onderneemt. De applicatie zelf weet w´elke acties moeten ondernomen worden. De tijdstippen ervan worden echter bepaald door de triggers. Het raamwerk voorziet in een algemene structuur om nieuwe events te defini¨eren, zodat ze gemakkelijk en flexibel kunnen ingepast worden. In de ontwikkelde applicatie werd ter illustratie de code voor vier events voorzien, nl. het weergeven van een tekstfragment en het weergeven van een rood, groen of blauw vierkantje. De kleur kon natuurlijk ook gestuurd worden door private data, maar voor demonstratiedoeleinden werd besloten om hier drie aparte events van te maken. Elk event van de applicatie is een uitbreiding van de abstracte Event-klasse. Bij het opstarten van de applicatie worden een aantal nieuwe Event-objecten aangemaakt, louter op basis van een naam. Deze naam zal ook voorkomen in de signalisatie van de events. Er kunnen in de TS ook signalisatie en triggers aanwezig zijn voor events die niet ondersteund worden door de applicatie. Er is dan geen Event-object gedefinieerd met de naam die voorkomt in de signalisatie, en die informatie wordt genegeerd. Het eventID van elk Event wordt pas gedefinieerd op het moment dat de TS verwerkt wordt door het C-programma. Zo is een concrete invulling gegeven aan de ontkoppeling tussen de naam en het eventID van een event. Elk Event-object moet de methode startEvent() voorzien. Die methode bevat de code voor de acties die moeten ondernomen worden als het event optreedt. Dit gedrag kan gestuurd worden op basis van de private data die als argument wordt meegegeven bij de methode-oproep. Het beheer van de signalisatie berust bij de SignalingController. Als een nieuw videobestand wordt geopend, richt deze controller een oproep aan de C-bibliotheek om alle signalisatieinformatie uit de TS te filteren. Voor elk nieuw gesignaleerd event dat het C-programma in de TS ontdekt, wordt een SignalledEvent-object aangemaakt. Dit object wordt toegevoegd aan een lijst die beheerd wordt door de controller. Elke trigger in de TS geeft op zijn beurt aanleiding tot de creatie van een Trigger-object.
5.4 Het raamwerk aan de ontvangerzijde
75
Zo’n object bevat een eventID, private data, een Event-object en een tijdsindicatie wanneer dat Event moet optreden. Deze Triggers worden automatisch toegevoegd aan een lijst in de klasse TriggerList. Die laatste klasse staat in voor het beheer van de lijst en zorgt er o.a. voor dat meerdere triggers van een scheduled-event toch maar aanleiding geven tot ´e´en Trigger-object in de lijst. De ontvangstmodule moet verschillende taken simultaan vervullen. De video moet weergegeven worden en tegelijk moet op voldoend regelmatige basis nagekeken worden of er events moeten optreden. De eigenlijke vertoning van een event vormt een derde taak. Het ligt voor de hand om gebruik te maken van het concept van threads om aan deze eisen te voldoen. Elke taak vormt dan een aparte thread. Een processor werkt sequentieel en kan slechts ´e´en taak tegelijk uitvoeren. Door de processortijd te verdelen tussen verschillende taken lijkt het alsof meerdere taken in parallel afgewerkt worden. Bij een threadmechanisme wordt een tijdje gewerkt aan taak A, daarna aan taak B, vervolgens opnieuw aan taak A etc... Indien de afwisseling voldoende snel verloopt, krijgt de gebruiker de indruk dat alle taken tegelijk worden uitgevoerd, hoewel op elk moment slechts aan ´e´en taak tegelijk gewerkt wordt. In de ontvangstmodule worden twee threads gebruikt. Dit wordt getoond in figuur 5.12. Op de figuur worden enkel de twee threads van de applicatie getoond. De processor zal ook nog andere threads verwerken, o.a. van het besturingssysteem. wachtrij met grafische taken
-check NPT - indien nodig: startEvent() start timer
timer loopt af
Figuur 5.12: De twee threads van de ontvangstmodule
verwd jiereventvanscherm
Control Thread
toonevent
Event Dispatching Thread
5.4 Het raamwerk aan de ontvangerzijde
76
De eerste thread is de ControlThread en gaat op regelmatige basis de huidige videotijd na (polling). Hij start indien nodig de gepaste events via hun startEvent-methode. De tweede thread is de Event Dispatching Thread (EDT) van Java Swing, die instaat voor alle grafische taken, zoals het weergeven van de video. Het grafische gedeelte van de ontvangstmodule werd geprogrammeerd in Java Swing. In het Swing-model worden alle grafische taken vervuld door ´e´en thread: de EDT. Elke keer de gebruiker een knop indrukt, een menu opent, een venster minimaliseert... moeten allerlei grafische componenten hertekend worden. Deze taken komen in een wachtrij terecht en worden sequentieel afgewerkt door de EDT. Dit garandeert dat er geen inconsistenties optreden tussen de verschillende taken: de volgende grafische taak wordt pas aangevat als de vorige is afgewerkt. Zo worden situaties vermeden waarbij een component slechts half hertekend is, omdat het proces onderbroken werd door een andere taak. Anderzijds heeft deze aanpak als nadeel dat zware taken veel tijd in beslag nemen en zo de verwerking van de volgende taken in de wachtrij uitgesteld wordt. Indien bv. een grote berekening moet uitgevoerd worden als een menu geopend wordt, zal het een tijdje duren alvorens het menu opengeklapt op het scherm verschijnt. Dit leidt tot een minder alerte GUI. Dit nadeel woog bij de ontwikkeling van de Swing-bibliotheek blijkbaar niet op tegenover de voordelen van het gebruik van slechts ´e´en thread. Aangezien de EDT instaat voor rekenintensieve taken zoals het weergeven van de video13 , moet deze thread ook een voldoende groot aandeel van de processortijd toegewezen krijgen. Bij de ontwikkeling van een triggermechanisme kunnen de volgende aanwijzingen gevolgd worden: 1. Cre¨eer niet te veel threads. In een eerste testimplementatie was er geen centrale ControlThread voorzien, maar kreeg elk optredend event een eigen thread. Al deze threads raadpleegden voortdurend de videoklok om te bepalen of het event moest starten. Deze aanpak is echter niet houdbaar zodra het aantal events in een programma toeneemt. De processor moet dan door te veel threads gedeeld worden, waardoor de EDT niet voldoende snel zijn taken kan afwerken en het weergeven van de videobeelden met haperingen verloopt. Door het invoeren van een ControlThread wordt de videoklok eenmaal geraadpleegd en wordt vervolgens voor elk van de triggers (in de rij van de klasse TriggerList) gekeken of het overeenkomstige event moet gestart worden. Zo komt meer tijd vrij voor de EDT en verloopt het weergeven van de videobeelden vlotter. 2. Hou zoveel mogelijk rekenwerk buiten de EDT. Initialisaties en berekeningen kunnen beter 13
De weergave van een nieuw frame vormt een nieuwe taak in de wachtrij voor de EDT.
5.4 Het raamwerk aan de ontvangerzijde
77
in een andere thread gebeuren. Het weergeven van bv. een rode stip is echter een grafische operatie en moet dus zeker uitgevoerd worden door de EDT. De klasse SwingUtilities biedt een elegante oplossing. Voorafgaande berekeningen worden in een aparte thread uitgevoerd. Vanuit die thread wordt dan de methode SwingUtilities.invokeLater() opgeroepen met een Runnable-object als argument. De code in de run-methode van dat laatste object zal automatisch uitgevoerd worden door de EDT. In de run-methode komt enkel de code die nodig is om het event te laten verschijnen op het scherm. Intensieve berekeningen worden eerst in de andere thread uitgevoerd, waardoor de EDT ontlast wordt. 3. Bij het aflopen van een event moeten opnieuw een aantal grafische operaties gebeuren, zo moet bv. de rode stip of de tekst terug verdwijnen van het scherm. Dit kan door een gepast event te defini¨eren dat wordt gestart door de ControlThread. Deze methode verdubbelt echter het aantal events en lijkt daarom niet aangewezen. Het is beter om gebruik te maken van de Swing-klasse Timer. Tegelijk met het optreden van het event, wordt ook een Timer gestart, die afloopt op het ogenblik dat het event weer van het scherm moet verdwijnen. De Timer genereert een Swing-event14 . De afhandeling van zulke events gebeurt automatisch door de EDT. 4. Ondanks alle bovenstaande maatregelen om de EDT zoveel mogelijk te ontlasten, bleek toch nog een additionele ingreep noodzakelijk. De ControlThread bleef teveel processortijd opslorpen, zeker op tragere PC’s. Het relatieve aandeel van de ControlThread werd daarom beperkt. De thread vraagt de videoklok op, overloopt alle triggers en start de nodige events. Daarna moet de ControlThread een tijdje “slapen” en krijgt de EDT dus alle CPU-capaciteit15 . Door die slaapperiodes wordt de nauwkeurigheid van de ogenblikken waarop een event gestart wordt, beperkt. Deze onnauwkeurigheid is echter klein (orde 200 ms) t.o.v. de onnauwkeurigheid die ge¨ıntroduceerd werd door het versturen van de triggers in pakketten met een PMT (orde 500 ms). 14 15
Dit is typische Java-terminologie en is niet te verwarren met de getriggerde events in deze scriptie. We vermelden nogmaals dat nog andere threads van de processor gebruik zullen maken. In de bespreking
worden enkel de threads van de applicatie beschouwd.
5.5 Voorbeeldapplicatie
5.5
78
Voorbeeldapplicatie
Naast een principi¨ele implementatie van een zend- en ontvangstmodule, werd ook een concreet voorbeeld uitgewerkt, dat iDTV Foot gedoopt werd. Het in de praktijk toepassen van alle eerdere theoretische beschouwingen uit deze scriptie schenkt niet alleen persoonlijke voldoening en motivatie maar brengt ook sneller onvolkomenheden aan het licht. Meteen kan ook een beeld gevormd worden van de mogelijkheden die het raamwerk in de praktijk biedt. Figuur 5.13 toont een screenshot van de ontvangstmodule.
Figuur 5.13: Een screenshot van de iDTV Foot ontvangstmodule
De ontwikkelde toepassing biedt ondersteuning voor de uitzending van een voetbalmatch. Tijdens een wedstrijd gebeuren verschillende acties: doelpunten, overtredingen, gele en rode kaarten... Voor al die gebeurtenissen werden events gedefinieerd. De zender genereert per gebeurtenis een trigger voor het corresponderende event. De ontvangstzijde houdt al deze gegevens bij. Bemerk dat deze events off-screen events zijn, er verschijnt niks op het scherm als het event optreedt. Er werden ook enkele events gedefinieerd die wel zichtbaar zijn voor de ontvanger. Zo kan de zender het logo van een sponsor laten verschijnen bij de ontvanger, de tussenstand laten weergeven en zelfs een compleet overzicht laten weergeven met per ploeg het aantal overtredingen,
5.6 Besluit
79
doelpunten, rode kaarten... (zie figuur 5.13) Zowel grafische als tekstuele verschijningsvormen zijn dus voorzien. Het concept om via private data het eigenlijke optreden van een event te sturen werd eveneens opgenomen in de voorbeeldapplicatie. De zender moet bv. als private data opgeven welk sponsorlogo hij wil laten verschijnen. Bij een trigger voor het event “doelpunt gescoord” wordt als private data meegegeven wie het doelpunt gemaakt heeft. Deze namen verschijnen dan ook in het globaal overzicht dat wordt weergegeven.
5.6
Besluit
Een volwaardig raamwerk voor een triggermechanisme bestaat uit drie aspecten. Ten eerste moet er een protocol voorzien worden waarmee de triggers van de zender/broadcaster naar de ontvanger/TV-kijker kunnen verstuurd worden. Daarnaast moeten ook een zend- ´en een ontvangstmodule gebouwd worden die dit protocol implementeren. Het protocol gebruikt private sections om de triggers en de signalisatie te versturen. Er wordt een private section toegevoegd aan elk pakket met een Program Map Table. Als tijdsbasis wordt de Normal Playing Time gebruikt, overgenomen uit DSM-CC. De signalisatie wijst elk event een eventID toe en beheert de verschillende tijdsbases. Er werden descriptoren gedefinieerd voor de triggers. Private sections kunnen op die manier met de grootst mogelijke flexibiliteit opgevuld worden. De descriptoren kunnen ook private data bevatten. De triggers worden in de TS gebracht door de zendmodule. Deze bestaat uit een Java- en een C-gedeelte die met elkaar communiceren via de Java Native Interface. Het C-luik vervult de taken op bitniveau, het luik in Java fungeert als een grafische gebruikersinterface. De ontvangstmodule is een simulator voor de settop-box bij de TV-kijker. Ze bestaat eveneens uit een luik in C en een luik in Java. Het deel in C filtert de triggers en de signalisatie uit de TS. De grafische omgeving werd gebouwd in Java en QuickTime for Java. Het weergeven van de events is een complexe operatie waarbij gebruik wordt gemaakt van threads. Er werden een aantal aanbevelingen geformuleerd om de effici¨entie te verhogen. Het is belangrijk om de Event Dispatching Thread voldoende processortijd te gunnen door het aantal threads te beperken.
EVALUATIE VAN HET RAAMWERK
80
Hoofdstuk 6
Evaluatie van het raamwerk In dit hoofdstuk zal het raamwerk aan een kritische evaluatie onderworpen worden. In het eerste deel wordt de capaciteit van een private section berekend voor een typische situatie. Het tweede deel geeft aan op welke gebieden deze scriptie verder kan worden uitgediept.
6.1
Berekening van de capaciteit van een private section
In deze scriptie worden de private sections enkel toegevoegd aan transport pakketten die een PMT bevatten. De ruimte om triggerinformatie te versturen is dus beperkter dan wanneer aparte transport pakketten (met enkel een private section) zouden toegevoegd worden. Het is de bedoeling om in deze paragraaf de lezer een concreet beeld te geven over hoe beperkend deze factor is. Er zullen bij de bespreking een aantal veronderstellingen gemaakt worden. Deze worden steeds gemotiveerd. Een transport pakket bestaat uit 188 bytes. De eerste 4 bytes vormen een vaste header, zodat er 184 bytes overblijven voor de overige data. Als een transport pakket een sectie van een tabel bevat, dan is de 5de byte in het pakket een pointer. Die pointer geeft het begin van de eerste sectie in de payload aan. In een pakket met een sectie van een PMT zal deze pointer steeds nul aangeven1 . Er zijn dus 183 bytes beschikbaar voor de PMT en de (nog toe te voegen) private section. De verplichte velden in een PMT nemen 16 bytes in beslag. De PMT beschrijft de elementary 1
Als de vorige sectie een transport pakket niet volledig vulde, moet de volgende sectie steeds starten in het
begin van de payload van een nieuw transport pakket. Meer details zijn te vinden in [4].
6.1 Berekening van de capaciteit van een private section
81
streams (ES) die deel uit maken van de service. Voor elke ES worden o.a. het PID-nummer en het type gespecificeerd. Dit neemt 5 bytes per ES in. In deze scriptie worden enkel Single Program TS beschouwd. Die bevatten typisch drie ES: audio, video en STC2 . Zo neemt de PMT nog eens 15 bytes in beslag. In de PMT wordt ook een aantal descriptoren meegegeven, hetzij voor de hele service, hetzij per elementary stream. In de MPEG2-standaard [4] worden er tal van descriptoren beschreven, maar veel daarvan zullen zelden of nooit voorkomen in een TS. Een typische descriptor is 5 bytes groot. Als we veronderstellen dat er 4 descriptoren aanwezig zullen zijn, dan nemen die 20 bytes in. Uitgaande van de bovenstaande gegevens en veronderstellingen kan de ruimte berekend worden die beschikbaar is om een private section toe te voegen. Alle grootheden zijn uitgedrukt in bytes.
188 – 4 – 1 – 16 – 15 – 20 132
grootte van een transport pakket header pointer (met waarde 0) verplichte velden PMT beschrijving van 3 ES, 5 bytes per ES geschatte ruimte nodig voor descriptoren ruimte beschikbaar voor private section
Metingen op enkele TS hebben aangetoond dat deze schatting realistisch is. Meer dan
2 3
van
een transport pakket is beschikbaar om een private section toe te voegen. Dit rechtvaardigt gedeeltelijk de keuze in deze scriptie om private sections enkel toe te voegen aan bestaande pakketten (met een PMT) i.p.v. nieuwe transport pakketten te remultiplexeren met de bestaande TS. Het verlies aan ruimte blijft immers beperkt. In de volgende twee paragrafen wordt uitgegaan van een beschikbare ruimte van 132 bytes om een private section toe te voegen. De berekeningen worden afzonderlijk uitgevoerd voor de signalisatie en de triggers. 2
Bemerk dat de stempels van de STC (meestal) meegegeven worden in de video-stream en geen aparte ES
vormen. Toch moet de STC apart vermeld worden, zodat de ontvanger weet in welke ES hij de tijdsinformatie kan ophalen. Zie ook figuur 3.2.
6.1 Berekening van de capaciteit van een private section
6.1.1
82
Private section met signalisatie
De syntax van deze private section is terug te vinden in tabel B.1 in bijlage B. De algemene structuur werd reeds beschreven in paragraaf 5.1.2, in het bijzonder in figuur 5.3. De private section bevat een header, een aantal NPT-descriptoren en een overzicht van alle events. De events zijn geordend per tijdsbasis. Per event worden de naam en een eventID doorgegeven. In een typische situatie zal elke private section 2 NPT-descriptoren bevatten. Deze signaleren de tijdsbasis van het huidige en het volgende programma. Een NPT-descriptor is 13 bytes groot, dus beide descriptoren nemen samen 26 bytes in. De header is 7 bytes groot. Uitgaande van een private section van 132 bytes, blijft er zo nog 99 bytes over om de events te signaleren3 . Om de events te ordenen, wordt per tijdsbasis het contentID aangegeven, samen met het aantal events dat die tijdsbasis gebruikt. Per tijdsbasis neemt dit 2 bytes in beslag. Voor de details wordt verwezen naar tabel B.1. Er blijven 95 bytes over om per event de naam en het eventID door te geven. Onderstaande berekening vat alles nog eens samen. 132 – 7 – 26 – 4 95
beschikbare ruimte voor private section header 2 NPT-descriptoren ordening van events per tijdsbasis ruimte beschikbaar voor signalisatie naam en eventID
Per event worden een naam en een eventID doorgegeven. De naam is vrij te kiezen door de gebruiker en heeft een variabele lengte. We zullen uitgaan van een naam die bestaat uit 8 karakters en dus 8 bytes inneemt. Met die veronderstelling neemt elk event 11 bytes in: 2 bytes voor het eventID (waarvan slechts 13 bits gebruikt worden, zie tabel B.1), 1 byte om de lengte van de naam aan te geven, en 8 bytes voor de naam. Aangezien er nog 95 bytes beschikbaar waren, kunnen er 8 events per private section gesignaleerd worden. Dit aantal kan verhoogd worden door een kortere naam te kiezen voor de events. Als er meer dan 8 events gedefinieerd worden, dan moet de signalisatie opgesplitst worden over meerdere private sections. Dit is geen probleem aangezien elke section een volgnummer heeft. Op basis hiervan kan de ontvanger de volledige signalisatie terug in de correcte volgorde samenstellen. Tot slot van deze bespreking stippen we nog aan dat het aantal mogelijke events veel groter is dan bovenstaand resultaat. Het theoretisch maximum is bepaald door het aantal verschillende 3
We gaan er van uit dat de private section geen CRC32-foutcontrole bevat (cfr. syntax in tabel B.1).
6.1 Berekening van de capaciteit van een private section
83
eventIDs. Dit veld is 13-bit breed, zodat er tot 213 events gedefinieerd kunnen worden.
6.1.2
Private section met triggers
De syntax van deze private section is terug te vinden in tabel B.2 in bijlage B. De algemene structuur werd reeds beschreven in paragraaf 5.1.2, in het bijzonder in figuur 5.4. De private section start met een vaste header van 3 bytes. De rest van de private section bestaat uit een willekeurige combinatie van drie descriptoren: de NPT-descriptor en de descriptoren om een event te triggeren als een do-it-now of als een scheduled event. De grootte van de descriptoren is een belangrijke factor voor de performantie van het protocol. Hoe langer de descriptoren, hoe minder er in elke private section kunnen opgenomen worden en hoe meer private sections er vereist zijn om alle trigger-informatie ten minste ´e´en maal te kunnen versturen. Bovendien is de frequentie waarmee private sections kunnen verstuurd worden in deze scriptie beperkt tot de frequentie waarmee Program Map Tables in de TS voorkomen. Het is dus nuttig om een goed beeld te hebben van hoeveel triggers er in ´e´en private section kunnen opgenomen worden. De NPT-descriptor is steeds even groot, nl. 13 bytes. De grootte van de do-it-now en scheduledevent descriptor kan echter vari¨eren, afhankelijk van het aantal bytes aan private data dat met deze triggers wordt meegegeven. Om toch een idee te krijgen van de capaciteit van een private section, wordt er van uitgegaan dat elke trigger 8 bytes aan private data meekrijgt. De headers van een do-it-now en een scheduled-event descriptor zijn resp. 2 en 12 bytes groot. We kunnen de volgende tabel vooropstellen: Tabel 6.1: Typische grootte van een descriptor type
grootte
descriptor
(byte)
NPT descriptor
13
do-it-now descriptor
10
scheduled-event descriptor
20
Net zoals bij de signalisatie wordt uitgegaan van 2 NPT-descriptoren, die samen 26 bytes innemen. In totaal houden we dan 103 bytes over om te vullen met triggers. De onderstaande berekening vat alles nog eens samen.
6.1 Berekening van de capaciteit van een private section
132 – 3 – 26 103
84
beschikbare ruimte voor private section header 2 NPT-descriptoren ruimte beschikbaar voor triggers
We beschikken nu over alle resultaten die nodig zijn om te berekenen hoeveel triggers er in een private section kunnen worden opgenomen. Tabel 6.2 bevat alle relevante resultaten. In een eerste berekening (situatie A) werden geen do-it-now triggers verondersteld. Aangezien een do-it-now trigger slechts ´e´en maal voorkomt in de TS, is deze situatie niet onwaarschijnlijk. In de tweede berekening (situatie B) werden 2 do-it-now triggers toegevoegd. Er blijft dan minder ruimte over voor de scheduled-events. In situatie C bevat de private section enkel do-it-now triggers. Situatie C dient beschouwd te worden als een worst-case scenario. Tabel 6.2: Samenstelling van een private section met triggers (132 byte) Situatie A Situatie B Situatie C aantal NPT-descriptoren 2 2 2 aantal do-it-now descriptoren 0 2 10 aantal scheduled-event descriptoren 5 4 0 Uit deze tabel volgt dat een private section maximaal 5 triggers voor scheduled events kan bevatten. Dit aantal vermindert naarmate meer triggers voor do-it-now events toegevoegd worden. Twee do-it-now triggers nemen evenveel plaats in als ´e´en scheduled-event trigger. Met de gemaakte veronderstellingen kunnen er in een private section maximaal 10 triggers voor do-it-now events worden opgenomen, zodat er tussen 2 opeenvolgende private sections maximum 10 do-itnow events kunnen optreden. Typisch wordt er 1 PMT (en dus 1 private section) verstuurd per 0.2 s `a 0.5 s. De beschikbare ruimte in de private sections mag dus ruim voldoende genoemd worden4 . We besluiten deze paragraaf met twee opmerkingen. Ten eerste kan het maximum aantal events per private section worden opgedreven door de private data bij elke trigger kleiner te maken. Verder dient benadrukt te worden dat de bovenstaande berekening enkel aangeeft hoeveel triggers er in ´e´en private section kunnen verstuurd worden, maar geen indicatie geeft over het aantal verschillende triggers dat tegelijk kan ondersteund worden. Dit aantal is in principe onbeperkt. Er kunnen immers meerdere private sections worden aangemaakt, die elk een aantal triggers bevatten en na elkaar verstuurd worden. 4
Er moeten ook private sections met signalisatie verstuurd worden. De werkelijke frequentie ligt dus iets lager.
6.2 Uitbreidingen
6.2
85
Uitbreidingen
In deze scriptie werd slechts een deel van de mogelijkheden van het ontwikkelde raamwerk benut. Op basis van deze resultaten kan op veel gebieden nieuw onderzoek en ontwikkeling verricht worden. In deze paragraaf worden enkele suggesties gedaan over de wegen die verder kunnen bewandeld worden. Een eerste uitbreiding situeert zich in het transportmechanisme van de private sections. In deze scriptie werden deze enkel toegevoegd in transport pakketten met een PMT. De private sections kunnen echter ook in aparte pakketten verstuurd worden. Die pakketten worden geremultiplexeerd met de pakketten van de bestaande TS, cfr. figuur 5.2. De nauwkeurigheid van do-it-now triggers kan op die manier opgedreven worden. De triggers hoeven niet meer te wachten op het volgende transport pakket met een PMT om verstuurd te worden. Zodra een do-it-now trigger wordt gegenereerd, wordt een transport pakket met (enkel) een private section aangemaakt dat ogenblikkelijk geremultiplexeerd wordt met de overige pakketten. Het protocol hoeft niet aangepast te worden om deze uitbreiding te realiseren. Ten tweede zou het real-time aspect kunnen ge¨ıntroduceerd worden. In de zendmodule van deze scriptie wordt eerst de volledige video bekeken. Pas daarna worden de triggers in de TS gebracht. In een real-time applicatie worden beide stappen gecombineerd. De broadcaster bekijkt het beeld dat op dat ogenblik verzonden wordt over het netwerk. Triggers worden ogenblikkelijk in een private section verpakt en on-the-fly geremultiplexeerd met de te verzenden pakketten. Op die manier krijgen do-it-now triggers hun ware dimensie: ze worden tijdens het programma gegenereerd en worden ogenblikkelijk verstuurd. Voor scheduled-events zou er in deze uitbreiding weinig veranderen. Het Belgacom-netwerk gebruikt enkel Single Program TS. Het raamwerk kan zonder aanpassingen ook gebruikt worden in Multi-Program Transport Streams (MPTS). Elke service in de MPTS heeft een apart PID-nummer voor de PMT. De pakketten met private sections zullen hetzelfde label dragen als de PMT van de service waartoe ze behoren. Op die manier kan de decoder ondubbelzinnig bepalen op welke service een private section betrekking heeft. De uitbreiding tot MPTS vereist wel een nog complexere remultiplexerering dan in het geval van een SPTS. De vorige drie uitbreidingen buiten enkel de bestaande functionaliteit van het ontwikkelde raamwerk verder uit. Men kan zich echter ook concentreren op een uitbreiding van de toepassingen
6.2 Uitbreidingen
86
ervan. Hieronder wordt slechts ´e´en voorbeeld gegeven, maar de mogelijkheden zijn legio. In het netwerk van Belgacom zet de settop-box een verbinding op met een DSLAM. Die DSLAM stuurt de gewenste TS (met de gevraagde TV-zender) door. De DSLAM ontvangt de verschillende TS van het centrale distributie-platform. Daar wordt voor elke TV-zender ´e´en TS aangemaakt, die naar alle DSLAM’s wordt verzonden. Iedereen die naar hetzelfde programma kijkt, krijgt dezelfde TS te zien. In de toekomst zal men echter een grotere differentiatie tussen de gebruikers willen voorzien. Toegepast op het triggermechanisme kan dit inhouden dat niet alle gebruikers een welbepaalde trigger mogen ontvangen. Figuur 6.1 illustreert dit. distributie centrum
distributie centrum DSLAM
DSLAM
Server
Server
DSLAM
DSLAM
DSLAM
DSLAM
Figuur 6.1: Differentiatie tussen de gebruikers op het gebied van triggering
De broadcaster stuurt een trigger door. In de linkse situatie resulteert dit in een event op elke settop-box. In de rechtse situatie wordt er meer gedifferentieerd en treedt het event slechts bij enkele gebruikers op. Betalende diensten vormen een typische toepassing van dit principe. Nieuwsupdates mogen bv. enkel verschijnen bij geregistreerde gebruikers, of iedereen moet een persoonlijke code op het scherm te zien krijgen om deel te nemen aan een loterij... Omwille van schaalbaarheidsproblemen is het onmogelijk om per gebruiker een aparte TS aan te maken. Er moet eerder een oplossing gezocht worden waarbij elke gebruiker dezelfde TS ontvangt, maar niet alle triggers kan/mag detecteren. Hiervoor zijn twee mogelijkheden. Samen met de triggers kan een sleutel als private data meegegeven worden. Alleen de settop-boxen die aan bepaalde voorwaarden voldoen, kunnen op basis van deze sleutel de triggers correct interpreteren. Een andere optie is de uitbreiding van
6.2 Uitbreidingen
87
het raamwerk met een nieuw type descriptor, die de conditionele toegang tot de triggers regelt. Deze optie biedt wellicht meer flexibliteit dan het louter doorgeven van een sleutel als private data.
CONCLUSIES
88
Hoofdstuk 7
Conclusies In deze scriptie werd onderzoek verricht naar de ontwikkeling van een triggermechanisme. Het raamwerk diende in de eerste plaats bruikbaar te zijn op het iDTV-netwerk van Belgacom, maar werd toch zo generiek mogelijk ontwikkeld. Naast een doordacht protocol werden ook principi¨ele implementaties van een zend- en ontvangstmodule ontwikkeld. Het Multimedia Home Platform bleek na een grondige studie niet geschikt te zijn voor een conversie naar het Belgacom-netwerk. Er werd daarom een eigen protocol gedefinieerd, dat gebruik maakt van private sections. De sections worden toegevoegd na elk pakket met een Program Map Table en bevatten triggers en signalisatie-informatie. Als tijdsbasis wordt de Normal Playing Time gebruikt. De NPT laat toe om meerdere tijdsbases te gebruiken en een tijdsbasis te pauzeren of versneld te laten oplopen. Steeds werd aandacht besteed aan flexibiliteit en uitbreidbaarheid. Het gebruik van descriptoren voor de triggers, het toevoegen van private data en de ontdubbeling tussen naam en eventID zijn hier illustraties van. De zendmodule vormt de interface naar de broadcaster. Met deze module kan de broadcaster events defini¨eren en triggers toevoegen aan de TS. De module werd deels in C en deels in Java ge¨ımplementeerd. De ontvangstmodule is een simulatie van de settop-box bij de ontvanger. Net zoals de zendmodule is ze opgebouwd uit een luik in C en een luik in Java. Voor het weergeven van de video werd gekozen voor QuickTime for Java. Om de events te kunnen weergeven, diende gebruik te worden gemaakt van threads. De conclusies van uitgebreide experimenten in dit verband werden in deze scriptie opgenomen. Ze kunnen een waardevolle basis vormen voor toekomstig onderzoek en ontwikkeling.
CONCLUSIES
89
Naast een generiek zend- en ontvangstmodule werd ook een concrete voorbeeldapplicatie gebouwd. iDTV Foot is een toepassing die kan gebruikt worden tijdens een voetbalmatch. Ze bevat de nodige voorgedefinieerde events. Met deze scriptie werd een aanzet gegeven tot de uitbouw van een platform voor het triggeren van events. De principi¨ele implementatie toont bovendien de haalbaarheid van de oplossing aan. Mits de nodige uitbreidingen, in het bijzonder naar realtime, kan het platform zeker dienen als vertrekpunt voor de ontwikkeling van een commerci¨eel product. Digitale TV is geen toekomstmuziek meer, maar verschijnt wellicht eerder vandaag dan morgen in de huiskamers. Zo komt er misschien een dag dat de resultaten van deze scriptie terug te vinden zijn in iedere settop-box...
SYNTAX VAN PRIVATE SECTION
90
Bijlage A
Syntax van Private Section A.1
Private Section
De syntax van een Private Section werd gedefinieerd in [4] en wordt hieronder besproken. Tabel A.1: Syntax van een private section syntax aantal bits private section(){ table id section syntax indicator private indicator reserved private section length if(section syntax indicator == ‘0’){ for(i = 1; i ≤ N ; i++){ private data byte } } else{ table id extension reserved version number current next indicator section number last section number for(i = 1; i ≤ private section length - 9; i++){ private data byte } CRC 32 } }
mnemonic
8 1 1 2 12
uimsbf bslbf bslbf bslbf uimsbf
8
bslbf
16 2 5 1 8 8
uimsbf bslbf uimsbf bslbf uimsbf uimsbf
8
bslbf
32
rpchof
A.1 Private Section
91
In de tabel worden de volgende mnemonics gebruikt: uimsbf bslbf rpchof tcimsbf
unsigned integer, most significant bit first bit string, left bit first remainder polynomial coefficients, highest order first two’s complement integer, most significant bit first
De velden hebben de volgende betekenis: table id: Geeft aan van welk soort tabel deze sectie een onderdeel is. Voor een private
section mogen enkel waarden uit het bereik 0x40 - 0xFE gekozen worden. section syntax indicator: Dit 1-bit veld geeft aan of de uitgebreide syntax van de
private section al dan niet wordt gevolgd. private indicator: De betekenis van deze bit is vrij te kiezen door de gebruiker. private section length: Het aantal resterende bytes in deze private section (na dit
veld). table id extension: Uitbreiding van het veld table id. Mag volledig vrij gekozen
worden door de gebruiker. version number: Dit veld wordt elke keer ge¨ıncrementeerd als de inhoud van de private
section gewijzigd is. Via dit veld kan de gebruiker eenvoudig nagaan of de private section ge¨ updated werd en is het niet nodig om telkens de volledige sectie te ontleden. current next indicator: Indien deze bit de waarde ‘1’ heeft, is deze versie van de
tabel geldig. Staat deze bit op ‘0’, dan is deze versie op het moment van ontvangst nog niet geldig. Ze wordt pas geldig bij ontvangst van een volgende private section met hetzelfde section number en table id. section number: Geeft het volgnummer van de sectie aan, zodat de volledige tabel
correct kan worden gereconstrueerd. De eerste sectie heeft volgnummer 0x00. last section number: Geeft het volgnummer van de laatste sectie van de tabel. CRC 32: Het resultaat van een 32-bit Cyclic Redundancy Check, gedefinieerd in [4].
A.2 DSM-CC Section
A.2
92
DSM-CC Section
Omdat DSM-CC Sections aan bod komen bij de bespreking van het triggermechanisme in hoofdstuk 4, werd ook hun syntax opgenomen in deze bijlage. De DSM-CC Section vormt een uitbreiding op een private section. Ze volgt de syntax ervan, maar sommige velden krijgen extra restricties. Enkel die velden worden hieronder opgesomd. table id: deze waarde kan nu niet meer gekozen worden. Een DSM-CC Section met
Stream Event Descriptors heeft 0x3D als table id. section syntax indicator: dit veld krijgt een andere betekenis in een DSM-CC sec-
tie. In plaats van de vorm van de syntax aan te geven, maakt het hier onderscheid in het controlemechanisme dat gebruikt wordt om bitfouten op te sporen. Bij een waarde ‘1’ wordt een CRC-32 berekend, bij ‘0’ een checksum. Het resultaat wordt steeds in de laatste 4 bytes van de sectie geplaatst. De sectie zelf volgt overigens altijd de uitgebreide syntax, alsof dit veld in tabel A.1 steeds de waarde ‘1’ zou aannemen. table id extension: in DSM-CC blijft dit veld vrij te kiezen. In MHP wordt het
gebruikt om aan te geven welke soort descriptoren er in de payload zitten: do-it-now, scheduled event of NPT.
PROTOCOL
93
Bijlage B
Protocol In deze bijlage wordt de volledige syntax van het ontwikkelde protocol voor het triggermechanisme beschreven. Zoals steeds in deze scriptie wordt het onderscheid tussen signalisatie en eigenlijke triggering aangehouden.
B.1
Signalisatie
Voor de private section met de signalisatie wordt de eenvoudige syntax uit tabel A.1 gehanteerd. Omwille van hun functionaliteit, werden er ook drie velden uit de uitgebreide syntax overgenomen: version number, section number en last section number. De private section start met een header van 7 bytes. Daarna komen de NPT-descriptoren. Ze hebben een vaste grootte van 13 bytes (104 bits). Hun exacte syntax komt aan bod bij de bespreking van de private section met de triggers en wordt getoond in tabel B.3. Er wordt een descriptor voorzien voor elke tijdsbasis. In het laatste deel van de sectie wordt de nodige informatie voorzien om de ontkoppeling tussen naam en eventID mogelijk te maken. De verschillende events worden geordend per contentID. De naam wordt als een reeks van ASCII-karakters doorgegeven. Tot slot is het mogelijk om een CRC-foutcontrole door te voeren.
B.2 Triggers
94
Tabel B.1: Syntax van een private section met signalisatie syntax aantal bits mnemonic private section signalisatie(){ table id 8 uimsbf section syntax indicator 1 bslbf private indicator 1 bslbf reserved 2 bslbf private section length 12 uimsbf stuff 3 bslbf version number 5 uimsbf section number 8 uimsbf last section number 8 uimsbf no of NPT descriptors (= N1) 8 uimsbf for(i = 1; i ≤ N1; i++){ NPT descriptors } while(private section not full) { no of eventIDs (= N2) 8 uimsbf stuff 1 bslbf contentID 7 uimsbf for(i = 1; i ≤ N2; i++) { stuff 3 bslbf eventID 13 uimsbf eventNameLength (= N3) 8 uimsbf for(i = 1; i ≤ N3;i++) { eventName[i] ASCII } } } if(private indicator == 1) CRC32 32 rpchof }
B.2
Triggers
De private section die gebruikt wordt om triggers door te geven is heel eenvoudig qua opbouw. Er werd gekozen voor de eenvoudige syntax uit tabel A.1. De payload bestaat uit een willekeurige combinatie van drie descriptoren: de NPT-descriptor, de do-it-now descriptor en de scheduledevent descriptor.
B.2 Triggers
95
Tabel B.2: Syntax van een private section met triggers syntax aantal bits mnemonic private section triggers(){ table id 8 uimsbf section syntax indicator 1 bslbf private indicator 1 bslbf reserved 2 bslbf private section length (= N1) 12 uimsbf while(total no descriptor bytes ≤ N1){ NPT descriptor cfr. tabel B.3 k do it now descriptor cfr. tabel B.4 k scheduled event descriptor cfr. tabel B.5 } }
B.2.1
NPT-descriptor
De syntax van de NPT-descriptor is nagenoeg volledig overgenomen uit DSM-CC. De velden scaleNumerator en scaleDenominator werden ingekort van twee naar ´e´en byte. Deze velden zullen slechts kleine getallen bevatten, zodat ´e´en byte volstaat. Verder werden enkele overbodige velden uit de NPT-Descriptor van DSM-CC weggelaten. Tabel B.3: Syntax van de NPT-descriptor syntax aantal bits mnemonic NPT descriptor(){ descriptorTag 3 uimsbf stuff 5 bslbf contentID 7 uimsbf STC Reference 33 uimsbf reserved 7 bslbf NPT Reference 33 uimsbf scaleNumerator 8 tcimsbf scaleDenominator 8 tcimsbf }
descriptorTag: heeft de waarde 000. contentID: geeft de tijdsbasis aan waarop deze descriptor betrekking heeft. STC Reference: dit veld wordt samen met het veld NPT Reference gebruikt om de
B.2 Triggers
96
NPT te signaleren. NPT Reference: dit veld wordt samen met het veld STC Reference gebruikt. De NPT
neemt de waarde van dit veld aan als de STC van de ontvanger de waarde bereikt die in het veld STC Reference staat opgegeven. scaleNumerator en scaleDenominator: geven de verhouding aan van de snelheid
van de NPT-klok t.o.v. de STC. Zowel positieve als negatieve verhoudingen zijn mogelijk.
B.2.2
Do-it-now descriptor
Deze descriptor wordt gebruikt om een event ogenblikkelijk te triggeren. Tabel B.4: Syntax van de do-it-now-descriptor syntax aantal bits mnemonic do-it-now descriptor(){ descriptorTag 3 uimsbf eventID 13 uimsbf privateDataLength (= N) 8 uimsbf for(i = 1; i ≤ N; i++){ privateDataByte 8 bslbf } }
descriptorTag: heeft de waarde 100. eventID: specificeert het event dat moet optreden. privateDataLength: geeft aan hoeveel bytes private data er meegestuurd worden met
de trigger. privateDataByte: een byte private data.
B.2.3
Scheduled-event descriptor
Deze descriptor wordt gebruikt om een event te triggeren dat pas op een later ogenblik optreedt.
B.2 Triggers
97
Tabel B.5: Syntax van de scheduled-event-descriptor syntax aantal bits mnemonic scheduled-event descriptor(){ descriptorTag 3 uimsbf eventID 13 uimsbf stuff 7 bslbf eventNPT 33 uimsbf privateDataLength (= N) 8 uimsbf for(i=1; i ≤ N; i++){ privateDataByte 8 bslbf } }
descriptorTag: heeft de waarde 101. eventID: specificeert het event dat moet optreden. eventNPT: bevat het tijdstip waarop het event moet optreden. privateDataLength: geeft aan hoeveel bytes private data er meegestuurd worden met
de trigger. privateDataByte: ´e´en byte private data.
HANDLEIDING
98
Bijlage C
Handleiding In deze bijlage wordt een handleiding meegegeven aan de gebruiker van de software. Zowel de installatieprocedure als de bediening van zend- en ontvangstmodule worden behandeld. Beide modules vereisen dat Java ge¨ınstalleerd is op de PC. Tijdens de ontwikkeling werd versie 1.4.2 gebruikt. Op het web is overvloedig informatie beschikbaar over Java [38]. Er zal daarom van uitgaan worden dat Java beschikbaar is op de PC. Verder zijn ook QuickTime for Java en een C-compiler vereist.
C.1
Installatie QuickTime for Java
Op het ogenblik van publicatie is QuickTime 6.5 de meest recente versie (voor Windows). De QuickTime-player is gratis te downloaden van [36]. Let erop dat u de QuickTime Standalone Installer downloadt en niet de versie met het programma iTunes. Voor het gemak van de gebruiker werd het correcte bestand bijgeleverd op de CD-ROM bij deze scriptie.
1. Start het gedownloade (of van de CD-ROM afgehaalde) (exe-)bestand. 2. Kies voor de Custom installatieprocedure. 3. In het volgende venster moet u de QuickTime for Java-component aanvinken. 4. Als de installatie voltooid is, ga dan op zoek naar het bestand QTJava.zip. De directory van dit bestand moet u opnemen in het classpath van uw Java-compiler.
C.2 Zendmodule
99
Als alternatief kan u in de laatste stap het bestand QTJava.zip kopi¨eren naar de directory met de Java-bronbestanden van zend- of ontvangstmodule.
C.2
Zendmodule
C.2.1
Installatieprocedure
De zendmodule is opgebouwd uit een deel in C en een deel in Java. Beide delen communiceren via de Java Native Interface. De bronbestanden van beide delen zijn terug te vinden op de CD-ROM bij deze scriptie. Bij de compilatie dient de volgende procedure gevolgd te worden.
Compilatie C-bestanden De bestanden moeten gecompileerd worden tot de bibliotheek addTriggersInStream. Volg hiertoe de volgende procedure in Microsoft Visual C++ 6.0: 1. Open een nieuw project met de naam addTriggersInStream. Dit project moet van het type Win32 Dynamic-Link Library zijn. 2. Voeg alle bronbestanden toe aan het project. De bestanden zijn terug te vinden op de CD-ROM bij deze scriptie, onder de map ‘Zendmodule’. 3. Om gebruik te maken van JNI moeten ook de header-bestanden jni.h en jni md.h ge¨ıncludeerd worden. Opdat Visual C++ deze bestanden zou terugvinden, moet in het menu Tools → Options onder het tabblad Directories de directory toegevoegd worden waar die bestanden terug te vinden zijn. Beide bestanden worden automatisch meegeleverd bij de SDK van Java en zijn typisch terug te vinden in de subdirectories \include en \include\win32 van de directory waarin Java werd ge¨ınstalleerd. 4. Stel de configuratie in op Release i.p.v. Debug. Dit kan via het menu Build → Set Active Configuration. 5. Compileer de bibliotheek door het Build -icoontje aan te klikken, of via de F7-toets. Na compilatie vindt u de bibliotheek addTriggersInStream.dll terug in de subdirectory \Release. Kopieer dit bestand naar de directory met de Java-bronbestanden voor de zendmodule.
C.2 Zendmodule
100
Compilatie Java-bestanden U compileert eenvoudigweg alle *.java bestanden met het javac-commando. Zorg ervoor dat het classpath van QuickTime for Java correct is ingesteld. Hebt u er bij de installatie van QTJ voor gekozen om het bestand QTJava.zip te kopi¨eren naar de directory met de bronbestanden, dan kan u alternatief het volgende commando gebruiken: javac -classpath .;QTJava.zip *.java
C.2.2
Gebruik van de zendmodule
Zoals aangehaald in de hoofdtekst maakt de zendmodule gebruik van twee bestanden. Het ene bestand is de TS waarin de triggers worden ingebracht. In dezelfde directory moet een tweede bestand aanwezig zijn, met dezelfde naam (op de extensie na), in MPEG-2 Program Stream of MPEG-1 formaat. Dit bestand wordt gebruikt om de videobeelden weer te geven. U dient er voor te zorgen dat beide bestanden zich in dezelfde directory bevinden als de Java-bronbestanden van de zendmodule. U start de zendmodule met het commando java Sender Eventueel moet u, net zoals bij het compileren, de classpath-variabele expliciet opgeven. Indien QTJava.zip in dezelfde directory staat als de bronbestanden, neemt het commando de volgende vorm aan: java -classpath .;QTJava.zip Sender Via het menu Bestand kan u vervolgens een videobestand openen. Een ingebouwde filter zorgt ervoor dat enkel (video)bestanden worden weergegeven waarvoor zowel een TS als een MPEG-2 PS of een MPEG-1 bestand met dezelfde naam aanwezig zijn in de directory. Vervolgens kan u nieuwe events toevoegen via Events → Nieuwe events defini¨ eren. Per event moet u een naam, het contentID en de manier waarop het event zal getriggerd worden, ingeven. Bij de definitie van de contentID’s dient u er op te letten dat elk contentID door minstens 1 event wordt gebruikt.
C.3 Ontvangstmodule
101
U start de video, en laat events optreden door op de knoppen onderaan het scherm te drukken. Indien gewenst kan u private data meegeven door deze in te geven in het tekstveld onder de gepaste knop. Via het menu Events → Triggers toevoegen aan stream voegt u de triggers en de signalisatie toe aan de TS. Er verschijnt een bevestigingsboodschap zodra dit proces is voltooid. De herwerkte TS vindt u terug in dezelfde directory als de oorspronkelijke bestanden. Dit bestand heeft een naam die bestaat uit de naam van de oorspronkelijke TS, waar de uitbreiding out is aan toegevoegd. Via Events → Overzicht gedefinieerde events kan u een overzicht opvragen van alle gedefinieerde events.
C.2.3
iDTV Foot-zendmodule
De bediening van de module is dezelfde als die van de algemene zendmodule. Bij het opstarten van de module moet u de ploegen ingeven. De nodige knoppen voor het genereren van de events worden automatisch aangemaakt. Bij enkele knoppen vindt u ook een tekstvak om private data mee te geven. Bij de events “Doelpunt”, “Gele kaart” of “Rode kaart” kan u de naam van de betrokken speler meegeven. Bij het event “Toon Sponsor” geeft u aan welk logo u wenst af te beelden. De ontvangstmodule herkent de strings “intec”, “belgacom” en “jupiler”. Als u een nieuw bestand opent met een wedstrijd tussen andere teams, dan kan u de ploegen wijzigen via het menu Set-Up → Wijzigen ploegen.
C.3
Ontvangstmodule
C.3.1
Installatieprocedure
Net zoals bij de zendmodule moeten zowel de C- als de Java-bestanden gecompileerd worden. De stappen zijn nagenoeg identiek en er kan dus verwezen worden naar paragraaf C.2.1. Voor de compilatie van de C-bestanden dient u nu een project aan te maken met de naam
retrieveInfo. Na compilatie moet u het bestand retrieveInfo.dll kopi¨eren naar de directory met de Java-bronbestanden van de ontvangstmodule. Het bestand QTJava.zip moet aanwezig zijn in de directory met de Java-bronbestanden,
tenzij u de classpath-variabele hebt gewijzigd.
C.3 Ontvangstmodule
C.3.2
102
Gebruik van de ontvangstmodule
Net zoals bij de zendmodule moeten ook hier twee bestanden aanwezig zijn in de directory met de bronbestanden (van de ontvangstmodule): enerzijds een MPEG-2 PS of MPEG-1 videobestand, en anderzijds een TS die de triggers bevat. U dient dus het uitvoerbestand van de zendmodule te kopi¨eren naar de directory met de bronbestanden van de ontvangstmodule. Dit bestand herkent u aan de string out in de naam van het bestand. Ook hier is een gepaste filter ingebouwd, zodat u enkel die bestanden te zien krijgt die aan deze voorwaarde voldoen. U start de applicatie via (ook hier moet u eventueel nog de classpath-variabele expliciet opgeven) java Receiver Na het openen van een bestand verschijnt in het controlepaneel onderaan een menu met alle events in de TS. U kiest in dit menu welke events u wenst weer te geven. Eventueel kan u ook de snelheid van afspelen verhogen, om u ervan te vergewissen dat ook in dit geval de relatieve positie van de triggers behouden blijft. Dit is evenwel enkel het geval voor positieve waarden. Via Events → Overzicht gedefinieerde events kan u een overzicht opvragen van de events die gedefinieerd zijn in de applicatie. Enkel de triggers in de TS voor die events zullen door de applicatie gebruikt worden, de overige worden genegeerd. Via Triggers → Overzicht triggers in stream kan u een overzicht bekijken van de getriggerde events.
C.3.3
iDTV Foot-ontvangstmodule
De bediening van de module is analoog aan die van de algemene ontvangstmodule. In de applicatie zijn automatisch alle events gedefinieerd die kunnen gegenereerd worden door de iDTV Foot-zendmodule. U kan hier echter niet kiezen welke events u wenst weer te geven, alle events treden automatisch op.
INHOUD VAN DE CD-ROM
103
Bijlage D
Inhoud van de CD-ROM Bij het voorliggend boek hoort ook een CD-ROM. Die bevat naast de broncode ook enkele programma’s die de gebruiker nodig heeft als hij de zend- en ontvangstapplicatie wenst te testen. Er werden ook enkele referenties opgenomen. Hieronder wordt een overzicht gegeven per directory: Boek Bevat dit boek in PDF-formaat. De bronbestanden in LATEX en de figuren, gemaakt in MS Visio, werden eveneens opgenomen. Zendmodule Bevat zowel de broncode (in C en in Java) als een voor Windows gecompileerde versie van de zendmodule. Om deze zendmodule te draaien moeten Java en QuickTime for Java ge¨ınstalleerd zijn. Deze software werd opgenomen in de map Software. Ontvangstmodule Bevat zowel de broncode (in C en in Java) als een voor Windows gecompileerde versie van de ontvangstmodule. Om deze ontvangstmodule te draaien moeten Java en QuickTime for Java ge¨ınstalleerd zijn. Deze software werd opgenomen in de map Software. iDTV Foot Bevat zowel de broncode als een voor Windows gecompileerde versie van de iDTV-Foot applicatie. De code voor zend- en ontvangstmodule werd ondergebracht in aparte mappen. Om deze applicatie te draaien moeten Java en QuickTime for Java ge¨ınstalleerd zijn. Deze software werd opgenomen in de map Software.
INHOUD VAN DE CD-ROM
104
Software Bevat software die bij deze scriptie werd gebruikt of geraadpleegd. Naast de Java SDK en een volledige versie van QuickTime werd ook de Elecard-codec opgenomen. Deze codec laat toe om MPEG-2 TS weer te geven in Windows Media Player. Deze map bevat verder nog de programma’s Transport Stream Reader en Xilisoft Video Converter. Met het eerste programma kan een TS geanalyseerd worden, met het tweede kan het videoformaat van een bestand geconverteerd worden. Video Bevat twee videofragmenten die gebruikt werden bij deze scriptie. Van elk fragment is een versie in MPEG-1, in MPEG-2 PS en in MPEG-2 TS formaat ter beschikking gesteld. Referenties Bevat een elektronische versie van enkele referenties uit deze scriptie.
BIBLIOGRAFIE
105
Bibliografie [1] IBBT. Multimedia Content Distribution Platform. https://mcdp.ibbt.be. [2] Broadband
Bananas.
The
Broadband
Bananas
Video
Vault.
http://www.broadbandbanans.org/videovault. [3] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison Wesley, 1999. [4] ITU-T. Generic coding of moving pictures and associated audio information: systems. ITU-T Rec. H.222.0 of ISO 13818-1. [5] ITU-T. Generic coding of moving pictures and associated audio information: video. ITU-T H.262 of ISO 13818-2. [6] ITU-T. Generic coding of moving pictures and associated audio information: audio. ITU-T H.262 of ISO 13818-3. [7] Michael Orzessek and Peter Sommer. ATM & MPEG2 - Integrating Digital Video Into Broadband Networks. Prentice Hall, 1997. ISBN 0 13 243700 7. [8] DVB. Digital Video Broadcasting (DVB); Multimedia Home Platform Specification 1.0.3. ETSI ES 201 812 V1.1.1. [9] Digital Video Broadcasting. The Standard of the Digital World. http://www.dvb.org. [10] DVB. Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for cable systems. ETSI EN 300 429 V1.1.2. [11] DVB. Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services. ETSI EN 300 421 V1.1.2.
BIBLIOGRAFIE
106
[12] DVB. Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H). ETSI EN 302 304 V1.1.1. [13] DVB. Digital Video Broadcasting (DVB); Architectural framework for the delivery of DVBservices over IP-based networks. ETSI TR 102 033 V1.1.1. [14] DVB. Digital Video Broadcasting (DVB); Specification for conveying ITU-R System B Teletext in DVB bitstreams. ETSI EN 300 472 V1.3.1. [15] DVB. Digital Video Broadcasting (DVB); DVB Subtitling. ETSI EN 300 743 V1.2.1. [16] Myrio. Enriching the Digital Home with IP Video Solutions. http://www.myrio.com. [17] NDS.
MediaHighway
Middleware:
Empowering
new
TV
Services.
http://nds.com/middleware/middleware.html. [18] Liberate. Liberate Technologies. http://www.liberate.com. [19] OpenTV. Enabling Interactive Television Experiences Worldwide. http://www.opentv.com. [20] Steve Morris and Anthony Smith-Chaigneau. MHP, OCAP, and JavaTV.
Interactive TV Standards. A Guide to
Elsevier Focal Press, 2005.
ISBN 0 240 80666 2.
http://www.interactivetvweb.org. [21] W3C HTML Working Group. up
Language
(Second
Edition).
XHTML 1.0 The Extensible HyperText MarkW3
Consortium
Recommendation,
2002.
http://www.w3.org/TR/xhtml1/. [22] H.W. Lie, B. Bos, C. Lilley, and I. Jacobs. Cascading Style Sheets, level 2. W3 Consortium Recommendation, mei 1998. http://www.w3.org/TR/REC-CSS2/. [23] European Computer Manufacturers Association. ECMA Script Language, december 1999. ISO/IEC 16262. [24] Sun. Java TV API Specification 1.0. http://java.sun.com/javaTV/index.jsp. [25] ISO/IEC. Generic coding of moving pictures and associated audio information: Extension for Digital Storage Media Command and Control. ISO 13818-6. [26] V. Balabanian et al. Digital Storage of Media Command and Control Protocol Applied to ATM. IEEE JSAC, augustus 1996. vol. 14, no. 6.
BIBLIOGRAFIE
107
[27] V. Balabanian et al. An Introduction to Digital Storage Media Command and Control Protocol (DSM-CC). IEEE Communication, november 1996. [28] The Object Management Group. The Common Object Request Broker: Architecture and Specification, 2001. [29] Comments and position of Belgacom with regard to emerging broadband IP television
technologies
(IP
TV)
versus
traditional
DVB
platforms,
april
2004.
http://europa.eu.int/information society/topics/ecomm/doc/useful information/library/ public consult/interoperability idtv/belgacom idtv v2.pdf. [30] James F. Kurose and Keith W. Ross. Computernetwerken, een top-down benadering. Pearson Education Benelux, 2de edition, 2003. ISBN 9 043 00806 0. [31] ITU-T. Amendment 1: Carriage of metadata over ITU-T Rec. H.222.0 / ISO 13818-1 streams. ITU-T H.262 of ISO 13818-2. [32] Wang XingDong, Yu Songyu, and Liang Longfei. Implementation of MPEG2 Transport Stream Remultiplexer for DTV Broadcasting. IEEE Transactions on Consumer Electronics, mei 2002. vol. 48, no. 2. [33] Nico Clemminck. Een generiek systeem voor gecontroleerde overdracht van MPEG-1/2 video in ware tijd. Scriptie, Vakgroep INTEC, Faculteit Toegepaste Wetenschappen, Universiteit Gent, 2003. [34] Koen De Bosschere. Het prestatie-effect van inputbuffering. Vakgroep ELIS, Faculteit Toegepaste Wetenschappen, Universiteit Gent, 2002. [35] Sun. Java Media Framework. http://java.sun.com/products/java-media/jmf/. [36] Apple. QuickTime for Java. http://www.apple.com/quicktime/download. [37] Elecard. Moonlight Elecard MPEG2 Player. http://www.elecard.com. [38] Sun. Java SDK. http://java.sun.com.
LIJST VAN FIGUREN
108
Lijst van figuren
1.1
Principieel schema van een settop-box . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Interactieve reclamespot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Interactieve quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1
Triggers voor een scheduled en een do-it-now event . . . . . . . . . . . . . . . . .
8
2.2
Onderscheid tussen STC en NPT . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Het gebruik van meerdere tijdsbases . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
Van Elementary tot Transport Stream . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
Tabellen in de Multi-Program Transport Stream . . . . . . . . . . . . . . . . . .
19
4.1
Enkele van de API’s gedefinieerd rond de DVB-J . . . . . . . . . . . . . . . . . .
25
4.2
MHP in het drielagig model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3
Twee manieren om DVB-HTML applicaties weer te geven . . . . . . . . . . . . .
27
4.4
Het toestandsdiagram van een XLet . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.5
Het carrouselprincipe en het ontstaan van wachttijden . . . . . . . . . . . . . . .
29
4.6
Het client-server model van DSM-CC . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.7
De verschillende stappen om een Object te versturen . . . . . . . . . . . . . . . .
33
4.8
Stream Event Objects en Stream Event Descriptors . . . . . . . . . . . . . . . . .
37
5.1
Een transport pakket met een Adaptation Field . . . . . . . . . . . . . . . . . . .
43
5.2
Het transport van een private section in een bestaande Transport Stream . . . .
46
LIJST VAN FIGUREN
109
5.3
Private Section voor de signalisatie . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.4
Private section met triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.5
Java Native Interface als doorgeefluik tussen Java en C . . . . . . . . . . . . . . .
58
5.6
Opbouw van het C-luik van de zendmodule . . . . . . . . . . . . . . . . . . . . .
59
5.7
Opbouw van de signalisatie op basis van twee types gelinkte lijsten . . . . . . . .
63
5.8
Een screenshot van de zendmodule . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.9
Samenhang tussen de Java-klassen van de zendmodule . . . . . . . . . . . . . . .
67
5.10 Een screenshot van de ontvangstmodule . . . . . . . . . . . . . . . . . . . . . . .
71
5.11 De events worden weergegeven op een laag boven de video . . . . . . . . . . . . .
72
5.12 De twee threads van de ontvangstmodule
75
. . . . . . . . . . . . . . . . . . . . . .
5.13 Een screenshot van de iDTV Foot ontvangstmodule 6.1
. . . . . . . . . . . . . . . .
78
Differentiatie tussen de gebruikers op het gebied van triggering . . . . . . . . . .
86
LIJST VAN TABELLEN
110
Lijst van tabellen
6.1
Typische grootte van een descriptor
. . . . . . . . . . . . . . . . . . . . . . . . .
83
6.2
Samenstelling van een private section met triggers (132 byte) . . . . . . . . . . .
84
A.1 Syntax van een private section . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
B.1 Syntax van een private section met signalisatie . . . . . . . . . . . . . . . . . . .
94
B.2 Syntax van een private section met triggers . . . . . . . . . . . . . . . . . . . . .
95
B.3 Syntax van de NPT-descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
B.4 Syntax van de do-it-now-descriptor . . . . . . . . . . . . . . . . . . . . . . . . . .
96
B.5 Syntax van de scheduled-event-descriptor . . . . . . . . . . . . . . . . . . . . . .
97