Methoden voor het manipuleren van MPEG-2 Video en MPEG-2...
116
Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Methoden voor het manipuleren van MPEG-2 Video en MPEG-2 Systems stromen op basis van MPEG-21 BSDL door Jelle Claus Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. Wesley De Neve Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar 2004–2005
Transcript of Methoden voor het manipuleren van MPEG-2 Video en MPEG-2...
Faculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Methoden voor het manipuleren van
MPEG-2 Video en MPEG-2 Systems stromen
op basis van MPEG-21 BSDL
door Jelle Claus
Promotor: prof. dr. ir. R. Van de WalleThesisbegeleider: lic. Wesley De Neve
Afstudeerwerk ingediend tot het behalen van de graad vanLicentiaat in de Informatica
Academiejaar 2004–2005
Toelating tot bruikleen
“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar testellen en delen van de scriptie te kopieren voor persoonlijk gebruik. Elk an-der gebruik valt onder de beperkingen van het auteursrecht, in het bijzondermet betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij hetaanhalen van resultaten uit deze scriptie.”
Jelle Claus, mei 2005
i
Dankwoord
Graag wil ik een dankwoordje richten tot alle mensen die bijgedragen hebbentot de realisatie van deze thesis.
Vooreerst wil ik prof. dr. ir. Rik Van de Walle bedanken voor het opvol-gen van deze scriptie en voor de begeleiding van deze scriptie in het algemeen.Verder wil ik natuurlijk ook mijn begeleider Wesley de Neve bedanken voorde uitstekende begeleiding en voor de vele tips en handige informatie die hijter beschikking stelde om mij op goede weg te zetten. Ook wil ik alle mede-werkers van het Multimedialab bedanken voor de steun en de voorgesteldeoplossingen voor sommige problemen.
Ik wil tenslotte ook mijn vrienden en familie bedanken voor de morelesteun tijdens mijn studies.
ii
Methoden voor het manipuleren vanMPEG-2 Video en MPEG-2 Systems stromen
op basis van MPEG-21 BSDL
doorJelle Claus
Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in deInformatica
Academiejaar 2004–2005
Universiteit GentFaculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Promotor: prof. dr. ir. R. Van de WalleThesisbegeleider: lic. Wesley De Neve
Samenvatting
Deze scriptie behandelt eerst de belangrijkste aspecten van MPEG-2. Hier-bij wordt in bepaalde gevallen speciaal gekeken naar de mogelijkheden dieMPEG-2 te bieden heeft wat betreft schaalbare videocodering, voornamelijktemporele schaalbaarheid. Via een XML-gerelateerde taal zal een beschrij-ving van MPEG-2 Video en MPEG-2 Systems (video, audio, data) wordenopgesteld om zo op een semantisch niveau de bitstroom makkelijk te kunnenaanpassen en een veranderde bitstroom te verkrijgen. Zo zullen we onder an-dere beelden weglaten, de aspect ratio wijzigen (breedbeeld - gewoon beeld)van een videostroom of uit een multimediastroom de audio laten vallen omenkel een videostroom over te houden, met andere woorden een demultiplexerontwerpen via BSDL. We gaan ook wat dieper in op het praktische gebruikvan BSDL en dit doen we via prestatiemetingen. Tenslotte bestuderen weook kort hoe H.264/AVC-stromen in een MPEG-2 Systems stroom kunnengebundeld worden.
Trefwoorden: beschrijving van multimediale data, H.264/AVC, MPEG-21BSDL, MPEG-2 Video, MPEG-2 Systems, multimediastromen, schaalbarevideocodering, videostromen, XML, XSLT
iii
Inhoudsopgave
1 Inleiding 1
1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Het Beoogde Doel . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Inleiding tot MPEG-2 3
2.1 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 MPEG-2 Video . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 MPEG-2 Video Sequence . . . . . . . . . . . . . . . . . 5
2.2.2 Group of Pictures: GOP . . . . . . . . . . . . . . . . . 6
2.2.3 Beeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 MPEG-2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Conversie van een elementaire stroom tot een PES . . . 11
2.3.2 PES header . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Conversie van een PES tot een PS of TS . . . . . . . . 14
3 Inleiding tot MPEG-21 BSDL 17
3.1 Schaalbare videocodering . . . . . . . . . . . . . . . . . . . . . 17
3.2 MPEG-21 DIA BSDL . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Eenvoudig Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 BSDL Specificatie . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Beperkingen . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.3 BSDL-1 Uitbreidingen voor de BSDToBin tool . . . . . 28
3.4.4 BSDL-2 Uitbreidingen voor de BinToBSD tool . . . . . 28
iv
4 BSDL-schema voor MPEG-2 Video 31
4.1 Inleiding: startcodes . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Enkele belangrijke datatypes . . . . . . . . . . . . . . . . . . . 32
4.2.1 Elementaire Datatypes . . . . . . . . . . . . . . . . . . 32
4.2.2 Picture Payload Type . . . . . . . . . . . . . . . . . . 33
4.3 MPEG-2 Video BSDL-schema . . . . . . . . . . . . . . . . . . 34
4.3.1 Root Element: MPEG2Video . . . . . . . . . . . . . . 34
4.3.2 Sequence Header . . . . . . . . . . . . . . . . . . . . . 35
4.3.3 GOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.4 Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Aanpassen van MPEG-2 Video 40
5.1 Veranderen van de Aspect Ratio . . . . . . . . . . . . . . . . . 40
5.2 Weglaten van Beelden . . . . . . . . . . . . . . . . . . . . . . 42
5.3 MPEG-2 Video Statistieken . . . . . . . . . . . . . . . . . . . 44
6 BSDL-schema voor MPEG-2 Systems Programmastromen 45
6.1 Startcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Datatype PacketPayloadType . . . . . . . . . . . . . . . . . . 46
6.3 MPEG-2 Systems BSDL-schema . . . . . . . . . . . . . . . . . 47
6.3.1 Root Element: MPEG2Systems . . . . . . . . . . . . . 47
6.3.2 Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3.3 PackHeader en SystemHeader . . . . . . . . . . . . . . 49
6.3.4 PES-pakketten . . . . . . . . . . . . . . . . . . . . . . 51
6.3.5 PES-header . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.6 Probleem met BSDL-software? . . . . . . . . . . . . . 51
7 Aanpassen van MPEG-2 Systems 53
7.1 Demultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.1.1 Weglaten van PES Audiopakketten . . . . . . . . . . . 53
7.1.2 Extrapoleren van de elementaire stroom . . . . . . . . 56
7.2 Statistieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
v
8 Performantiemetingen van BSDL op MPEG-2 59
8.1 Performantie van BinToBSD . . . . . . . . . . . . . . . . . . . 60
8.1.1 Lange MPEG-2 Systems programmastroom . . . . . . 60
8.1.2 Korte MPEG-2 Video bitstroom . . . . . . . . . . . . . 64
8.2 Performantie van de transformaties . . . . . . . . . . . . . . . 64
8.3 Performantie van BSDToBin . . . . . . . . . . . . . . . . . . . 65
8.3.1 Lange MPEG-2 Systems programmastroom . . . . . . 65
8.3.2 Korte MPEG-2 Video bitstroom . . . . . . . . . . . . . 67
8.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9 H.264/AVC in een MPEG-2 programmastroom 69
10 Besluit 73
A Gebruik van de Thesis DVD 75
A.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.2 Resultaten: Demo’s . . . . . . . . . . . . . . . . . . . . . . . . 76
A.3 BinToBSD, BSDToBin en XSLT Demo’s . . . . . . . . . . . . 76
B MPEG-2 Basic Datatypes Schema 79
C MPEG-2 Simple Types Schema 82
D MPEG-2 Video BSDL-Schema 85
E MPEG-2 Systems BSDL-Schema 91
Bibliografie 104
vi
Lijst van figuren
2.1 Onderdelen MPEG-2 Video . . . . . . . . . . . . . . . . . . . 5
2.2 Compressie van beelden . . . . . . . . . . . . . . . . . . . . . 7
2.3 Verband tussen de drie beeldtypes . . . . . . . . . . . . . . . . 8
2.4 MPEG-2 Video Syntax . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Overzicht van MPEG-2 Systems . . . . . . . . . . . . . . . . . 11
2.6 Conversie van een elementaire stroom tot een Packetised Ele-mentary Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 PES-pakkethoofding . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Structuur van een MPEG-2 Systems Programmastroom . . . . 15
3.1 Praktische werking . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Concept van MPEG-21 DIA . . . . . . . . . . . . . . . . . . . 20
3.3 Vergelijking tussen W3C XML Schema en BSDL Schema . . . 21
3.4 Overzicht van het BSDL raamwerk . . . . . . . . . . . . . . . 22
3.5 Eenvoudig BSDL voorbeeld . . . . . . . . . . . . . . . . . . . 24
3.6 Eenvoudig BSDL-schema . . . . . . . . . . . . . . . . . . . . . 25
4.1 Enkele eenvoudige datatypes . . . . . . . . . . . . . . . . . . . 33
4.2 Datatype Picture Payload Type . . . . . . . . . . . . . . . . . 34
4.3 Root element van het BSDL-schema . . . . . . . . . . . . . . . 34
4.4 Sequence Header . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Declaratie van het GOP-element . . . . . . . . . . . . . . . . . 37
4.6 Declaratie van het Picture-element . . . . . . . . . . . . . . . 38
5.1 Verschil in Aspect Ratio . . . . . . . . . . . . . . . . . . . . . 41
vii
5.2 Verandering van Aspect Ratio: Stylesheet . . . . . . . . . . . 42
5.3 Verwijderen van B-beelden: Stylesheet . . . . . . . . . . . . . 43
5.4 MPEG-2 Video Statistieken: Stylesheet . . . . . . . . . . . . . 44
6.1 Datatype Packet Payload Type . . . . . . . . . . . . . . . . . 47
6.2 Root element van het BSDL-schema voor MPEG-2 Systems . 48
6.3 Het Pack-element (gedeeltelijk) . . . . . . . . . . . . . . . . . 49
6.4 Video Pakket element . . . . . . . . . . . . . . . . . . . . . . . 50
6.5 Bug in BSDL-software? . . . . . . . . . . . . . . . . . . . . . . 52
7.1 Demultiplexer: weglaten audiopakketten . . . . . . . . . . . . 54
7.2 Demultiplexer: XSLT stylesheet . . . . . . . . . . . . . . . . . 55
7.3 Demultiplexer: reconstrueren van de elementaire stroom . . . 56
7.4 MPEG-2 Systems Statistieken: Stylesheet . . . . . . . . . . . 57
8.1 Uitvoeringstijd BinToBSD t.o.v. aantal beelden . . . . . . . . 61
8.2 Grootte van de XML-beschrijving t.o.v. aantal beelden . . . . 62
8.3 Geheugengebruik BinToBSD bij sequentie S6 . . . . . . . . . . 63
8.4 Geheugengebruik BSDToBin bij sequentie S6 . . . . . . . . . . 66
9.1 H.264/AVC in een MPEG-2 programmastroom . . . . . . . . 71
viii
Lijst van tabellen
2.1 MPEG-standaarden . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Aspect Ratio Informatie . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Picture Coding Type . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Toegelaten XML datatypes in BSDL Schema . . . . . . . . . . . . . 27
4.1 MPEG-2 Video Startcodes . . . . . . . . . . . . . . . . . . . . . . 32
6.1 MPEG-2 Systems Startcodes . . . . . . . . . . . . . . . . . . . . . 46
6.2 MPEG-2 Systems PES Startcodes . . . . . . . . . . . . . . . . . . . 46
8.1 Statistieken BintoBSD MPEG-2 Systems . . . . . . . . . . . . . . . 60
8.2 Statistieken BintoBSD MPEG-2 Video . . . . . . . . . . . . . . . . 64
8.3 Enkele XSLT transformaties met behulp van Saxon . . . . . . . . . . 64
8.4 Statistieken BSDToBin MPEG-2 Systems . . . . . . . . . . . . . . . 65
8.5 Statistieken BSDToBin MPEG-2 Video . . . . . . . . . . . . . . . . 67
ix
Lijst van afkortingen
MPEG Moving Picture Experts GroupGroep van experts die reeds verschillende standaarden voor het repre-senteren van multimediale data heeft gedefinieerd.
GOP Group of PicturesEen syntax-element uit de MPEG-2 Video standaard dat een groep vanbeelden aanduidt binnen de videosequentie.
PES Packetised Elementary StreamEen elementaire stroom (video, audio, data, ...), opgedeeld in pakkettenvan variabele of constante lengte, waarbij elk pakket wordt voorzien vaneen header.
MPEG-21 DIA MPEG-21 Digital Item AdaptationDeel 7 van de het MPEG-21 multimediaraamwerk dat verschillendetools specifieert voor het wijzigen van multimediale data.
BSDL Binary Syntax Description LanguageBitstroombeschrijvingstaal om bitstromen te beschrijven in de vormvan XML-documenten. BSDL is een onderdeel van MPEG-21 DIA.
XML eXtensible Markup LanguageUitbreidbare zelfbeschrijvende opmaaktaal om structuur aan te bren-gen in tekstbestanden via opmaakcodes.
XPath XML Path LanguageTaal om aan adressering en selectie te doen binnen een XML-document.
XSLT eXtensible Stylesheet Language TransformationTechnologie voor het omzetten van XML-documenten naar andere do-cumenten. Dit kunnen HTML-documenten, XML-documenten of nogandere soorten zijn.
x
SVC Schaalbare Video CoderingConcept dat het mogelijk maakt om verschillende versies af te leidenuit een bitstroom zonder hercodering door middel van een basislaag enaantal uitbreidingslagen.
UMA Universal Multimedia AccessConcept om dezelfde multimediale data te verspreiden op verschillendesoorten apparaten.
H.264/AVC Advanced Video Coding (MPEG-4 part 10)Deel van de MPEG-4 standaard dat meer efficientere videocoderingspecifieert.
DVD Digital Versatile DiscEen drager van data in de computerwereld dat tot nu toe het meestgebruikt wordt voor films en multimediastromen op te slaan.
HD-DVD High Definition DVDDe DVD-standaard voor de toekomst, nog in volle ontwikkeling. Wel-licht zal H.264/AVC worden gebruikt voor de codering van de video-stroom.
MPEG-4 XMT eXtensible Textual FormatRaamwerk voor de beschrijving van audiovisuele scenes.
xi
Hoofdstuk 1
Inleiding
1.1 Probleemstelling
Door de diversiteit aan apparaten aangesloten op het internet zal men van
een multimediastroom vaak meerdere “versies” opslaan op een multimedia-
server die aangepast zijn aan de specifieke gebruikersparameters (netwerkca-
paciteit, welk apparaat, processorsnelheid, ...). Het is echter onhandig om
telkens een videosequentie te hercoderen in mindere kwaliteit en op te slaan
naast de kwaliteitsversie. Recent streeft men naar SVC ofwel Schaalbare
VideoCodering. Dit betekent dat we bij voorkeur bitstromen in lagen wil-
len aanbieden. Een multimediastroom heeft dan een bepaalde basislaag en
verschillende verbeteringslagen erboven die meer kwaliteit aanbieden.
Het is door dat concept dat men BSDL1 heeft ontwikkeld binnen de
MPEG-21 standaard. Door middel van BSDL zouden we bitstromen kunnen
beschrijven in een XML-bestand om zo via eenvoudige editeerbewerkingen op
dit XML-bestand aangepaste bitstromen te verkrijgen. In deze thesis onder-
zoeken we de mogelijkheden van MPEG-21 BSDL op de MPEG-2 standaard.
1Bitstream Syntax Description Language
1
1.2 Het Beoogde Doel
Het doel van deze thesis is het opstellen van een BSDL-schema, wat een uit-
breiding en eveneens een beperking is op W3C XML Schema, voor MPEG-2
Video en Systems en het toepassen van verschillende transformaties op deze
beschrijvingen. Zo zullen we temporele schaalbaarheid in MPEG-2 Video
aantonen (beelden weglaten), de aspect ratio van een videostroom wijzigen
of de audio weglaten in een multimediastroom om enkel video over te hou-
den. Op die manier kan op een hoog niveau een videostroom door middel
van eenvoudige editeerbewerkingen aangepast worden. Het is immers veel
gemakkelijker een XML-bestand aan te passen dan een bitstroom op zich.
Als we het aangepaste XML-bestand kunnen transformeren naar een aange-
paste videostroom (met behulp van de originele videosequentie) bekomen we
het resultaat van de veranderingen.
We zullen in de eerste hoofdstukken meer in detail bespreken wat MPEG-
2 Video, MPEG-2 Systems en MPEG-21 BSDL precies is. Vervolgens stellen
we een BSDL-schema op voor MPEG-2 Video en voeren we enkele trans-
formaties door op videostromen. We doen dit analoog ook voor MPEG-2
Systems. We analyseren tot slot ook het praktische gebruik van BSDL aan
de hand van prestatiemetingen, en als laatste hoofdstuk bestuderen we kort
het importeren van H.264/AVC2 in een MPEG-2-programmastroom.
2Advanced Video Coding (MPEG-4 deel 10)
2
Hoofdstuk 2
Inleiding tot MPEG-2
2.1 Definitie
MPEG (Moving Picture Experts Group) is een internationale organisatie
die instaat voor de standaardisering van de (de)codering en het opslaan (in
digitaal formaat) van audio -en videoformaten. Deze groep houdt een vijftal
keer per jaar een conferentie, waar zo’n 350 experts aan deelnemen. Voor
meer informatie over de MPEG-groep zie de MPEG webpagina [1].
Een overzicht van de MPEG-standaarden vind je in tabel 2.1.
Standaard ToepassingMPEG-1 Opslag van video en audio (bvb MP3)MPEG-2 Uitbreiding van MPEG-1, Onderdeel van de DVD-standaard voor videoMPEG-4 Codering van Audio Visuele objectenMPEG-7 MetadataMPEG-21 Multimedia-raamwerk
Tabel 2.1: MPEG-standaarden
De MPEG-2 standaard werd ontwikkeld in 1994 en kan bandbreedtes
bereiken tot 40 Mbit/s en meer (afhankelijk van het gebruikte profiel), wat
aanzienlijk hoger is dan de 1.5 MBit/s van MPEG-1. MPEG-2 is commercieel
de meest succesvolle MPEG-standaard. Hier volgen enkele toepassingen van
deze standaard:
3
• Videostandaard voor DVD en digitale televisie (SDTV1, HDTV2)
• Veel gebruikte audiostandaard voor oudere DVD’s, nu gebruikt men
eerder Dolby Surround of AC3 (Dolby Digital).
• DBS3, CATV4, ...
De MPEG-2-standaard bevat een tiental onderdelen. De belangrijkste
drie, die we in deze thesis even nader bekijken, zijn “Video”, “Audio” en
“Systems”. MPEG-2 Video zorgt voor de compressie van digitale video tot
elementaire videostromen. MPEG-2 Audio zorgt voor de compressie van
digitale audio tot elementaire audiostromen. MPEG-2 Systems voegt de-
ze elementaire stromen samen (audio, video en data) tot een multimedia-
stroom. We zullen eerst MPEG-2 Video onder de loep nemen, meer bepaald
de video-syntax, die heel belangrijk zal zijn voor het opstellen van een syntax-
beschrijving.
2.2 MPEG-2 Video
Een MPEG-2-videostroom is opgebouwd in lagen. Dit blijkt uit Figuur 2.1.
Een videostroom, gecodeerd met MPEG-2-Video, bestaat uit verschillende
videosequenties. Elke videosequentie bevat verschillende groepen van beelden
(GOP: “Group of Pictures”). Elke GOP bevat verschillende beelden, waarbij
elk beeld is opgebouwd uit slices. Deze slices bevatten macroblokken die dan
weer zijn opgebouwd uit blokken. Elk onderdeel (bijvoorbeeld een GOP of
een beeld) bevat naast de verschillende elementen van een onderliggende laag,
ook headers met extra informatie, en natuurlijk ook startcodes zodat een
decoder de onderdelen kan herkennen in het videobestand. Zo zal de Video
Sequence een Video Sequence Header bevatten en verschillende groepen van
beelden. Iedere GOP zal ook een GOP header hebben en erna verschillende
beelden, ...
1Standard Definition TeleVision2High Definition TeleVision3Direct Broadcast Satellite4Cable Antenna Television
4
11
2.3. MPEG-2 video Het belangrijkste onderdeel van de MPEG-2-videostroomsyntax zijn de headers. Deze
headers zijn hiërarchisch gestructureerd. Een overzicht van de verschillende headers is terug te vinden in Tabel 2-6. We zullen nu in de volgende paragrafen deze verschillende headers kort bespreken en zo komen tot een overzicht van de MPEG-2-videostroomsyntax. De bedoeling hiervan is om enkele begrippen die veelvuldig voorkomen bij scrambling hier te bespreken, zodanig dat de betekenis duidelijk is. Voor meer informatie over MPEG-2 video, zie [2-3].
Tabel 2-6: Overzicht van de verschillende headers van de MPEG-2-videostroomsyntax
De manier waarop de verschillende headers hiërarchisch gestructureerd zijn is terug te
vinden in Figuur 2-5. Uit deze figuur blijkt dat een MPEG-2-videostroom bestaat uit 6 lagen. De bovenste laag (laag 1) bestaat uit verschillende videosequenties. Hierbij heeft elke videosequentie een videosequentieheader en verder een groep van beelden (“Group of Pictures”, GOP) (laag 2). Elke GOP bestaat uit een GOP-header en verder een reeks beelden (laag 3). Elk beeld bestaat uit een beeldheader en een reeks slices (laag 4), elke slice bestaat uit een sliceheader en enkele macroblokken (laag 5) en elke macroblok bestaat uit een header en enkele blokken (laag 6). Elke header heeft zijn eigen functionaliteiten, zoals weergegeven in Tabel 2-6 en het zijn nu deze functionaliteiten die we verder zullen bespreken, samen met enkele bijkomende eigenschappen.
Figuur 2-5: Overzicht van de verschillende headers van de MPEG-2-videostroomsyntax
Syntax header Functie Video Sequence Header Bevat de basisparameters (grootte van de
videobeelden, maximale bitrate, …). Group of Pictures Header
Zorgt voor willekeurige toegang, snel opzoeken en wijzigen van de videostroom.
Picture Header Het type beeld: I, P of B beeld en tijdelijke referentie.
Slice Header Verzameling macroblokken. Macroblok Header De 16 x 16 bewegingsvectoreenheid. Blok Bevat de data voor de gequantiseerde DCT-
coëfficiënten van een 8 x 8 blok in een macroblok.
Figuur 2.1: Onderdelen MPEG-2 Video
2.2.1 MPEG-2 Video Sequence
Een Video Sequence begint met de sequence header (waarin de video sequence
start code vervat zit), gevolgd door een of meerdere groepen van beelden en
eindigt met de video sequence end code.
De video sequence header bevat belangrijke informatie over de video-
stroom zoals de resolutie van de beelden, het aantal weer te geven beelden
per seconde (“frame rate” ofwel beeldsnelheid), grootte van de buffers, maxi-
mum aantal bits per beeld, en nog heel wat bijkomende globale parameters.
We willen echter een parameter uit de header even nader bekijken: de As-
pect Ratio, namelijk de verhouding tussen de breedte en de hoogte van de
beelden.
Iedereen kent wellicht het verschil tussen een gewone TV en een breedbeeld-
televisie. De aspect ratio ligt in nauw verband met de begrippen breedbeeld
en “gewoon” beeld. De Aspect Ratio definieert hoe een bitstroom moet
weergegeven worden met betrekking tot de breedte/hoogte-verhouding. Het
formaat 4:3 is algemeen bekend als een normaal beeld, de oudere standaard,
terwijl het formaat 16:9 alsmaar meer gebruikt wordt voor breedbeeld. Dik-
wijls komt het wel eens voor dat de aspect ratio verkeerd is ingesteld en men,
5
informeel uitgedrukt, “uitgerokken” mensen ziet op het scherm, met andere
woorden dat een videosequentie voor breedbeeld wordt weergegeven met een
4:3 aspect ratio en dus de hoogte van de beelden wordt verlengd. Een manier
om de bitstroom te corrigeren op vlak van aspect ratio via BSDL, zullen we
later bespreken.
Zoals gezegd wordt de aspect ratio in de Video Sequence Header opgeslaan
als de aspect ratio information. In tabel 2.2 zien we dat een aspect ratio
van 4:3 wordt opgeslaan in de bitstroom als “0010”, de waarde 2 in het
decimaal stelsel. Breedbeeld aspect ratio (16:9) zien we uitgedrukt met de
decimale waarde drie. Andere waarden voor de aspect ratio worden heel
zelden gebruikt.
aspect ratio information Aspect Ratio0000 forbidden0001 -0010 4:30011 16:90100 2.21:10101 reserved1111 reserved
Tabel 2.2: Aspect Ratio Informatie
2.2.2 Group of Pictures: GOP
Een GOP bestaat eveneens uit een header gevolgd door een reeks van beel-
den. De bedoeling van een GOP is dat men op die manier willekeurige
toegang, snel opzoeken en vooruitspoelen van een sequentie kan toelaten.
De belangrijkste info in de GOP header bestaat uit tijdscodes die gebruikt
worden tijdens het afspelen van de sequentie. Een GOP bevat dus een reeks
beelden waarvan het eerste beeld altijd een I-beeld (zie later) moet zijn. In
de volgende sectie bespreken we de verschillende soorten beelden.
6
2.2.3 Beeld
Een beeld bestaat uit drie componenten, die de helderheid (Y) en de chro-
minantie (kleur) aanduiden (Cb en Cr). In de picture header vinden we
onder meer het picture coding type (welk type beeld), een tijdscode en af-
hankelijk van het type beeld, informatie over de bewegingsvectoren die nodig
zijn om het beeld te kunnen decoderen. Een beeld in niet-gecomprimeerde
vorm wordt in de taal van videocodering ook een Presentation Unit genoemd.
Een gecodeerd beeld is dan genaamd een Access Unit. Op Figuur 2.2 zien we
hoe een opeenvolging van beelden kan worden gecodeerd tot gecomprimeerde
video.
• A number of additional ‘private data’ chan-nels may be accommodated. Private data is adata stream whose content is not specified byMPEG. Such data streams may be used tocarry data services such as: teletext; additionalservice information specific to a particularnetwork; commands intended to controlmodulation, and network distribution equip-ment; any other type of data required by aparticular application.
There are some notable multiplex characteristics notspecified by MPEG:
• There is no form of error protection within themultiplex. Error protection and the subsequentmodulation of the MPEG-2 multiplex is chosento suit the characteristics of the channel orstorage medium and is not specified by MPEG.
• There is no electrical or physical specificationfor the MPEG-2 multiplex, so a designer mayuse the signal levels or connector types that bestsuit the application.
2. PROGRAMME AND TRANSPORTSTREAMS
The MPEG-2 Systems Specification defines two alter-native multiplexes. One is called a ‘transport stream’,the other is called a ‘programme stream’. Each is opti-mised for a different set of applications.
2.1 The programme stream
This multiplex is based on the established MPEG-1multiplex. Like the MPEG-1 multiplex, it can accom-modate asingle programmeonly and is intended forthe storage and retrieval of programme material fromdigital storage media.
A programme stream is intended for use in error-free
environments because it is rather susceptible to errors.There are two reasons for this. Firstly, the programmestream comprises a succession of relatively long andvariable length packets. Each packet begins with apacket header. An error occurring in the packet headermay cause the loss of the entire packet. As programmestream packets may contain many kilobytes of data,the loss of a single packet may represent the loss orcorruption of an entire video frame. Secondly, the vari-ability of the packet lengths means that a decodercannot predict where one packet will finish and a newone will start. Instead, it must read and interpret thepacket length field contained in each packet header. Ifthis packet length field is corrupted by an error, the de-coder will lose synchronism with the stream, againresulting in the loss of at least one packet.
2.2 The transport stream
A multiplex devised formulti-programmeapplicationssuch as broadcasting, so that a single transport streamcan accommodate many independent programmes. Itcomprises a succession of 188-byte-long packetscalled transport packets. The use of short, fixed-length packets means that the transport stream is not assusceptible to errors as the programme stream. Fur-ther, each 188-byte-long packet is easily givenadditional error protection by processing it through astandard error protection process such as Reed-Solo-mon encoding. The improved error resilience of thetransport stream means that it has a better chance ofsurviving the error-prone channels to be found in abroadcast environment, for example.
It might seem that the transport stream is clearly thebetter of the two multiplexes with its increased errorresilience and ability to carry many simultaneous pro-grammes. However, it should be remembered that thetransport stream is a more sophisticated multiplex thanthe programme stream and is consequently more diffi-cult to create and to demultiplex. It is also less like thewell-established MPEG-1 multiplex.
ruwe digitale video stroom'Presentation Unit'
'Access Unit'
gecompr.'I' beeld
(100 kbytes)*
* De echte grootte hangt af van de vooropgestelde bitrateen de complexiteit van het beeld
MPEG-2 compressie tot 5Mbit/s
Beeld(830 kbytes)
Beeld(830 kbytes)
Beeld(830 kbytes)
gecompresseerd'B' beeld(12 kbytes)*
gecompr.'B' beeld
(12 kbytes)*
gecompr.'P' beeld(33 kbytes)*
Beeld(830 kbytes)
Fig. 2 - The compression of ‘presentationunits’ to yield ‘access units’.
(N.B. The ‘video elementary’ streamconsists of asuccessionof ‘access units’.)
(R023/025) - 2 -Figuur 2.2: Compressie van beelden
Om een zo goed mogelijke compressie te realiseren zullen sommige beel-
den voor hun reconstructie afhankelijk zijn van andere beelden. Als men een
beeldsnelheid heeft van 30 beelden per seconde en we bestuderen de beelden
apart, zullen er op veel beelden “gelijke” delen staan die niet hergecodeerd
moeten worden indien we beelden afhankelijk maken van andere. Daarom
gebruikt MPEG-2 ook verschillende beeldtypen om aan te duiden welke beel-
den enkel maar gedecodeerd kunnen worden met behulp van andere beelden.
Er zijn drie soorten beelden, elk met een aantal eigen karakteristieken: intra-
gecodeerde beelden (I-beelden, intracoded), voorspelde beelden (P-beelden,
7
predicted) en bidirectioneel voorspelde beelden (B-beelden, bidirectional).
Een voorbeeld van de afhankelijkheden van de verschillende beeldtypes wordt
weergegeven in Figuur 2.3.
vi ITU-T Rec. H.262 (2000 E)
Intro. 4 The scalable and the non-scalable syntax
The full syntax can be divided into two major categories: One is the non-scalable syntax, which is structured as a super set of the syntax defined in ISO/IEC 11172-2. The main feature of the non-scalable syntax is the extra compression tools for interlaced video signals. The second is the scalable syntax, the key property of which is to enable the reconstruction of useful video from pieces of a total bitstream. This is achieved by structuring the total bitstream in two or more layers, starting from a standalone base layer and adding a number of enhancement layers. The base layer can use the non-scalable syntax, or in some situations conform to the ISO/IEC 11172-2 syntax.
Intro. 4.1 Overview of the non-scalable syntax
The coded representation defined in the non-scalable syntax achieves a high compression ratio while preserving good image quality. The algorithm is not lossless as the exact sample values are not preserved during coding. Obtaining good image quality at the bitrates of interest demands very high compression, which is not achievable with intra picture coding alone. The need for random access, however, is best satisfied with pure intra picture coding. The choice of the techniques is based on the need to balance a high image quality and compression ratio with the requirement to make random access to the coded bitstream.
A number of techniques are used to achieve high compression. The algorithm first uses block-based motion compensation to reduce the temporal redundancy. Motion compensation is used both for causal prediction of the current picture from a previous picture, and for non-causal, interpolative prediction from past and future pictures. Motion vectors are defined for each 16-sample by 16-line region of the picture. The prediction error, is further compressed using the Discrete Cosine Transform (DCT) to remove spatial correlation before it is quantised in an irreversible process that discards the less important information. Finally, the motion vectors are combined with the quantised DCT information, and encoded using variable length codes.
Intro. 4.1.1 Temporal processing
Because of the conflicting requirements of random access and highly efficient compression, three main picture types are defined. Intra Coded Pictures (I-Pictures) are coded without reference to other pictures. They provide access points to the coded sequence where decoding can begin, but are coded with only moderate compression. Predictive Coded Pictures (P-Pictures) are coded more efficiently using motion compensated prediction from a past intra or predictive coded picture and are generally used as a reference for further prediction. Bidirectionally-predictive Coded Pictures (B-Pictures) provide the highest degree of compression but require both past and future reference pictures for motion compensation. Bidirectionally-predictive coded pictures are never used as references for prediction (except in the case that the resulting picture is used as a reference in a spatially scalable enhancement layer). The organisation of the three picture types in a sequence is very flexible. The choice is left to the encoder and will depend on the requirements of the application. Figure Intro. 1 illustrates an example of the relationship among the three different picture types.
I B B P B B B P
Bidirectionele Interpolatie
Voorspelling
Figure Intro. 1 – Example of temporal picture structure
FIGURE Intro. 1/H.262...[D01] = 8 CM
Figuur 2.3: Verband tussen de drie beeldtypes
I-beelden
Intragecodeerde beelden worden gecodeerd zonder informatie van andere
beelden. Ze worden als het ware als een JPEG-figuur opgenomen in de bit-
stroom. Zo zorgen I-beelden voor willekeurige toegang in de videosequentie
en is het nu duidelijk waarom een GOP moet beginnen met een I-beeld. In
termen van compressie zijn I-beelden duidelijk inefficient en zullen tot tien
keer meer bytes nodig hebben in de bitstroom dan B-beelden.
P-beelden
Zoals we zien op Figuur 2.3 maken voorspelde beelden (P) gebruik van het
voorgaande I- of P-beeld om ge(de)codeerd te worden. Net zoals I-beelden
8
kunnen P-beelden verder gebruikt worden door andere P- of B-beelden. P-
beelden maken dus gebruik van bewegingsvectoren ten opzichte van het vorige
P -of I-beeld. Dit zorgt voor een grotere compressie van de beelden.
B-beelden
Bidirectionele beelden maken gebruik van zowel een voorgaand beeld als van
een toekomstig beeld. Deze beelden kunnen I- of P-beelden zijn. Door dit
dubbel gebruik van bewegingsvectoren zorgen B-beelden voor de grootste
compressie, maar zijn niet decodeerbaar zonder twee andere beelden. Deze
beelden zorgen ook voor een delay en complexe strategie van buffering.
We vonden dus de picture coding type dus in de picture header. Net
zoals bij de aspect ratio zullen we met dit element in de picture header veel
werken in deze thesis. We zullen namelijk B-beelden weglaten, om te zien hoe
temporele schaalbaarheid in MPEG-2 Video kan worden toegepast. Waarom
we voor B-beelden kiezen is redelijk duidelijk. Deze beelden zullen immers
zonder neveneffecten kunnen weggelaten worden omdat ze zelf niet verder
gebruikt worden door andere beelden. Zouden we immers P-beelden of I-
beelden weglaten dan zouden vele B-beelden niet meer decodeerbaar zijn,
resulterend in artefacten en fouten in de weergave van de beelden. In tabel
2.3 vinden we de mogelijke waarden voor het element picture coding type in
de picture header.
Zo is het duidelijk dat B-beelden de decimale waarde drie (binair 011) heb-
ben, en op die manier zullen we in een syntax-beschrijving van een MPEG-2
videostroom B-beelden kunnen onderscheiden van andere.
Voor meer gedetailleerde informatie omtrent MPEG-2 Video is [2] een
interessant werk. De volledige MPEG-2 Video specificatie van MPEG vinden
we in [3].
Op Figuur 2.4 vinden we een syntax diagram terug voor MPEG-2 Video
tot op het Picture-niveau.
9
picture coding type type beeld000 forbidden001 I-beeld010 P-beeld011 B-beeld100 forbidden101 reserved110 reserved111 reserved
Tabel 2.3: Picture Coding Type
ISO/IEC 13818-2 : 2000 (E)
36 ITU-T Rec. H.262 (2000 E)
This subclause does not adequately document the block layer syntax when data partitioning is used. See 7.10.
6.3 Video bitstream semantics
6.3.1 Semantic rules for higher syntactic structures
This subclause details the rules that govern the way in which the higher level syntactic elements may be combined together to produce a legal bitstream. Subsequent clauses detail the semantic meaning of all fields in the video bitstream.
Figure 6-15 illustrates the high level structure of the video bitstream.
ISO/IEC 11172-2: MPEG-1 Video
Sequence Header
Sequence Header
Sequence Extension
Extensionand User
UserData
Group ofPic. Hdr.
Picture Header
Pic. CodingExtension
Extensionand User
Picture Data
Sequence End
Figure 6-15 – High level bitstream organisation
Na een GOP, moet het eerste beeld (van een nieuwe GOP) een I-beeld zijn*
*
FIGURE 6-15/H.262...[D16] = 9 CM
block( i ) { No. of bits Mnemonic
if ( pattern_code[i] ) {
if ( macroblock_intra ) {
if ( i < 4 ) {
dct_dc_size_luminance 2-9 vlclbf
if(dct_dc_size_luminance != 0)
dct_dc_differential 1-11 uimsbf
} else {
dct_dc_size_chrominance 2-10 vlclbf
if(dct_dc_size_chrominance != 0)
dct_dc_differential 1-11 uimsbf
}
} else {
First DCT coefficient 2-24 vlclbf
}
while ( nextbits() != End of block )
Subsequent DCT coefficients 3-24 vlclbf
End of block 2 or 4 vlclbf
}
}
Figuur 2.4: MPEG-2 Video Syntax
2.3 MPEG-2 Systems
MPEG-2 Systems zorgt voor het samenvoegen (multiplexeren) van multime-
diastromen. Hierbij zal synchronisatie tussen een video -en een audiostroom
een heel belangrijke rol spelen. Met behulp van de Systems-standaard kan
men audiostromen van verschillende talen opnemen in een Systems-stroom,
videostromen met verschillende resoluties meesturen en andere data (bijvoor-
beeld voor menu’s van een DVD, teletekst, ...) allemaal tot een stroom mul-
tiplexeren. MPEG-2 Systems definieert twee soorten multiplex-standaarden
namelijk de programmastroom (PS) en de transport-stroom (TS). Op Fi-
10
guur 2.2 konden we zien hoe een MPEG-2 video elementaire stroom werd
opgebouwd uit ruwe video data (conversie van Presentation Units tot Access
Units). We bespreken nu het verdere verloop hoe we een programmastroom
construeren uit 2 of meer elementaire stromen. Op Figuur 2.5 zien we een
overzicht van de MPEG-2 Systems specificatie.
ITU-T Rec. H.222.0 (2000 E) ix
Introduction
The systems part of this Recommendation | International Standard addresses the combining of one or more elementary streams of video and audio, as well as other data, into single or multiple streams which are suitable for storage or transmission. Systems coding follows the syntactical and semantic rules imposed by this Specification and provides information to enable synchronized decoding of decoder buffers over a wide range of retrieval or receipt conditions.
System coding shall be specified in two forms: the Transport Stream and the Program Stream. Each is optimized for a different set of applications. Both the Transport Stream and Program Stream defined in this Recommendation | International Standard provide coding syntax which is necessary and sufficient to synchronize the decoding and presentation of the video and audio information, while ensuring that data buffers in the decoders do not overflow or underflow. Information is coded in the syntax using time stamps concerning the decoding and presentation of coded audio and visual data and time stamps concerning the delivery of the data stream itself. Both stream definitions are packet-oriented multiplexes.
The basic multiplexing approach for single video and audio elementary streams is illustrated in Figure Intro. 1. The video and audio data is encoded as described in ITU-T Rec. H.262 | ISO/IEC 13818-2 and ISO/IEC 13818-3. The resulting compressed elementary streams are packetized to produce PES packets. Information needed to use PES packets independently of either Transport Streams or Program Streams may be added when PES packets are formed. This information is not needed and need not be added when PES packets are further combined with system level information to form Transport Streams or Program Streams. This systems standard covers those processes to the right of the vertical dashed line.
Video-encoder
Audio-encoder
Opdelen in pakketten
Opdelen in pakketten
ruwe Videodata
ruwe Audiodata
ProgrammaStroom
TransportStroom
Video PES
Audio PES
PS
mux
TS
mux
MPEG-2 Systems Specificatie
Figure Intro. 1 – Simplified overview of the scope of this Recommendation | International Standard
The Program Stream is analogous and similar to ISO/IEC 11172 Systems layer. It results from combining one or more streams of PES packets, which have a common time base, into a single stream.
For applications that require the elementary streams which comprise a single program to be in separate streams which are not multiplexed, the elementary streams can also be encoded as separate Program Streams, one per elementary stream, with a common time base. In this case the values encoded in the SCR fields of the various streams shall be consistent.
Like the single Program Stream, all elementary streams can be decoded with synchronization.
Figuur 2.5: Overzicht van MPEG-2 Systems
2.3.1 Conversie van een elementaire stroom tot een
PES
Een elementaire stroom (audio, video, data, ...) op zich wordt opgedeeld in
pakketten van ofwel constante ofwel variabele lengte, dit om praktische zaken
zoals broadcasting mogelijk te maken. Figuur 2.6 verduidelijkt hoe men een
elementaire stroom opdeelt in pakketten. Deze PES5 bestaat dus uit PES-
pakketten. Elk PES-pakket bestaat uit een header, samen met de eigenlijke
data (payload). De payload bestaat uit bytes, sequentieel genomen van de
5Packetised Elementary Stream
11
originele elementaire stroom. Op eender welk moment wordt de elementai-
re stroom dus afgebroken en zet men een PES header tussen de data zodat
we een stroom van PES-pakketten bekomen. Dus, een nieuwe Access Unit
of beeld kan op gelijk welk punt in de payload van een PES-pakket voorko-
men, en verschillende kleine Access Units kunnen zich ook in 1 PES-pakket
bevinden. Zoals gezegd kunnen PES-pakketten van variabele grootte zijn.
Dit zorgt voor een grote flexibiliteit voor een programmeur die een MPEG-2
multiplexer zou ontwerpen. Men kan dan bijvoorbeeld de lengte van de PES-
pakketten laten varieren om toch het begin van de payload van een pakket
overeen te laten stemmen met het begin van een Access Unit.
3. PRESENTATION UNITS AND ACCESSUNITS
Fig. 2 shows an uncompressed digital video sequencebeing MPEG-coded to a target data rate of 5 Mbit/s.Each picture* in its uncompressed form is termed apresentation unit. The coder compresses each presen-tation unit to give acoded picturewhich is termed anaccess unit. Note that video access units are not all thesame size. Their size depends on whether they repre-sent an ‘I’, ‘P’ or ‘B’ picture2, 3 and also on howdifficult the picture was to code.
The result of the MPEG-encoding of a video sequenceis a succession of video access units; it is this succes-sion of access units that comprises thevideoelementary stream.
Similarly, the result of the MPEG-encoding of audio isa succession of audio access units;4 it is this successionof access units that comprises anaudio elementarystream. Each audio access unit typically contains afew tens of milliseconds of compressed audio.
4. PACKETISED ELEMENTARY STREAMS
The next stage in the creation of either of the MPEG-2multiplexes is to convert each elementary stream intoa Packetised Elementary Stream(PES). A Packet-ised Elementary Stream consists entirely ofPES-packets, as shown in Fig. 3.
A PES-packet consists of aheader and apayload.The payload simply consists of data bytes taken se-quentially from the original elementary stream. Thereis no requirement to align the start of access units andthe start of PES-packet payloads. Thus, a new accessunit may start at any point in the payload of a PES-packet and it is possible forseveralsmall access unitsto be contained in asinglePES-packet.
PES-packets may be of variable length subject to a
maximum length of 64 kBytes. (There is one excep-tion to this: in the case of a video packetisedelementary stream when carried in a transport stream,where PES-packets may be of unbounded length.) Thedesigner of an MPEG-2 multiplexer may choose to ex-ploit this flexibility in a number of ways. Thepossibilities include simply using a fixed PES-packetlength or varying the length in order to align the startof access units with the start of PES-packet payloads.
4.1 PES packet header
Fig. 4 shows the fields comprising aPES-packetheader. The first four (i.e. The ‘PES-packet startcode prefix’ plus the ‘stream_id’) comprise the PES-packet start code. This combination of 32 bits isguaranteed not to arise in the packetised elementarystream other than at the start of a PES-packet.(There is a general exception to this; the contents ofprivate data are not constrained by MPEG, and assuch they may contain emulations of the PES-packetstart code.)
4.2 Stream_id byte
The stream_id byte distinguishes PES-packets be-longing to one elementary stream from those ofanother within the same programme. MPEG specifiesthe permitted values for this field, including 32 avail-able for audio elementary streams and 16 for videoelementary streams.
4.3 The flags
Flags 1 and Flags 2 are ‘indicator bits’ which showthe presence or absence of the various optional fieldsthat may be included in a PES-packet header. Theseoptional fields convey additional information aboutthe packetised elementary stream, such as: whetherscrambled or not, relative priority, copyright informa-tion, and an optional error-check field for the packet.
elementarystream comprising access units(video, audio or other)
access unit
Packetised Elementary Stream(PES) PES-packet PES-packet payload
PES-packet header
Fig. 3 - Conversion of anelementary stream to a Packetised
Elementary Stream.
* A ‘picture’ can be represented by a frame or field. See Ref. 2 for details.
(R023/025) - 3 -
Figuur 2.6: Conversie van een elementaire stroom tot een Packetised ElementaryStream
2.3.2 PES header
Op figuur 2.7 zien we de structuur van een PES-pakket. We bespreken kort
de belangrijkste onderdelen.
PES pakket startcode prefix
De eerste 4 bytes (de PES pakket startcode prefix en de stream id) van de
pakketheader wordt de PES pakket startcode genoemd. Deze combinatie
12
4.4 Time stamps
Of particular importance are the two most significantbits of flags 2 markedP and D in Fig. 4. When set,these indicate the presence of aPresentation TimeStamp (PTS) field and aDecoding Time Stamp(DTS) field respectively, within the PES-packetheader. Time stamps are the mechanism provided bythe MPEG-2 systems layer to ensurecorrect synchro-nismbetween related elementary streams at a decoder.
4.5 Data length field
The PES header data length fieldis the last of themandatory bytes in the PES-packet header. Its valuegives the number of bytes of optional PES-packetheader data present in the PES-packet header beforethe first byte of the PES-packet payload is reached.(There are 25 optional PES-packet header fieldswhich between them may total nearly 200 bytes ofadditional data.)
5. THE PROGRAMME STREAM MULTIPLEX
In a programme stream, PES-packets that are derivedfrom the contributing elementary streams are organ-ised into ‘packs’ (see Fig. 5). A pack comprises a
‘pack-header’, an optional ‘system-header’ and anynumber of PES-packets taken from any of the contrib-uting elementary streams, in any order. There is noconstraint on the length of a pack, except that a packheader must occur at least every 0.7 seconds withinthe program stream, as the pack header contains im-portant timing information (the system clockreference). The system header contains a summary ofthe characteristics of the programme stream such as:its maximum data rate; the number of contributingvideo and audio elementary streams; further timing in-formation. A decoder may use the informationcontained in a system header to determine whether it iscapable of decoding the programme stream or not.
6. THE TRANSPORT STREAM MULTIPLEX
The transport stream multiplex consists entirely ofshort, fixed length transport packets (Fig. 6). A trans-port packet (see Fig. 7) is always 188 bytes long. Itcomprises a4-byte headerfollowed by anadaptationfield or a payload or both. In a transport stream, thePES-packets from the various elementary streams areeach divided among the payload parts of a number oftransport packets.
Fig. 8 shows how each PES-packet is divided into thepayloads of a number of transport packets. The proc-ess is subject to two constraints:
1. The first byte of each PES-packet must becomethe first byte of a transport packet payload.
2. Only data taken from one PES-packet may becarried in any one transport packet.
A PES-packet is unlikely to fill the payloads of aninteger number of transport packets, exactly. As shownin Fig. 8, it will often be the case that there are insuffi-cient bytes to completely fill the payload of the finaltransport packet. So as not to contravene the two con-straints of the previous paragraph, the excess space isdeliberately wasted by including an adaptation field ofappropriate length for this particular transport packet.This wastage can be minimised through careful choiceof PES-packet length. This also provides an argumentfor the use of long PES-packet lengths, as this will en-sure that a greater proportion of transport packets arecompletely filled.
PES-pakket
000
000
000
000
000
000
000
001
X X X X X X X XX X X X X X X XX X X X X X X X1 0 X X X X X XP D X X X X X XX X X X X X X X
PES-pakket start code prefix
stream_id
PES-pakket lengte
flags 1flags 2PES header data lengte
Presentation Time Stamp (optioneel)
Decoding Time Stamp (optioneel)
verdere optionele velden
msb lsb
Fig. 4 - A PES-packet header.
DV V VA
VV VAV
optional systemheader
pack header
video PES-packet audio PES-packet data PES-packet
'pack'
pack header pack header
V
V A D
Fig. 5 - Structure of the MPEG-2‘Programme Stream’ multiplex.
(R023/025) - 4 -
Figuur 2.7: PES-pakkethoofding
van 32 bits zal enkel voorkomen bij het begin van een pakket. Ergens anders
wordt dit niet toegelaten, zodat de decoder de start van een pakket kan
herkennen. Het prefix wordt gevormd door 23 0-bits en vervolgens een 1-bit.
ID van de elementaire stroom
De laatste byte van de startcode is de byte die de stream id aangeeft. Deze
byte onderscheidt de vele soorten pakketten die zich in een systems stroom
kunnen bevinden. MPEG definieert bijvoorbeeld 32 toegelaten waarden voor
de stream id byte die een audiopakket aanduidt. Daarnaast zijn er nog 16
mogelijke waarden voor een videopakket. Een hexadecimale representatie
van de mogelijke startcodes voor een PES videopakket zijn de waarden tussen
0x000001E0 en 0x000001EF. Hierin herkennen we het prefix 0x000001.
13
Vlaggen
Zoals we zien op figuur 2.7 zijn er 2 bytes na de startcode die de pakketleng-
te aanduiden en vervolgens 2 bytes met verschillende vlaggen. Deze 16 bits
zijn indicator bits die de aanwezigheid van optionele velden aanduiden. Deze
optionele velden komen dan voor aan de staart van de header. Ze bevat-
ten extra informatie over de stroom zoals eventuele beveiliging (scrambling),
foutcorrectie velden en informatie over het auteursrecht (copyright).
Tijdscodes
De belangrijkste indicatiebits zijn de 2 meest betekenende bits van flags 2,
gemarkeerd P en D op figuur 2.7. Wanneer deze op ’1’ staan duiden ze de
aanwezigheid aan van een Presentatie Tijdscode (PTS: Presentation Time
Stamp) veld en van een Decodeer Tijdscode (DTS: Decoding Time Stamp)
veld in de header. Deze tijdscodes zorgen voor de synchronisering tussen
gerelateerde elementaire stromen in de multimediastroom.
PES header data lengte
De laatste verplichte byte in de header wordt ingenomen door het veld PES
Header Data Length. De waarde geeft het aantal bytes aan van optionele data
in de PES-pakket header, alvorens de eerste byte van de payload is bereikt.
Er zijn immers 25 optionele velden en de lengte van de header kan dus in
totaal redelijk groot zijn.
2.3.3 Conversie van een PES tot een PS of TS
MPEG-2 Systems definieert vervolgens 2 soorten stromen waarin PES-pakketten
zullen gemultiplexeerd worden. Over het algemeen worden programmastro-
men gebruikt voor het opslaan van multimediale data op een harde schijf,
DVD, ... Anders gezegd gebruikt men programmastromen in zo goed als
foutvrije omgevingen, terwijl transportstromen ontworpen zijn voor gebruik
bij streaming en andere foutgevoelige omgevingen.
14
PES tot Programmastroom (PS)
4.4 Time stamps
Of particular importance are the two most significantbits of flags 2 markedP and D in Fig. 4. When set,these indicate the presence of aPresentation TimeStamp (PTS) field and aDecoding Time Stamp(DTS) field respectively, within the PES-packetheader. Time stamps are the mechanism provided bythe MPEG-2 systems layer to ensurecorrect synchro-nismbetween related elementary streams at a decoder.
4.5 Data length field
The PES header data length fieldis the last of themandatory bytes in the PES-packet header. Its valuegives the number of bytes of optional PES-packetheader data present in the PES-packet header beforethe first byte of the PES-packet payload is reached.(There are 25 optional PES-packet header fieldswhich between them may total nearly 200 bytes ofadditional data.)
5. THE PROGRAMME STREAM MULTIPLEX
In a programme stream, PES-packets that are derivedfrom the contributing elementary streams are organ-ised into ‘packs’ (see Fig. 5). A pack comprises a
‘pack-header’, an optional ‘system-header’ and anynumber of PES-packets taken from any of the contrib-uting elementary streams, in any order. There is noconstraint on the length of a pack, except that a packheader must occur at least every 0.7 seconds withinthe program stream, as the pack header contains im-portant timing information (the system clockreference). The system header contains a summary ofthe characteristics of the programme stream such as:its maximum data rate; the number of contributingvideo and audio elementary streams; further timing in-formation. A decoder may use the informationcontained in a system header to determine whether it iscapable of decoding the programme stream or not.
6. THE TRANSPORT STREAM MULTIPLEX
The transport stream multiplex consists entirely ofshort, fixed length transport packets (Fig. 6). A trans-port packet (see Fig. 7) is always 188 bytes long. Itcomprises a4-byte headerfollowed by anadaptationfield or a payload or both. In a transport stream, thePES-packets from the various elementary streams areeach divided among the payload parts of a number oftransport packets.
Fig. 8 shows how each PES-packet is divided into thepayloads of a number of transport packets. The proc-ess is subject to two constraints:
1. The first byte of each PES-packet must becomethe first byte of a transport packet payload.
2. Only data taken from one PES-packet may becarried in any one transport packet.
A PES-packet is unlikely to fill the payloads of aninteger number of transport packets, exactly. As shownin Fig. 8, it will often be the case that there are insuffi-cient bytes to completely fill the payload of the finaltransport packet. So as not to contravene the two con-straints of the previous paragraph, the excess space isdeliberately wasted by including an adaptation field ofappropriate length for this particular transport packet.This wastage can be minimised through careful choiceof PES-packet length. This also provides an argumentfor the use of long PES-packet lengths, as this will en-sure that a greater proportion of transport packets arecompletely filled.
PES-packet
000
000
000
000
000
000
000
001
X X X X X X X XX X X X X X X XX X X X X X X X1 0 X X X X X XP D X X X X X XX X X X X X X X
PES-packet start code prefix
stream_id
PES-packet length
flags 1flags 2PES header data length
presentation time stamp (if present)
decoding time stamp (if present)
further optional fields
msb lsb
Fig. 4 - A PES-packet header.
DV V VA VV VAV
optional systemheader
pack header
video PES-packet audio PES-packet data PES-packet
'pack'
pack header pack header
V
V A D
Fig. 5 - Structure of the MPEG-2‘Programme Stream’ multiplex.
(R023/025) - 4 -Figuur 2.8: Structuur van een MPEG-2 Systems Programmastroom
Op figuur 2.8 zien we hoe uiteindelijk de programmastroom multiplex
van MPEG-2 wordt opgebouwd. In een programmastroom worden PES-
pakketten (opgebouwd uit de elementaire stromen) georganiseerd in packs.
Een pack bevat een pack header, een optionele system header en verschillende
PES-pakketten van de deelnemende elementaire stromen, in een willekeurige
volgorde. Er is geen beperking op de lengte van een pack, uitgezonderd
dan op het feit dat een pack header iedere 0.7 seconden moet verschijnen
in de programmastroom, omdat deze header belangrijke timing informatie
bevat (specifiek: de system clock reference). De pack system header bevat
extra informatie zoals de maximum data rate, het aantal elementaire stromen
vervat in de programmastroom en geavanceerdere timing informatie. Een
decoder zal bijvoorbeeld, door de system header te lezen, kunnen bepalen als
hij de programmastroom zal kunnen decoderen of niet.
PES tot Transportstroom (TS)
Transportstromen worden gebruikt bij transmissienetwerken waar er een gro-
tere kans op fouten bestaat (internet, ATM, ...). Ze bestaan ook uit samenge-
stelde data van Packetized Elementary Streams en bijkomende beschrijvende
data. Als gevolg van de kans op fouten zal men relatief lange PES-pakketten
15
opsplitsen in kortere transportstroom pakketten (TS-pakketten ofwel Trans-
port Stream-pakketten) met een vaste lengte van 188 bytes. Elk TS-pakket
bestaat uit een TS-header, eventueel gevolgd door bijkomende data (Adapta-
tion Field) en vervolgens door een gedeelte van een PES-pakket (of een vol-
ledig PES-pakket bij heel kleine PES-pakketten).
We bestuderen transportstromen niet in deze thesis omdat we vooral wer-
ken met digitaal opgeslagen multimediastromen. Een .vob-bestand van een
DVD is immers een programmastroom, zodat een schema voor programma-
stromen nuttiger zal zijn om te gebruiken dan een schema voor transportstro-
men. Met een schema voor programmastromen kunnen we dan een volledige
DVD proberen te beschrijven.
De volledige MPEG-2 Systems specificatie kunnen we terugvinden in [4].
Voor een overzicht van MPEG-2 Systems (inclusief transportstromen) is [5]
een interessant werk.
16
Hoofdstuk 3
Inleiding tot MPEG-21 BSDL
3.1 Schaalbare videocodering
Het Internet groeit ieder jaar vliegensvlug. Denk maar aan:
• de verschillen in toestellen die toegang hebben tot het Internet;
• de verschillen in bandbreedtes van een netwerkverbinding;
• de diversiteit aan hardware- en software-configuraties;
• de opkomende mobiele toestellen (PDA, GSM) die in staat zijn om
videosequenties af te spelen.
Op dit ogenblik zie je nog steeds veel websites waar verschillende versies van
multimediale data aangeboden worden, bijvoorbeeld voor een smalband- en
een breedbandverbinding. Deze versies werden apart gecomprimeerd en op-
geslagen op een multimedia server. Dit zorgt voor een aanzienlijke overhead
als we spreken over een heel groot aanbod aan multimediale data. Hier kan
schaalbare videocodering een oplossing bieden. Men kan spreken van schaal-
bare videocodering als een encoder schaalbare of gelaagde bitstromen kan
afleveren. Dit zijn bitstromen waaruit gemakkelijk, met behulp van eenvou-
dige editeerbewerkingen, aangepaste versies kunnen afgeleid worden. Deze
17
versies zullen op een bepaald vlak een lagere kwaliteit aanbieden, en dus ook
minder eisen opleggen aan de decoder (hardware, software) en/of de capaci-
teiten van een netwerkverbinding (bandbreedte). Het achterliggend concept
van deze schaalbare bitstromen is UMA, beter bekend als Universal Multi-
media Access. Voor meer informatie over UMA verwijzen we naar [6]. Over
het algemeen worden drie vormen van schaalbaarheid (bij een bitstroom)
onderscheiden:
• spatiale schaalbaarheid: lagere kwaliteit komt neer op een vermindering
in resolutie (aantal pixels).
• temporele schaalbaarheid: lagere kwaliteit stemt overeen met een lagere
beeldsnelheid (minder beelden per seconde).
• SNR1-schaalbaarheid waar men lagere kwaliteit zal zien in de beelden
zelf (codeerfouten).
Door deze technieken moet er slechts eenmaal een hoge-kwaliteitsversie aan-
gemaakt worden om tientallen versies te kunnen aanbieden. Die aanpassin-
gen gebeuren vrij eenvoudig, zoals het weglaten van de juiste blokken data.
Doordat men inzag dat men schaalbaarheid kon aanbieden zonder te moeten
inboeten aan codeerefficientie, heeft men beslist om binnen MPEG-21 een
standaardisatieproces op te starten voor Schaalbare Videocodering (SVC).
MPEG-21 BSDL is daar een onderdeel van.
In de nabije toekomst zou het dan mogelijk moeten zijn om een multime-
dia server te onderhouden zoals we op figuur 3.1 kunnen zien. Hierbij zal een
eindgebruiker (de surfer) een mediabestand aanvragen aan de server. Deze
aanvraag, samen met de Constraints van de gebruiker, dit is bijvoorbeeld
de netwerkcapaciteit, zijn hardware configuratie zoals de processorsnelheid,
zal worden ontvangen door de Adaptation Engine. Een onderdeel van deze
engine is de Decision Engine. Deze eenheid zal op basis van de meegegeven
parameters van de gebruiker (Constraints) en de beschrijving van het me-
diabestand (die de eenheid van de multimedia server zal afgehaald hebben)
1Signal-to-Noise Ratio of Signaal-Ruis-Verhouding
18
bepalen hoe het mediabestand best wordt aangepast om een zo goed moge-
lijke versie aan de eindgebruiker te verzenden. Als de gebruiker over een lage
bandbreedte beschikt, zal er een goede beslissing genomen worden om de
bitstroom aan te passen en aan kwaliteit in te boeten. Deze beslissing wordt
verzonden naar de Adaptation Engine die de effectieve aanpassing zal door-
voeren en deze aangepaste versie zal verzenden naar de gebruiker. Daarvoor
zal deze Adaptation Engine uiteraard het multimediabestand van de server
moeten halen.
Het BSDL-raamwerk past dus in figuur 3.1 bij de Resource Adaptation
Engine.
23
Praktische Werking van Server
MultimediaDatabank
Eindgebruiker(surfer)
AdaptationDecisionEngine
Resource Adaptation
Engine
Adaptation Engine
Gebruikers-parameters
Aangepastmediabestand
XML-beschrijving
Media-bestand
AdaptationDecision
Figuur 3.1: Praktische werking
3.2 MPEG-21 DIA BSDL
Een belangrijk probleem dat moet opgelost worden wanneer men schaalbare
video wil aanbieden aan een groot aantal gebruikers, is dat er software moet
gebouwd worden die er voor zorgt dat de juiste aanpassingen gebeuren aan
de schaalbare bitstroom door de juiste datablokken weg te laten of door te
sturen, afhankelijk van de te bekomen versie.
19
De Bitstream Syntax Description Language ofwel BSDL, is onderdeel van
de Bitstream Syntax Description Tool, die onderdeel is van MPEG-21 DIA
(Digital Item Adaptation). MPEG-21, ook bekend als ISO/IEC 21000, is de
meest recentste standaard ontwikkeld (of beter gezegd nog in ontwikkeling)
door MPEG2. MPEG-21, in contrast tot de andere MPEG standaarden, is
een generiek raamwerk voor de productie en consumptie van multimediale
data. Het centrale concept binnen MPEG-21 is het Digital Item, afgekort DI.
Een DI is een gestructureerd object, uitgedrukt in XML, dat zowel inhoud als
metadata bevat. Een volledig overzicht van MPEG-21 kan je terugvinden in
[7]. De BSDL-technologie is een onderdeel geworden van deel 7: MPEG-21
DIA (Digital Item Adaptation). DIA voorziet ook nog andere hulpmidde-
len bij het automatisch aanpassen van multimediale data aan verschillende
toestellen. Figuur 3.2 toont het concept van de werking van MPEG-21 DIA.
page 338 July 2003 VCIP 2003 — T6
Concept of Digital Item Adaptation
Digital Item AdaptedDigital Item
DIA Tools
Digital ItemAdaptation Engine
ResourceAdaptation Engine
DescriptionAdaptation Engine
Scope of standardization
Figuur 3.2: Concept van MPEG-21 DIA
DIA bestaat uit verschillende tools (zie de MPEG specificatie [8]) waar-
onder de tool Bitstream Syntax Description. Deze tool bestaat dan weer uit 2
concepten, namelijk BSDL en gBSD (Generic Bitstream Syntax Description),
2Moving Picture Experts Group
20
dat een meer algemene aanpak heeft dan BSDL. Voor BSDL zal bijvoorbeeld
voor iedere videocodec een ander schema ontwikkeld moeten worden.
Binnen MPEG-21 DIA kwam men dus op het idee om een mechanisme te
ontwikkelen dat zou toelaten om automatisch beschrijvingen aan te maken
van de structuur van een bitstroom. Die beschrijvingen, in een XML-formaat,
zouden dan gebruikt kunnen worden voor editeer-bewerkingen, aangezien het
gemakkelijker is om dit soort bewerkingen te implementeren op XML-niveau
dan op bitstroomniveau. Wanneer er dan ook een mechanisme zou bestaan
om vanuit (aangepaste) bitstroombeschrijvingen terug de corresponderende
bitstromen te genereren, had men een raamwerk om bitstromen aan te passen
zonder dat men een echte parser voor die bitstromen moest ontwikkelen.
Het is hieruit dat BSDL gegroeid is. Een ander vernieuwend principe
in het BSDL-raamwerk was het idee dat men XML Schema kon gebruiken,
niet enkel om een grammatica vast te leggen voor een bepaalde categorie
van bitstroombeschrijvingen (aangezien dat XML-documenten zouden zijn),
maar ook om een grammatica vast te leggen voor de bitstromen zelf. Om dat
mogelijk te maken waren een aantal uitbreidingen en beperkingen nodig op
XML Schema omwille van de specifieke eigenschappen van bitstromen. Door
de BSDL-schema’s zodanig op te stellen dat dubbelzinnigheden vermeden
worden, is het bovendien mogelijk om deze schema’s als input te gebruiken
voor het automatisch aanmaken van bitstroombeschrijvingen. BSDL kan dus
aanzien worden als een uitbreiding en beperking op XML. Figuur 3.3 toont
dit aan.
W3C XML Schema
Bitstroombeschrijving in XML-formaat
BSDL-schema
XML-documentXML-schema
MPEG-21 BSDL
Figuur 3.3: Vergelijking tussen W3C XML Schema en BSDL Schema
21
Het principe van BSDL vinden we dan weer terug in figuur 3.4. Dit
concept is doorheen de thesis constant gebruikt geweest. We volgen de ver-
schillende stappen in het aanpassen van een bitstroom via BSDL.
5
MPEG-21 BSDL Raamwerk
BITSTROOM XML-beschrijving
Aangepaste XML-beschrijving
Aangepaste BITSTROOM
BinToBSD
Transformatie
BSDToBin
BSDL-schema
mijn_video.m2v
MPEG_2.xsd
mijn_video.xml
mijn_aangepaste_video.xmlmijn_aangepaste_video.m2v
Verwijder_B.xslt
Figuur 3.4: Overzicht van het BSDL raamwerk
We starten van een gegeven bitstroom (gecodeerd in een bepaalde co-
dec zoals MPEG-2, MPEG-4 XVID, ...) en we willen een high-level XML-
beschrijving genereren voor deze bitstroom. Daarvoor moeten we een BSDL-
schema ontwikkelen, specifiek ontworpen voor de codec van de bitstroom.
Dit te ontwerpen schema is een representatie van alle mogelijke bitstromen,
gegenereerd door de encoder van die bepaalde codec. Een BSDL schema
definieert dus de syntax van een mogelijke bitstroom net zoals een XML-
schema een syntax definieert (een toegelaten inhoud) voor een groep van
XML-documenten.
Wanneer we een BSDL-schema hebben voor een bepaalde codec, zullen we
dus een bitstroombeschrijving kunnen genereren voor iedere bitstroom die in
deze codec is gecodeerd. Dit proces wordt uitgevoerd door de BintoBSD tool
van de BSDL-software, die bovendien zelf moet geımplementeerd worden.
Het enige wat MPEG gestandaardiseerd heeft zijn de tags die kunnen voor-
22
komen in een BSDL-schema. Als uitvoer van de BintoBSD tool verkrijgen
we een XML-bestand dat de structuur van de bitstroom beschrijft.
In de volgende stap kunnen we een XML-bestand transformeren. Hoe we
deze transformatie (dus verandering van de XML file) doorvoeren is ook vol-
ledig vrij. Bijvoorbeeld, we kunnen gebruik maken van een XSLT3 transfor-
matie, die kan uitgevoerd worden door een XSLT processor zoals bijvoorbeeld
Saxon. In deze thesis gebruiken we Saxon. Deze tool is een gratis open source
XSLT en XQuery processor en kan je vinden op [9]. Men kan ook Java biblio-
theken zoals SAX (Simple API for XML) of DOM (Document Object Model)
gebruiken, zeker wanneer meer complexe transformaties moeten worden uit-
gevoerd. De enige beperking is wel dat de aangepaste XML-beschrijving nog
steeds moet geldig zijn met het originele BSDL-schema van de videocodec.
De laatste stap is de aangepaste bitstroom genereren via de BSDtoBin
tool van BSDL. Deze tool neemt als invoer de aangepaste bitstroom be-
schrijving en het BSDL-schema maar ook de originele bitstroom, omdat de
beschrijving immers referenties naar data blokken (bytes) uit de originele
bitstroom zal bevatten. Tenslotte moeten we opmerken dat de aangepaste
beschrijving NIET de bitstroom beschrijving is van de aangepaste bitstroom.
3.3 Eenvoudig Voorbeeld
We zullen alles even verduidelijken met een eenvoudig voorbeeld dat wordt
getoond op figuur 3.5.
We hebben een bitstroom, voorgesteld in hexadecimale notatie, die een
fictieve codec volgt. De syntax van deze codec is eenvoudig: de frames (beel-
den, pictures) volgen elkaar sequentieel op in de bitstroom. De lengte van
een frame is 2 bytes. Als we een schema hebben voor deze codec, zal de
beschrijving eruit zien zoals we op de figuur kunnen zien. Een frame wordt
aangeduid met een element <Frame>a b<Frame> waarbij a de startbyte aan-
duidt van de originele bitstroom, en b de lengte aanduidt. Dit is dus een
3Extensible Stylesheet Language Transformation
23
4 Davy De Schrijver et al.
gine is completely open: only the structure and the tagsthat can appear within the BSDL schema are standard-ized. As output of the engine, we get an XML file thatrepresents the structure of the original bitstream.During the next step, we can transform the XML file.The transformation is the XML-equivalent of the adap-tation of the original bitstream. How to transform theXML file is also not standardized. For example, one canuse an XSLT transformation (Extensible Stylesheet Lan-guage Transformations [13]), or a library like SAX (Sim-ple API for XML) or DOM (Document Object Model)when a more complex transformation is needed. The onlyrestriction on the transformation is that the adapted de-scription must be valid with respect to the appropriateBSDL schema. In our example, we have eliminated thesecond frame, something that can be easily done by anXSLT transformation.The last step is the re-generation of the new adaptedbitstream; for this, we need the BSDtoBin tool. Thistool takes as input the adapted bitstream descriptionand the BSDL schema but also the original bitstreambecause the description will contain references to datablocks (of bytes) in the original bitstream (for example,copy all the bytes between byte 1100 and byte 1180).Finally, note that the adapted description is not the bit-stream description of the adapted bitstream. In our ex-ample, it is clear that the adapted description (after thetransformation) is not the same XML fragment as thedescription of the adapted bitstream we get after usingthe adapted bitstream as input for the BintoBSD engine.
OriginalBitstream BintoBSD XML Bitstream
Description
Transformation
Adapted BitstreamDescriptionBSDtoBin
BSDLSchema
AdaptedBitstream
Fig. 3 Bitstream Syntax Description Language (BSDL)framework
3 BSDL in the context of MC-EZBC
In Section 2, the working of the MC-EZBC wavelet-based codec and the MPEG-21 BSDL standard was ex-plained. In this section, we will dicuss how we have de-veloped a BSDL schema for the codec in question. First,we will explain how a generated bitstream looks like af-ter the encoding phase. Then we will explain how wecan construct a BSDL schema and how we can generatea bitstream description.
Bitstream(Hexadecimal representation)
05 E7 C3 D2 02 12
Frame 1 Frame 2 Frame 3
XML-description:<Bitstream>
<Frame>0 2</Frame><Frame>2 2</Frame><Frame>4 2</Frame>
</Bitstream>
StartbyteLength
BintoBSD
Adapted description:<Bitstream>
<Frame>0 2</Frame><Frame>4 2</Frame>
</Bitstream>
Transformation: eliminate 2nd frame
BSDtoBin
Adapted Bitstream(Hexadecimal representation)
05 E7 02 12
Frame 1 Frame 3
BintoBSD
Description of AdaptedBitstream:<Bitstream>
<Frame>0 2</Frame><Frame>2 2</Frame>
</Bitstream>
Different
BSDLSchema
Fig. 4 Simple BSDL Example
3.1 Structure of a MC-EZBC bitstream
The structure of a bitstream is codec-dependent in caseof the MC-EZBC compressor. In this paper, we use theimplementation of the MC-EZBC codec that was re-leased on September 2003 [7]. The complete structure ofa generated bitstream is given in Fig. 5. The first part of
Header Payload100bytes
GOP structure 1 GOP structure 2 GOP structure n…
GOP size 1 GOP size 2 GOP size n… GOPs4 bytes 4 bytes 4 bytes
GOP structure n-1
GOP Header GOP Content
MV Base Layer Subband 1MV Enhancement Layer Subband 2 Subband p…
Temporal Substream 1 MV 2 Temp Substr 2 MV m Temp Substr m…
MV = Motion Vectors
Fig. 5 Structure of a generated bitstream
the bitstream contains a header followed by the payloadof the video. The header contains general informationabout the bitstream. Some information is necessary toplay back the video correctly like frame rate, resolution,number of frames, and so on. Other information will beused by the decoder to decode the bitstream in the cor-rect manner like t level (reduction of the temporal levels,result of temporal scalability), s level (reduction of thespatial resolution), and so on. The complete header con-tains 100 bytes.After the fixed header, we have the actual payload ofthe video sequence. The first part of the payload con-tains the sizes of the different GOPs. This is importantbecause the decoder must know how many bytes to readbefore the decoding can start. The bitstream contains nostart codes (in contrast with other video codec specifica-tions such as MPEG-4 Visual). This applies that it willbe impossible to use that kind of streams in live stream-ing (for example, live television broadcasting).
Figuur 3.5: Eenvoudig BSDL voorbeeld
referentie naar een datablok in de originele bitstroom.
Wanneer we dan het tweede frame laten vallen bekomen we een aangepas-
te XML-beschrijving zonder het tweede <Frame>-element. Na uitvoering van
BSDtoBin verkrijgen we de aangepaste bitstroom met de 2 middenste bytes
(van het tweede frame) weggelaten. Om de laatste opmerking van daarnet
aan te tonen hebben we nog eens de beschrijving van deze aangepaste bit-
stroom gegenereerd met behulp van BintoBSD. Zo zien we dat de aangepaste
beschrijving niet overeenstemt met de terug gegenereerde beschrijving van de
aangepaste bitstroom.
Het gebruikte BSDL-schema zal er uitzien zoals op figuur 3.6. We hebben
een root element in het schema genaamd Bitstream en dit bestaat uit een
sequentie van frames. We zien dat een element wordt gerefereerd aan de
24
hand van ref=.... De attributen minOccurs en maxOccurs spreken voor zich:
dit is het aantal keer dat een frame zal voorkomen in een bitstroom. Dit zal
dus tussen 0 en oneindig liggen (unbounded).
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/BSDLvoorbeeld.xsd
<?xml version="1.0" encoding="UTF-8" ?> - <xsd:schema xmlns:bt="urn:mmt:2005:dataTypes-NS" xmlns:bs1="urn:mpeg:
mpeg21:2003:01-DIA-BSDL1-NS" xmlns:bs2="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" xmlns:bsdl="BSDLvoorbeeld" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="BSDLvoorbeeld" elementFormDefault="qualified" bs2:rootElement="BSDLvoorbeeld:Bitstream"> <!-- ********** Root element declaration ********** --> - <xsd:element name="Bitstream">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="bsdl:FRAME" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ********** FRAME declaration ********** --> - <xsd:element name="FRAME">
- <xsd:simpleType>
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:length value="2" /> </xsd:appinfo>
</xsd:annotation> </xsd:restriction>
</xsd:simpleType> </xsd:element>
</xsd:schema>
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/BSDLvoorbeeld.xsd9/05/2005 14:50:00
Figuur 3.6: Eenvoudig BSDL-schema
Het element Frame wordt dan eenvoudig opgesteld. We definieren eerst
een restrictie die aangeeft dat Frame een byterange type betreft (dit type
werd speciaal aangemaakt voor BSDL, het zit namelijk in de namespace
bs1, de BSDL-1 uitbreidingen op XML: hierover later meer). Dan geeft men
tenslotte nog aan hoe lang het Frame is aan de hand van bs2:length. Dit is
dan weer een uitbreiding van BSDL-2 met namespace bs2. Hier komen we
dus later op terug. De lengte wordt dus gezet op 2 bytes.
25
3.4 BSDL Specificatie
We gaan hier wat meer in detail over hoe BSDL echt werkt, wat de uitbrei-
dingen en ook beperkingen zijn op XML en hoe men ervoor heeft gezorgd
dat we zulke beschrijvingen relatief gemakkelijk kunnen opstellen.
3.4.1 Inleiding
De BSDL-specificatie bouwt voort op de specificatie van W3C XML Schema.
We zullen trachten een volledig overzicht te geven van deze specificatie, die
is opgesplitst in een tweetal delen, die elk een XML-schema hebben. Het
Schema for BSDL-1 Extensions definieert een aantal ingebouwde datatypes
en attributen die kunnen gebruikt worden in een BSDL-schema en die ge-
bruikt worden bij het genereren van bitstromen uit bitstroombeschrijvingen
(BSDtoBin). Om van een bitstroom een beschrijving te verkrijgen kan het
zijn dat er nog bijkomende constructies nodig zijn om dubbelzinnigheden te
vermijden. Deze uitbreidingen (voor BintoBSD dus) zijn terug te vinden
in het Schema for BSDL-2 Extensions. Beide schema’s hebben een eigen
naamruimte (namespace). Verder zijn er nog een aantal beperkingen op
XML Schema vastgelegd, onder andere over welke datatypes er wel en niet
toegelaten zijn in een BSDL-schema.
3.4.2 Beperkingen
Data die in een bitstroom voorkomt, mag enkel voorkomen binnen een XML-
element, nooit in een attribuut. De reden daarvoor is dat de volgorde van
attributen van geen belang is, terwijl dat wel belangrijk is tijdens het ge-
nereren van bitstromen. Zogenaamde mixed content (wanneer tussen XML-
elementen er ook tekst kan voorkomen) is ook niet toegelaten in BSDL. Als
algemene regel geldt dat elk element een datatype moet hebben. Dat bete-
kent ook dat datatypes zoals xsd:any uit den boze zijn.
De datatypes die toegelaten zijn in BSDL, zijn uiteraard enkel die waar-
voor er een binaire representatie bestaat. Dit betekent bijvoorbeeld dat een
26
xsd:integer niet toegelaten is, aangezien het aantal bytes hierbij niet vastligt.
Anderzijds is een xsd:int wel mogelijk. Toch zijn er bepaalde datatypes toe-
gelaten waarvan de lengte niet vastligt. Om in zo een geval een beschrijving
te kunnen genereren uit een bitstroom zal er bijkomende informatie nodig
zijn; dit wordt vastgelegd in BSDL-2. In tabel 3.1 wordt een overzicht ge-
geven van alle datatypes gedefinieerd in de XML Schema specificatie, en die
ook in BSDL toegelaten zijn.
datatype lengte(bytes)xsd:string onbeperktxsd:float 4xsd:double 8xsd:hexBinary onbeperktxsd:base64Binary onbeperktxsd:long 8xsd:int 4xsd:short 2xsd:byte 1xsd:unsignedLong 8xsd:unsignedInt 4xsd:unsignedShort 2xsd:unsignedByte 1
Tabel 3.1: Toegelaten XML datatypes in BSDL Schema
Bovendien kunnen eigen types aangemaakt worden door een van de unsig-
ned datatypes te beperken aan de hand van de xsd:maxExclusive-constructie.
Het aantal bits dat gebruikt wordt voor de representatie in de bitstroom is
het aantal bits dat nodig is om de grootst mogelijke waarde binnen het bereik
vast te leggen. Bijvoorbeeld een datatype van 4 bits declareren is een unsig-
nedByte nemen en xsd:maxExclusive waarde 16 geven. Immers 16 wordt net
met 5 bits weergegeven; alles onder 16 wordt voorgesteld met 4 bits. Deze
technieken zullen we volop gebruiken in het ontwerpen van een schema voor
MPEG-2 Video en Systems in de volgende hoofdstukken.
27
3.4.3 BSDL-1 Uitbreidingen voor de BSDToBin tool
Naast de datatypes uit W3C XML Schema, definieert BSDL-1 ook twee eigen
datatypes: byteRange en bitstreamSegment; beide zijn onbeperkt in lengte.
Verder wordt er ook een attribuut ignore toegevoegd.
Het ignore-attribuut kan handig zijn wanneer je in een bitstroombeschrij-
ving bijkomende metadata wil toevoegen, waarvan je wil duidelijk maken dat
ze niet in de bitstroom zelf voorkomen. Door aan de definitie van een element
in het BSDL-schema het ignore-attribuut toe te voegen, zal dat element (en
al zijn afstammelingen) genegeerd worden door de BSDL-parsers wanneer
het de waarde true heeft in de bitstroombeschrijving.
Elementen van het byteRange-datatype bestaan uit twee niet-negatieve
gehele getallen en verwijzen naar een fragment uit de originele bitstroom.
Daarnaar wordt verwezen aan de hand van het xml:base attribuut (meestal
weergegeven in het root-element van de bitstroom-beschrijving). Het eerste
getal verwijst naar de positie in de bitstroom (de eerste byte heeft waarde
0), het tweede getal slaat op de lengte (aantal bytes) van het fragment.
In het eenvoudige voorbeeld op Figuur 3.6 werd gebruikt gemaakt van het
byteRange-type.
3.4.4 BSDL-2 Uitbreidingen voor de BinToBSD tool
Een belangrijke uitbreiding ten opzichte van BSDL-1 is het gebruik van
XPath-expressies: soms is het voor het genereren van bitstroombeschrijvin-
gen nodig om te kunnen definieren dat de lengte van een bepaald element,
of het aantal keer dat een element voorkomt, afhangt van de waarde van
een ander element. Ook bij het voorwaardelijk voorkomen van een bepaald
element kunnen XPath-expressies gebruikt worden.
Om het aantal keer dat een bepaald element voorkomt in een bitstroom-
beschrijving vast te leggen, kan het nOccurs-attribuut gebruikt worden, dat
een XPath-expressie kan bevatten. Merk op dat, om bitstroombeschrijvingen
te genereren die door gewone XML Schema-tools correct kunnen gevalideerd
28
worden, de waarde van dit attribuut moet liggen tussen de waarde van het
minOccurs- en maxOccurs-attribuut van het Schema.
Elementen kunnen ook conditioneel zijn; daarvoor bestaat het if-attribuut
dat een XPath-expressie bevat, of het ifNext-attribuut, dat een hexadecimale
voorstelling bevat van een waarde (1 hexadecimaal getal) of een bereik (2
getallen, gescheiden door een “-”): enkel wanneer de volgende bits in de
bitstroom hiermee overeenkomen, zal het element in de bitstroombeschrijving
opgenomen worden.
Ook hier moeten we erop letten dat de waarden van minOccurs en maxOc-
curs correct zijn, als we willen dat de beschrijving correct kan gevalideerd
worden: minOccurs moet op 0 staan, maxOccurs op 1.
Nog een attribuut dat in BSDL-2 wordt vastgelegd, is het rootElement-
attribuut dat voorkomt in het xsd:schema-element en aan de BintoBSD-
parser zegt welk element in de definitie van het Schema als beginelement
moet gekozen worden. Wanneer er geen beperkingen worden gedefinieerd op
datatypes van onbeperkte lengte, zal de bitstroom tot op het einde doorlo-
pen en volledig opgenomen worden in het corresponderende element. Om
zulke beperkingen vast te kunnen leggen, volstaan in sommige gevallen de
constructies niet die XML Schema aanbiedt. Daarom wordt er in BSDL
soms gebruikgemaakt van de xsd:annotation/xsd:appinfo-combinatie binnen
een xsd:restriction-component. Een voorbeeld kan je zien op Figuur 3.6: het
Frame-element wordt daar beperkt in lengte door de waarde 2 (bytes).
Het length-datatype kan gebruikt worden om het aantal bytes vast te
leggen van een element van onbeperkte lengte. Ook hier kan een XPath-
expressie gebruikt worden. Dit type mag niet gebruikt worden samen met
een xsd:length-, startCode- of endCode-constructie.
De startCode- en endCode-datatypes worden gebruikt wanneer de gren-
zen van een segment in de bitstroom vastgelegd worden aan de hand van
vooraf gedefinieerde sequenties van bits. Wanneer het einde van het huidige
element op die manier aangegeven wordt, maakt men gebruik van endCode;
wanneer het begin van het volgende element op die manier wordt aangegeven,
maakt men gebruik van startCode. Net zoals bij de if- en ifNext-constructie
29
kan een bereik opgegeven worden in plaats van 1 waarde. Het is toegela-
ten om meerdere start- en eindcodes op te geven voor hetzelfde element.
Van zodra de eerste code gevonden wordt, zal het element dan afgesloten
worden. Wel mag deze constructie niet gebruikt worden in combinatie met
length-beperkingen (uit BSDL of XML Schema).
30
Hoofdstuk 4
BSDL-schema voor MPEG-2
Video
In dit hoofdstuk zullen we de specificatie van BSDL (hoofdstuk 3) toepassen
op de MPEG-2 Video Syntax die we besproken hebben in hoofdstuk 2. Op die
manier bekomen we een BSDL-schema dat zal gebruikt worden om MPEG-
2-videostromen te beschrijven in een XML-bestand.
4.1 Inleiding: startcodes
Startcodes zijn van groot belang in elke videostroom (hexadecimaal be-
schouwd). Startcodes zijn specifieke bitpatronen die niet elders voorkomen
in de videostroom. Elke startcode bestaat uit een start code prefix, gevolgd
door een start code value. De start code prefix bestaat uit 23 0-bits en 1
1-bit. Dit is dus de bitstring “0000 0000 0000 0000 0000 0001”.
De start code value is een 8-bits getal dat het type van de start code
identificeert. Een overzicht van de startcodes voor MPEG-2 Video vinden
we terug in tabel 4.1. Merk op dat de “System Start Codes” gebruikt wor-
den door MPEG-2 Systems. Daar zullen we het later natuurlijk meer over
hebben.
31
naam Start Code Valuepicture start code 00slice start code 01 tot AFreserved B0reserved B1user data start code B2sequence header code B3sequence error code B4extension start code B5reserved B6sequence end code B7group start code B8system start codes B9 tot FF
Tabel 4.1: MPEG-2 Video Startcodes
Indien we in de bitstroom een startcode willen terugvinden dat het begin
aanduidt van een GOP (Group of Pictures) dan zullen we moeten zoeken
naar (hexadecimaal) 0x00001B8, omdat B8 de start code value is van de
group start code. In het schema dat we ontwerpen zullen de sequence header
code, de picture start code en de group start code een belangrijke rol spelen.
4.2 Enkele belangrijke datatypes
4.2.1 Elementaire Datatypes
We zullen heel wat aparte datatypes definieren. Enkele eenvoudige types vind
je op Figuur 4.1. Deze datatypes, genaamd b1 tot b16 (op de figuur zien we
enkel een paar voorbeelden, aangezien de andere heel analoog zijn), beperkt
men tot respectievelijk 1 tot 16 bits. Met andere woorden, het datatype b1 is
een beperking op de lengte, namelijk 1 bit. Datatype b2 heeft een beperking
van 2 bits lengte, enzoverder...
Deze types zijn gedefinieerd in een apart bestand BasicDatatypes.xsd, dat
je kan raadplegen in Bijlage B.
32
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/BasicDatatypes.xsd
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="b8">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="256" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b7">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="128" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b6">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="64" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b5">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="32" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b4">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="16" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b3">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="8" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b2">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="4" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b1">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="2" /> </xsd:restriction>
</xsd:simpleType> </xsd:schema>
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/BasicDatatypes.xsd (2 of 2)14/05/2005 14:40:15
Figuur 4.1: Enkele eenvoudige datatypes
4.2.2 Picture Payload Type
Een heel belangrijk type is PicturePayloadType die we gedefinieerd zien op
Figuur 4.2. Dit type zullen we gebruiken om de extra data van een beeld te
refereren in ons schema. We hebben immers verdere gedetailleerde “parsing”
van de slices niet nodig in deze thesis. Indien men later ook wil slices, macro-
blokken en blokken beschrijven, kan men het schema nog altijd uitbreiden.
Deze PicturePayloadType zorgt ervoor dat we alle data overslaan tot we een
van de vier afgebeelde startcodes terugvinden in de bitstroom. We laten dus
alles over tot ofwel het volgende beeld (Picture Start Code 0x00000100), of-
wel tot de volgende GOP (Group of Pictures Start Code 0x000001B8), tot
de volgende video sequence (Sequence Header Start Code 0x000001B3) en
tenslotte eventueel tot het einde van de huidige video sequence (Sequence
End Code 0x000001B7).
Dit type is gedefinieerd in een apart bestand MPEG2SimpleTypes.xsd,
dat je kan raadplegen in Bijlage C.
33
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/mpeg-2_simple_types.xsd
</xsd:annotation> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="BeginVideoPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:startCode value="000001B3" /> <!-- packet start codes --> <bs2:startCode value="000001BC-000001FF" />
<!-- pack_start_code --> <bs2:startCode value="000001BA" />
<!-- program_end_code --> <bs2:startCode value="000001B9" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="SystemPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:startCode value="000001BB" /> </xsd:appinfo>
</xsd:annotation> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="PicturePayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<!-- Nieuw Beeld: Picture Start Code --> <bs2:startCode value="00000100" />
<!-- In geval van een "laatste" beeld. --> <!-- Group Start Code --> <bs2:startCode value="000001B8" />
<!-- Sequence Header Start Code --> <bs2:startCode value="000001B3" />
<!-- Sequence End Code --> <bs2:startCode value="000001B7" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="GOPPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:startCode value="000001B8" /> </xsd:appinfo>
</xsd:annotation> </xsd:restriction>
</xsd:simpleType>
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/mpeg-2_simple_types.xsd (2 of 3)16/05/2005 16:30:42
Figuur 4.2: Datatype Picture Payload Type
4.3 MPEG-2 Video BSDL-schema
4.3.1 Root Element: MPEG2Video
Figuur 4.3: Root element van het BSDL-schema
Na het bepalen van de naamruimtes (namespaces), het root element en de
imports van de verschillende andere benodigde schema’s, zullen we het BSDL-
schema voor MPEG-2 Video ontwerpen. Op figuur 4.3 zien we een deel van
34
het schema, namelijk voor het root element MPEG2Video waar de bitstroom
dus in feite “begint”. Het element bit stuffing is enkel om de bitstroom
te aligneren zodat we terug het begin van een byte hebben. We zien dat
MPEG2Video bestaat uit verschillende video sequences. De sequence start
code 0x000001B3 hebben we nodig in het ifNext-attribuut om de sequentie te
starten. Deze constructie zullen we heel veel gebruiken. Het MPEG-2 Video
BSDL-schema in XML-vorm kan je raadplegen in Bijlage D. Daar zal men het
gebruik van onder andere ifNext duidelijk kunnen zien. Een video sequence
bestaat dus uit een sequence header, eventueel een sequence extension, de
extension data en uiteindelijk een reeks van GOP’s. We herkennen hier
direct hoe we in BSDL de syntax van MPEG-2 Video, die we bestudeerden
in hoofdstuk 2, modelleren. Na de verschillende video sequences, komen we
op het einde van de videostroom met de sequence end code.
De verschillende elementen van de video sequence (die we gerefereerd
hebben met behulp van ref=“...”) gaan we vervolgens kort bespreken.
4.3.2 Sequence Header
Op Figuur 4.4 zien we de uitwerking van de Sequence Header. Belangrijke
informatie in deze header is bijvoorbeeld de resolutie, aangeduid door twee
elementen horizontal size value en vertical size value. Een element uit deze
sequence header dat we gaan veranderen is aspect ratio information, dat de
aspect ratio (zie hoofdstuk 2) aanduidt. De sequence extension (het volgende
element op Figuur 4.3) zullen we hier niet in detail bespreken. Het volstaat
om te vermelden dat de sequence extension gelijkaardig opgebouwd is zoals
de sequence header. Deze sequence extension bevat extra informatie omtrent
de resolutie, het chroma formaat, ...
35
Figuur 4.4: Sequence Header
36
4.3.3 GOP
Figuur 4.5: Declaratie van het GOP-element
Op Figuur 4.5 zien we de opbouw van een GOP. Het belangrijkste onder-
deel ervan vinden we onderaan terug, namelijk een reeks van pictures. Hierbij
wordt natuurlijk de Picture Start Code gebruikt in het ifNext-attribuut van
het element Picture.
4.3.4 Picture
Op Figuur 4.6 vinden we uiteindelijk de syntax terug van een beeld. Het
element Picture Coding Type, dat we al besproken hebben, is hier uiteraard
heel belangrijk. Dit element zullen we later gebruiken om bepaalde beelden
weg te laten. Dit element wordt ook zelf gebruikt in het schema zoals we
kunnen zien bij de elementen forward motion info en backward motion info.
Als het een I-beeld betreft zal er geen element forward motion info of back-
ward motion info volgen. Is het beeld echter een P-beeld of B-beeld (picture
coding type = 2 of 3), dan volgt er in de videostroom een element forward
motion info die informatie bevat over de bewegingsvectoren t.o.v. een vorig
37
Figuur 4.6: Declaratie van het Picture-element
beeld. Bij een B-beeld (picture coding type = 3) vinden we ook nog eens
een element backward motion info met informatie over de bewegingsvectoren
t.o.v. een volgend beeld.
38
Er volgen nog verschillende elementen zoals extra info en de picture coding
extension, die zoals gewoonlijk extra informatie bevat over het beeld. We
eindigen een beeld met een PicturePayloadType. We bedoelen daarmee dat
we niet verder in detail de bitstroom gaan ontleden, maar alles overlaten tot
we een nieuw Picture Start Code (of andere: zie vroeger...) tegenkomen in de
bitstroom. Zo laten we heel wat details over die we in principe wel later nog
kunnen modelleren (uitbreiden van het BSDL-schema). Voor deze thesis was
het echter niet nodig om verder in detail te gaan, omdat het belangrijkste
element, de picture coding type, reeds werd gevonden.
Het volledige BSDL-schema voor MPEG-2 Video vinden we terug in Bij-
lage D.
39
Hoofdstuk 5
Aanpassen van MPEG-2 Video
Met behulp van het schema dat we gedeeltelijk uitgelegd hebben in het vorige
hoofdstuk is het mogelijk om XML-beschrijvingen te genereren van videostro-
men gecodeerd met een MPEG-2 Video codec. Dit XML-bestand werd dan
aangepast via een XSLT transformatie, gebruik makend van de Saxon XSLT
Processor. We zullen in dit hoofdstuk zien hoe we gemakkelijk de aspect ra-
tio veranderen van een videostroom en beelden kunnen weglaten (temporele
schaalbaarheid).
5.1 Veranderen van de Aspect Ratio
Zoals eerder vermeld is de Aspect Ratio een soms kritiek probleem bij het zien
van een videostroom op een computer. Als mensen spreken van “uitgerokken”
beelden, wil dit zeggen dat de aspect ratio niet goed ingesteld staat. Dan is
de breedbeeld sequentie immers omgezet naar “gewoon” beeld en dus ervaart
men alles als “uitgerokken”. Ook het omgekeerde kan voorkomen, namelijk
dat mensen er “platter” of “dikker” gaan uitzien en dit komt voor als een
sequentie voor normaal beeld (4:3) wordt afgespeeld als een sequentie voor
breedbeeld (16:9).
Op figuur 5.1 zien we dat een breedbeeld versie links niet de juiste As-
pect Ratio heeft. Het gecorrigeerde beeld zien we dan rechts. De linkse
40
videostroom heeft een aspect ratio information van 3 (16:9) en de rechtse
een waarde 2 (4:3). In het XML schema zullen we dit ook perfect terug-
vinden. Als we de BSDL beschrijvingen zouden vergelijken zouden we een
andere waarde zien voor het element Aspect Ratio Information in de Sequence
Header.
Figuur 5.1: Verschil in Aspect Ratio
Via BSDL en een XSLT processor kunnen we een mechanisme ontwikkelen
dat dit automatisch corrigeert. We kunnen van de originele bitstroom via
BinToBSD een beschrijving genereren. Deze beschrijving passen we aan met
behulp van een XSLT stylesheet om het element Aspect Ratio Information in
de Sequence Header aan te passen. De resulterende XML-beschrijving gaan
we terug omzetten naar een bitstroom via BSDtoBin. Het resultaat is een
nieuwe bitstroom met een gecorrigeerde Aspect Ratio.
Op Figuur 5.2 vinden we het belangrijkste deel terug van de XSLT sty-
lesheet die de aspect ratio verandert. Als we een sequence header aantreffen,
testen we welke waarde deze aspect ratio heeft. Indien deze waarde 2 is,
veranderen we de waarde in 3, en omgekeerd. Zo construeert men een me-
chanisme om een 4:3 sequentie om te zetten naar 16:9, maar eveneens ook
om een 16:9 sequentie om te zetten naar 4:3. Gelijk welke Aspect Ratio de
videosequentie heeft (4:3 of 16:9), er wordt een verandering doorgevoerd.
We moeten opmerken dat we, om deze verandering door te voeren, niet
41
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/aspect_ratio_change.xsl
<?xml version="1.0" ?> - <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="MPEG2"
xmlns:mp2="MPEG2" version="1.0"> <xsl:output method="xml" indent="yes" />
<!-- Match all: default template --> - <xsl:template name="tplAll" match="@*|node()">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Match root element --> - <xsl:template match="mp2:Bitstream">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Do nothing for processing instructions --> <xsl:template match="processing-instruction()" />
<!-- Match B_VOP - Overrides tplAll --> - <xsl:template name="tplB_sequence_header" match="mp2:sequence_header/mp2:
aspect_ratio_information">- <xsl:if test="../mp2:aspect_ratio_information = 2">
<aspect_ratio_information>3</aspect_ratio_information> </xsl:if>
- <xsl:if test="../mp2:aspect_ratio_information = 3">
<aspect_ratio_information>2</aspect_ratio_information> </xsl:if>
</xsl:template> </xsl:stylesheet>
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/aspect_ratio_change.xsl14/05/2005 16:35:54
Figuur 5.2: Verandering van Aspect Ratio: Stylesheet
de bitstroom hoeven te doorlopen tot op het Picture niveau. Als we enkel
de Sequence Header’s detecteren (aan de hand van de sequence header start
code natuurlijk), kan het BSDL-schema, enkel om de Aspect Ratio te ver-
anderen, enorm vereenvoudigd worden en dus voor een aanzienlijk minder
lange uitvoeringstijd zorgen van de verschillende operaties (BintoBSD, xslt,
BSDtoBin). We hebben de beschrijving van de GOP’s, Pictures, ... immers
niet nodig om enkel de aspect ratio information te wijzigen.
5.2 Weglaten van Beelden
We hebben het BSDL-schema zo ontworpen zodat we elk beeld afzonderlijk
konden herkennen. Vooral het element Picture Coding Type in de Picture
Header was heel belangrijk om temporele schaalbaarheid te realiseren bij
MPEG-2 Video. We hebben er voor gekozen om B-beelden weg te laten in
een videostroom. Dit type beelden kunnen immers makkelijk worden wegge-
laten zonder enige vorm van neveneffecten (artefacten, onduidelijkheden in
de beelden), want B-beelden worden verder niet gebruikt door andere beel-
den in de decodering. P -en I-beelden worden wel gebruikt door andere B(of
P)-beelden door de referenties met bewegingsvectoren. Het weglaten van
zowel B -en P-beelden zorgt ervoor dat we een videostroom verkrijgen met
enkel intragecodeerde beelden. Deze “feature” die we terugvinden in zowat
alle spelers die MPEG-2 Video kan afspelen, noemt men fast forwarding. Het
maakt onder andere gebruik van het feit dat het eerste beeld in een GOP
42
een I-beeld moet zijn.
Op Figuur 5.3 vinden we het belangrijkste deel terug van de XSLT styles-
heet die alle xml-elementen zal kopieren, behalve de picture-elementen waar-
van het element Picture Coding Type de waarde 3 heeft. Zo zien we dat de
default template alles zal behouden, net zoals het root element (bitstream),
terwijl als men een picture element vindt in de originele XML beschrijving,
men enkel het element zal kopieren indien de coding type niet 3 is.
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/removeB.xsl
<?xml version="1.0" ?> - <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:
m="MPEG2" version="1.0"> <xsl:output method="xml" indent="yes" />
<!-- Match all: default template --> - <xsl:template name="tplAll" match="@*|node()">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Match root element --> - <xsl:template match="m:Bitstream">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Do nothing for processing instructions --> <xsl:template match="processing-instruction()" />
<!-- Match B_VOP - Overrides tplAll --> - <xsl:template name="tplB_Picture" match="m:Picture[m:picture_coding_type=3]">
<!-- Nothing ! --> </xsl:template>
</xsl:stylesheet>
file:///C|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/removeB.xsl15/05/2005 0:25:59
Figuur 5.3: Verwijderen van B-beelden: Stylesheet
Na de transformatie met behulp van de stylesheet en na de uitvoering
van BSDToBin op de aangepaste XML beschrijving, verkrijgt men een vi-
deostroom waarvan de B-beelden werden weggelaten. Men ervaart de vi-
deosequentie dan als “minder vloeiend”. De testsequentie die ik hiervoor
gebruikte had 300 beelden: 21 GOP’s en dus 21 I-beelden, 80 P-beelden en
199 B-beelden. In totaal werden dus van de 300 beelden, 199 weggelaten. De
videosequentie was eigenlijk nog “deftig” bruikbaar en niet zo heel vlug te
onderscheiden van de originele sequentie, terwijl toch 2/3 van de beelden wer-
den weggelaten. Doordat B-beelden erg gecomprimeerd worden opgeslagen,
is de grootte van het videobestand niet 2/3 maar de helft kleiner geworden.
43
5.3 MPEG-2 Video Statistieken
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/mpeg-2_video_stats.xsl
<?xml version="1.0" ?> <!-- Be careful with namespaces! --> - <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:
mp2="MPEG2" version="1.0"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" /> - <xsl:template match="/mp2:MPEG2Video">
- <html>
- <head>
<title>MPEG-2 Video - Statistics</title> </head>
- <body>
<h1>MPEG-2 Video - Statistics</h1> Number of sequence headers (video sequences):
<xsl:value-of select="count(./mp2:video_sequence/mp2:sequence_header)" /> <br />
Number of GroupOfPictures <xsl:value-of select="count(./mp2:video_sequence/mp2:GroupOfPictures)" /> <br />
Number of Pictures: <xsl:value-of select="count(./mp2:video_sequence/mp2:GroupOfPictures/mp2:Picture)" /> <br /> <br />
Number of I Pictures: <xsl:value-of select="count(./mp2:video_sequence/mp2:GroupOfPictures/mp2:Picture[mp2:picture_coding_type=1])" /> <br />
Number of P Pictures: <xsl:value-of select="count(./mp2:video_sequence/mp2:GroupOfPictures/mp2:Picture[mp2:picture_coding_type=2])" /> <br />
Number of B Pictures: <xsl:value-of select="count(./mp2:video_sequence/mp2:GroupOfPictures/mp2:Picture[mp2:picture_coding_type=3])" /> <br />
</body> </html>
</xsl:template> </xsl:stylesheet>
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/MPEG-2/mpeg-2_video_stats.xsl18/05/2005 22:55:42
Figuur 5.4: MPEG-2 Video Statistieken: Stylesheet
Van een gegeven videosequentie kan men gemakkelijk statistieken verza-
melen door bijvoorbeeld het aantal elementen te tellen in de XML-beschrijving.
Op Figuur 5.4 zien we een klein extract van hoe een “count” operatie gebeurt
om het aantal beelden en vervolgens het aantal I-beelden te bepalen. Na uit-
voering van deze stylesheet (die een HTML-pagina als output heeft) bekomen
we een aantal statistieken van een testsequentie die ik veel gebruikte in deze
thesis. De statistieken gegenereerd met behulp van deze stylesheet vinden
we hieronder terug:
MPEG-2 Video - Statistieken
Number of sequence headers (video sequences): 1
Number of GroupOfPictures 21
Number of Pictures: 300
Number of I Pictures: 21
Number of P Pictures: 80
Number of B Pictures: 199
In het volgende hoofdstuk bekijken we hoe we een BSDL-schema ontwer-
pen voor MPEG-2 Systems programmastromen. We komen nog terug op
MPEG-2 Video in prestatiemetingen.
44
Hoofdstuk 6
BSDL-schema voor MPEG-2
Systems Programmastromen
In dit hoofdstuk zullen we de specificatie van BSDL (hoofdstuk 3) toepassen
op de MPEG-2 Systems Syntax, meer bepaald programmastromen, die we
besproken hebben in hoofdstuk 2. Op die manier bekomen we een BSDL-
schema dat zal gebruikt worden om MPEG-2-Systems programmastromen te
beschrijven in een XML-bestand.
6.1 Startcodes
In het vorige hoofdstuk zagen we hoe startcodes opgebouwd werden uit een
prefix en een start code value. We hebben de startcodes meer in detail
besproken voor MPEG-2 Video in tabel 4.1. In Tabel 6.1 vinden we de
waarden van de start code value voor startcodes, gebruikt in de MPEG-2
Systems programmastroom multiplex.
Indien we in de bitstroom een startcode willen terugvinden dat het begin
aanduidt van een Pack (reeks van pakketten) dan zullen we moeten zoeken
naar (hexadecimaal) 0x00001BA, omdat BA de start code value is van de
pack start code.
45
naam Start Code Valuepack start code BAsystem header start code BBprogram end code B9
Tabel 6.1: MPEG-2 Systems Startcodes
Belangrijk zijn de soorten PES-pakketten die we terugvinden in een pro-
grammastroom. Het soort pakket (video, audio, ...) wordt herkend via de
waarde van de start code value. De startcodes voor de belangrijkste PES
pakketten vinden we in Tabel 6.2.
PES Types Start Code ValuePSMapTable Packet BCPrivate1 Packet BDPadding Packet BEPrivate2 Packet BFAudio Packets C0 tot DFVideo Packets E0 tot EFReserved Packets F0-FEPSDirectory Packet FF
Tabel 6.2: MPEG-2 Systems PES Startcodes
MPEG-2 Systems definieert 16 startcodes voor Video pakketten en 32
voor Audio pakketten. Deze pakketten worden het belangrijkste onderdeel
in het ontwerpen van een demultiplexer in audio en video.
6.2 Datatype PacketPayloadType
Zoals in het vorige hoofdstuk zijn de datatypes b1 tot b16 belangrijk. Zie
hiervoor Figuur 4.1. Voor MPEG-2 Video was het zelf gemaakte datatype
PicturePayloadType van groot belang om de data van een beeld over te laten
en naar het volgende beeld te kunnen overschakelen. Bij MPEG-2 Systems
hebben we analoog nood aan zo’n datatype, genaamd PacketPayloadType.
De declaratie van dit type vinden we terug op Figuur 6.1.
46
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/mpeg-2_simple_types.xsd
<?xml version="1.0" encoding="UTF-8" ?> - <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bt="urn:mpeg:
mpeg21:2003:01-DIA-BasicDatatypes-NS" xmlns:bs0="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" xmlns:bs1="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" xmlns:bs2="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS">
- <xsd:annotation>
<xsd:documentation>Simple Types for the MPEG-2 syntax.</xsd:documentation> </xsd:annotation>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" schemaLocation="BasicDatatypes.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" schemaLocation="BSDL-0.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" schemaLocation="BSDL-1.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" schemaLocation="BSDL-2.xsd" />
<!-- *********************************************************************** --> <!-- --> <!-- Simple Types declaration --> <!-- --> <!-- *********************************************************************** -->
- <xsd:simpleType name="StartCodeType">
- <xsd:restriction base="xsd:hexBinary">
<xsd:length value="4" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="Stuffing">
<xsd:restriction base="bs0:fillByte" /> </xsd:simpleType>
- <xsd:simpleType name="PackPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<!-- packet start codes --> <bs2:startCode value="000001BC-000001FF" />
<!-- pack_start_code --> <bs2:startCode value="000001BA" />
<!-- program_end_code --> <bs2:startCode value="000001B9" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="VideoPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:startCode value="000001B7" /> </xsd:appinfo>
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/SCHEMAS/mpeg-2_simple_types.xsd (1 of 3)16/05/2005 16:30:42
Figuur 6.1: Datatype Packet Payload Type
Hier kunnen we zien hoe de extra data in een pakket zal worden “over-
geslaan” in de beschrijving en men in de bitstroom zal verder zoeken naar
de volgende start code van een pakket (0x000001BC-0x000001FF), van een
nieuw Pack (0x000001BA), of tenslotte eventueel het einde van de program-
mastroom, de program end code (0x000001B9).
6.3 MPEG-2 Systems BSDL-schema
6.3.1 Root Element: MPEG2Systems
Na het bepalen van de namespaces, het root element en de imports van
de verschillende andere benodigde schema’s, zullen we het BSDL-schema
voor MPEG-2 Systems ontwerpen. Op figuur 6.2 zien we het root element
MPEG2Systems waar de programmastroom dus in feite “begint”. We her-
kennen hier direct hoe we in BSDL de syntax van MPEG-2 Systems pro-
grammastromen, die we bestudeerden in hoofdstuk 2, modelleren. De pro-
grammastroom is een serie van “Packs” na elkaar, gevolgd door de Systems
End Code. Deze packs worden herkend door het bs2:ifNext-element met als
47
Figuur 6.2: Root element van het BSDL-schema voor MPEG-2 Systems
waarde de startcode van een Pack (0x000001BA).
6.3.2 Packs
Een MPEG-2 Systems Pack kunnen we verder ontleden in pakketten. Ie-
dere pack bestaat uit een packheader (waarin een optionele system header)
en uit een reeks pakketten. Deze pakketten kunnen video, audio, data, ...
zijn. Op Figuur 6.3 zien we een deel van het element Pack gedeclareerd. We
zien duidelijk de PackHeader en de verschillende soorten pakketten die mo-
gelijk zijn. Zoals we eerder al zagen, zijn er verschillende soorten startcodes
voor een PES-pakket, afhankelijk van het type (voor video, audio, data, ...).
Belangrijk zijn de 16 verschillende startcodes voor video en 32 startcodes
voor audio. Voor de audio van een DVD maken de verschillende producers
van films en DVD’s echter het gebruik van Private Pakketten, waarvoor er 2
startcodes gedefinieerd zijn. Voorbeelden van gebruik zijn Dolby Surround
waarbij men een 5.1 Surround System aanbiedt aan de gebruiker. Door deze
vrijheden werd MPEG-2 ook commercieel meest gebruikt. MPEG-2 Video
in combinatie met AC3 (Dolby Digital) in een programmastroom is de meest
gebruikte “versie” van een DVD. Als een DVD op je harde schijf zich be-
vindt, zal een .VOB bestand een programmastroom zijn. Daarom dat we
ook een programmastroom willen beschrijven in BSDL; een transportstroom
is commercieel veel minder interessant.
48
Figuur 6.3: Het Pack-element (gedeeltelijk)
6.3.3 PackHeader en SystemHeader
De PackHeader (het element in een Pack voor de reeks pakketten) bevat
allerlei flags en informatie vooral nodig voor synchronisatie tussen de ver-
schillende Packetised Elementary Streams. Als laatste element kan er een
SystemHeader in de bitstroom voorkomen (na de PackHeader, of als laatste
element van de PackHeader: dit is in feite hetzelfde). Deze optionele header
bevat nog extra informatie en verschillende flags voor synchronisatiedoelein-
den.
49
Figuur 6.4: Video Pakket element
50
6.3.4 PES-pakketten
Op Figuur 6.4 zien we hoe een videopakket eruit ziet in ons BSDL-schema.
Voor alle andere pakketten is dit volledig analoog. Een PES-pakket bestaat
uit een pakket header en de eigenlijke payload (data) van de elementaire
stroom. Zoals we eerder zagen in hoofdstuk 2 wordt een elementaire stroom
opgedeeld in pakketten waarbij enkel een header wordt toegevoegd en de
data van de elementaire stroom sequentieel bij het pakket wordt toegevoegd.
6.3.5 PES-header
We hebben deze header uitgebreid besproken in hoofdstuk 2 aan de hand van
Figuur 2.7. Voor een syntax van de PES-header kan je terecht op het einde
van deze thesis.
Het volledige BSDL-schema voor MPEG-2 Systems vind je immers terug
in Bijlage E. De packetheader bijvoorbeeld vind je op het einde van de bijlage
terug.
6.3.6 Probleem met BSDL-software?
Een doel in deze thesis was ook om de juiste grens te bepalen tussen de PES
header en de eigenlijke data van het pakket (de data sequentieel genomen
uit een elementaire stroom). Zo konden we een elementaire stroom volledig
reconstrueren aan de hand van die data en zal een Video Elementaire Stroom
terug aan het schema voor MPEG-2 Video voldoen. Dit bepalen van de grens
tussen header en data in een PES-pakket is niet gelukt. Er zijn nochtans
veel manieren en mogelijkheden getest, waarbij een voor de hand liggend
voorbeeld te zien is op Figuur 6.5
51
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/mpeg-2_systems.xsd
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ********************************** --> <!-- PacketHeader declaration --> <!-- *********************************** --> - <xsd:element name="PacketHeader">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="packet_start_code" type="mp2:StartCodeType" /> <xsd:element name="packet_length" type="bt:b16" /> <xsd:element name="skipbits_2" type="bt:b2" /> <xsd:element name="PES_scrambling_control" type="bt:b2" /> <xsd:element name="PES_priority" type="bt:b1" /> <xsd:element name="data_alignment_indicator" type="bt:b1" /> <xsd:element name="copyright" type="bt:b1" /> <xsd:element name="original_or_copy" type="bt:b1" /> <xsd:element name="PTS_DTS_flag_1" type="bt:b1" /> <xsd:element name="PTS_DTS_flag_2" type="bt:b1" /> <xsd:element name="ESCR" type="bt:b1" /> <xsd:element name="ES_rate" type="bt:b1" /> <xsd:element name="DSM_trick_mode" type="bt:b1" /> <xsd:element name="additional_copy_info" type="bt:b1" /> <xsd:element name="PES_CRC" type="bt:b1" /> <xsd:element name="PES_extension" type="bt:b1" /> <xsd:element name="PES_header_length" type="xsd:unsignedByte" />
<!-- ? Bug in Systems schema to define exact position of the beginning of the elementary stream ? -->
- <xsd:element name="Header_Payload">
- <xsd:simpleType>
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<bs2:length value="../mp2:PES_header_length" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element>
</xsd:schema>
file:///D|/2e Licentie/thesis/BDSL MPEG-2/DIA_BSDL_1_1_3/CONTENT/mpeg-2_systems.xsd (11 of 11)19/05/2005 3:44:59
Figuur 6.5: Bug in BSDL-software?
We hebben een element toegevoegd aan de PES header. Het tot dan
toe laatste element (PES Header Length) werd gebruikt om het byterange
type die bepaalde lengte mee te geven. Het element PES Header Length
geeft immers de lengte weer van de overige Header Data aanwezig in de
PES header. Dit zou dus betekenen dat we dit element kunnen gebruiken
om een exacte aantal bytes over te slaan en zo de grens te bepalen waar de
elementaire stroom begint. Deze constructie zien we op de figuur aan de hand
van het element Header Payload, dat een byteRange-type is en als lengte (bij
het attribuut value van element bs2:length) een XPath-expressie meekrijgt
dat eigenlijk gewoon het vorige element van deze PES-header beschouwt:
../mp2:PES header length.
Om een nog onverklaarbare reden wordt tijdens de BintoBSD operatie
een oneindige lus gegenereerd bij het parsen van dit element. Zoals we later
zullen zien is het Xpath-mechanisme in de BSDL-software niet zo optimaal
geprogrammeerd. Wellicht kan deze oneindige lus daarvan een gevolg zijn
maar dat staat niet vast.
52
Hoofdstuk 7
Aanpassen van MPEG-2
Systems
Met behulp van het schema dat we gedeeltelijk uitgelegd hebben in het
vorige hoofdstuk is het mogelijk om XML-beschrijvingen te genereren van
programmastromen gecodeerd volgens de MPEG-2 Systems standaard. Dit
XML-bestand kon men dan aanpassen via een XSLT transformatie, gebruik
makend van de Saxon XSLT Processor. In dit hoofdstuk zullen we zien hoe
we via BSDL een demultiplexer ontwerpen in Audio en Video.
7.1 Demultiplexer
7.1.1 Weglaten van PES Audiopakketten
Via BSDL kunnen we op een eenvoudige manier een demultiplexer ontwer-
pen voor een MPEG-2 programmastroom. We zullen zien hoe we bepaalde
soorten pakketten kunnen weglaten om zo een soort “filter” te bekomen die
bijvoorbeeld audiopakketten wegfiltert uit de programmastroom.
Zoals we kunnen zien op Figuur 7.1 laten we in de programmastroom de
audiopakketten weg. Indien een pack dus een PES audiopakket bevat, zal dat
pack na uitvoering van de transformatie het audiopakket niet meer bevatten.
53
V V A V V A D V V A
PackPack
Pack
V V V V D V V
PackPack
Pack
V A DPES Videopakket PES Audiopakket PES Datapakket
Figuur 7.1: Demultiplexer: weglaten audiopakketten
Dit mechanisme was via BSDL ook weer via een eenvoudige editeerbewerking
te realiseren. Figuur 7.2 toont hoe de stylesheet (XSLT) om audiopakketten
weg te laten er gedeeltelijk uitziet.
Op eenvoudige wijze kunnen we andere pakketten laten wegvallen uit een
programmastroom. Daartoe hoeven we enkel het woord AudioPacket te ver-
gangen door VideoPacket (om een audiostroom te verkrijgen), PrivatePacket,
... Na de transformatie bekomen we dus een aangepaste XML-beschrijving
zonder audiopakketten in de programmastroom. De resulterende bitstroom
(BSDToBin) zal dan enkel een videostroom (in pakketten) bevatten.
Merk op dat Audiopakketten (zoals MPEG-2 Systems ze definieert) meest-
al niet voorkomen bij een recente DVD. Meestal zal de audio AC3 (Dolby Di-
54
<?xml version="1.0" ?> <!-- Be careful with namespaces! --> - <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:
mp2="MPEG2" version="1.0"> <xsl:output method="xml" indent="yes" />
<!-- Match all: default template --> - <xsl:template name="tplAll" match="@*|node()">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Match root element --> - <xsl:template match="mp2:MPEG2Systems">
- <xsl:copy>
<xsl:apply-templates select="@*|node()" /> </xsl:copy>
</xsl:template> <!-- Do nothing for processing instructions --> <xsl:template match="processing-instruction()" />
- <xsl:template match="mp2:packet[count(mp2:AudioPacket) = 1]">
<!-- Nothing ! --> </xsl:template>
</xsl:stylesheet>Figuur 7.2: Demultiplexer: XSLT stylesheet
gital) of Dolby Surround zijn. Daardoor zullen we voor de demultiplexer geen
audiopakketten maar andere pakketten moeten weglaten. De audiostandaard
AC3 wordt in een programmastroom opgeslagen als Private1-pakketten. Als
we de XSLT aanpassen en “AudioPacket” veranderen door “Private1Packet”
zullen we een DVD met AC3 audio kunnen demultiplexeren.
Deze operatie geeft wel enkele neveneffecten bij sommige decoders. Som-
mige bestanden kunnen afgespeeld worden met Power DVD, andere met Nero
Showtime en nog andere met Windows Media Player. Dit is wellicht te wijten
aan de foutgevoeligheid van deze softwarepakketten. Wellicht ligt de oorzaak
ervan aan het feit dat er in de packheaders en systemheaders informatie staat
dat er nog een audiostroom aanwezig is in de programmastroom maar dit in
feite niet meer zo is na de demultiplex-operatie.
55
7.1.2 Extrapoleren van de elementaire stroom
Een tweede stap zou erin bestaan de elementaire stromen te reconstrueren
uit de programmastroom (dat enkel video PES-pakketten bevat). Dit pro-
bleem hebben we al gedeeltelijk besproken op het einde van hoofdstuk 6.
Daarin zagen we dat de BSDL-software een oneindige lus genereerde toen we
probeerden de exacte positie te bepalen tussen header en data van een PES-
pakket. Als we die exacte grens konden bepalen, zouden we de elementaire
stroom kunnen reconstrueren uit de verschillende PES Videopakketten. Dit
scenario die we voor ogen hadden vind je terug op Figuur 7.3.
V V V V V V
PackPack
Pack
PES Payload
PES Payload
…. Elementaire videostroom ….
V
PES Payload
Figuur 7.3: Demultiplexer: reconstrueren van de elementaire stroom
56
We zien hoe de PES-pakketten afzonderlijk worden behandeld. Van ie-
der PES-pakket bepalen we de grens van de header en van de payload (data
van de elementaire stroom). De payloads van de verschillende PES-pakketten
voegen we dan samen (concateneren) om zo de Video Elementaire Stroom te-
rug te bekomen. Deze elementaire stroom zou dan bovendien ook “voldoen”
aan het MPEG-2 Video BSDL-schema dat we ontworpen hebben. De ver-
schillende transformaties zoals aspect ratio verandering, weglaten van beel-
den, ... zouden dan bovendien kunnen toegepast worden op deze stroom.
Dit scenario lijkt in de praktijk eenvoudig te verwezenlijken, zoals we
besproken hebben op het einde van het vorige hoofdstuk. De BSDL-software
zorgde dus voor een oneindige loop toen we een extra element in de PES
header toevoegden (type byterange, met als lengte de waarde van het vorige
element: PES Header Length). Deze operatie BinToBSD mislukte spijtig
genoeg om een nog duistere reden.
7.2 Statistieken
<?xml version="1.0" ?> <!-- Be careful with namespaces! --> - <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:
mp2="MPEG2" version="1.0"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" /> - <xsl:template match="/mp2:MPEG2Systems">
- <html>
- <head>
<title>MPEG-2 Systems - Statistics</title> </head>
- <body>
<h1>MPEG-2 Systems - Statistics</h1> Number of packs:
<xsl:value-of select="count(./mp2:Pack)" /> <br />
Number of pack headers: <xsl:value-of select="count(./mp2:Pack/mp2:PackHeader)" /> <br />
Number of system headers: <xsl:value-of select="count(./mp2:Pack/mp2:PackHeader/mp2:SystemHeader)" /> <br /> <hr />
Number of PSMapTable packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:PSMapTable)" /> <br />
Number of Private1 packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:Private1Packet)" /> <br />
Number of Padding packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:PaddingPacket)" /> <br />
Number of Private2 packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:Private2Packet)" /> <br />
Number of audio packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:AudioPacket)" /> <br />
Number of video packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:VideoPacket)" /> <br />
Number of Reserved0 packets: <xsl:value-of select="count(./mp2:Pack/mp2:packet/mp2:Figuur 7.4: MPEG-2 Systems Statistieken: Stylesheet
Van een gegeven bitstroom kan men gemakkelijk statistieken verzame-
len door bijvoorbeeld het aantal elementen te tellen in de XML-beschrijving.
Op Figuur 7.4 zien we een klein extract van de stylesheet waar een “count”
operatie gebeurt om het aantal video- en audiopakketten te bepalen. Na
57
uitvoering van deze stylesheet (die een HTML-pagina als output heeft) be-
komen we een aantal statistieken. Deze statistieken gegenereerd met behulp
van deze stylesheet vinden we hieronder terug:
MPEG-2 Systems - Statistieken
Number of packs: 3506
Number of pack headers: 3506
Number of system headers: 0
Number of PSMapTable packets: 0
Number of Private1 packets: 574
Number of Padding packets: 45
Number of Private2 packets: 88
Number of audio packets: 0
Number of video packets: 2971
Hier zien we een aantal statistieken van een kort deel van een .vob-bestand
(DVD). We bemerken onder andere heel wat videopakketten, maar ook veel
Private1-pakketten (AC3). Verder vinden we ook nog een aantal Padding
-en Private2-pakketten terug. Een Private2-pakket kan bijvoorbeeld de on-
dertitels bevatten, al zijn we dit niet zeker.
58
Hoofdstuk 8
Performantiemetingen van
BSDL op MPEG-2
Tot nu toe hebben we gezien hoe we een schema opstellen, meer bepaald voor
de MPEG-2 Video en MPEG-2 Systems standaard. We voerden ook enkele
transformaties door met behulp van XSLT, om zo via BSDtoBin een nieuwe
aangepaste bitstroom te verkrijgen. Deze theoretische concepten voerden we
in de realiteit uit door middel van de parsers BinToBSD en BSDToBin, en
met behulp van de Saxon XSLT en XQuery Processor (voor de transforma-
ties).
Zijn deze concepten “bruikbaar” in de praktijk. Met “bruikbaar” bedoe-
len we een antwoord op de vraag: “Is het mogelijk een XML-beschrijving aan
te passen en een nieuwe bitstroom te genereren in real-time met de huidige
BSDL-referentiesoftware?”. “Real-time” wordt gehaald als de tijd nodig voor
de transformatie en het genereren van een nieuwe bitstroom niet de lengte
van de bitstroom overschrijdt. De uitvoeringstijd voor BintoBSD is iets min-
der belangrijk omdat dit enkel eenmaal hoeft te gebeuren en de beschrijving
wordt dan opgeslaan naast de bitstroom.
De metingen werden uitgevoerd op een PC met een Intel Pentium IV 3.2
Ghz processor (HyperThreading) en 1GB RAM. Het besturingssysteem dat
gebruikt werd is Windows XP Professional (Service Pack 2). Er werd gebruik
59
gemaakt van de Java 2 Standard Edition, versie 1.5.0, van Sun Microsystems
als Java virtuele machine.
8.1 Performantie van BinToBSD
8.1.1 Lange MPEG-2 Systems programmastroom
We hebben de performantieresultaten van verschillende lange programma-
stromen samengevat in Tabel 8.1.
seq duur # beelden tijd(s) Grootte(kB) XML(kB) ZIP(kB) Factor(%) RAM(Mb)S1 08:47 15802 567 237796 121189 1837 98 800+S2 04:24 7905 314 117824 90457 1249 99 600+S3 02:56 5265 204 78520 60271 833 99 500+S4 02:12 3957 160 59042 44989 627 99 400S5 01:45 3156 127 47124 36168 501 99 350S6 01:28 2646 105 39526 30334 420 99 320S7 01:06 1986 80 29700 22790 316 99 240S8 00:53 1575 64 23580 18091 251 99 180S9 00:44 1320 55 19790 15182 211 99 160
Tabel 8.1: Statistieken BintoBSD MPEG-2 Systems
Uitvoeringstijd
De uitvoeringstijd van de BinToBSD operatie is heel lang. Voor een program-
mastroom van ongeveer 9 minuten afspeeltijd hebben we een uitvoeringstijd
van 567 seconden, ofwel 9.5 minuten. Een algemene regel af te leiden van de
tabel is dat de operatie langer duurt dan de multimediastroom zelf (afspeel-
tijd).
Figuur 8.1 toont aan dat de uitvoeringstijd lineair stijgt in verhouding
met het aantal beelden (frames).
60
Uitvoeringstijd BintoBSD (MPEG-2 Systems)
0
100
200
300
400
500
600
0 2000 4000 6000 8000 10000 12000 14000 16000 18000
aantal frames
uitv
oerin
gstij
d (s
)
MPEG-2
Figuur 8.1: Uitvoeringstijd BinToBSD t.o.v. aantal beelden
Grootte van de XML-beschrijving
De grootte van de XML-beschrijvingen is ook “impressionant” te noemen.
Een XML-bestand van 120 MB voor een videostroom van 238 MB (en slechts
9 minuten lengte!) is een enorm groot bestand. Wanneer we deze bestanden
comprimeren met een standaard ZIP algoritme bekomen we opmerkelijke
resultaten. Een compressiefactor van 99% wordt bij iedere XML-beschrijving
bereikt. Dit komt door de oneindig vele herhalingen van elementen in het
XML-bestand zoals bijvoorbeeld de elementen PacketHeader en Pack.
Op Figuur 8.2 stellen we vast dat de grootte van de XML-beschrijvingen
logaritmisch stijgt in verhouding met het aantal beelden (frames).
61
Grootte beschrijving t.o.v. aantal beelden
0
20
40
60
80
100
120
140
0 5000 10000 15000 20000Aantal frames
Gro
otte
XM
L-B
esch
rijvi
ng (M
b)
MPEG-2
Figuur 8.2: Grootte van de XML-beschrijving t.o.v. aantal beelden
Geheugengebruik
Het geheugengebruik speelt ook een heel grote rol in de performantie van
BinToBSD-operaties. Voor de langste 3 sequenties (van 9 minuten, 4,5 minu-
ten en 3 minuten) was het programma waarmee we werkten voor de metingen
(JProfiler) zelfs niet in staat nog het geheugengebruik vast te leggen. Door
taakbeheer van Windows in het oog te houden hebben we toch een schatting
genoteerd in de tabel van het geheugengebruik (zonder gebruik van het JPro-
filer programma). De langste sequentie van 9 minuten had maar liefst meer
dan 800 Mb RAM geheugen nodig om een XML-beschrijving te genereren.
Dit is gigantisch veel, als men bedenkt om met het Systems BSDL-schema
een DVD te laten beschrijven. Dit zou dan een geheugen nodig hebben van
meer dan 10 Gb?
De reden voor deze “bottleneck” is de BSDL-referentiesoftware zelf, meer-
62
bepaald de werking van het XPath-mechanisme. Omdat er soms “vorige”
elementen uit de beschrijving nodig zijn om de bitstroom verder te parsen,
wordt de volledige boom opgeslaan in het geheugen, wat voor een enorme
overhead zorgt. Telkens zo’n expressie moet berekent worden, zal men een
soort “dubbel” maken van de “tot-nu-toe-verkregen”-beschrijving en de be-
rekening daarop doorvoeren. Aan de BSDL-software wordt binnen Multime-
dialab van de Universiteit Gent momenteel gewerkt. Men verwacht dat, met
deze geplande optimalisaties, een betekenend verschil in geheugengebruik zal
opgemeten worden.
Op Figuur 8.3 zien we het verloop van het geheugengebruik van de JVM
tijdens het parsen van sequentie S6.
Heap telemetry graph
Heap telemetry graph
Session: long mpeg-2 systems stream
Time of export: Saturday, May 7, 2005 4:44:41 PM CEST
JVM time: 19:25
Vrij geheugen Gebruikt geheugen
file:///D|/2e Licentie/THESIS DVD/Performantiemetingen/BinToB...ems (long sequence)/Chevy one sixth/Heap_telemetry_graph.html30/05/2005 2:17:43
Figuur 8.3: Geheugengebruik BinToBSD bij sequentie S6
63
8.1.2 Korte MPEG-2 Video bitstroom
We hebben dezelfde metingen uitgevoerd, nu eens op korte sequenties van
MPEG-2 Video. De resultaten vind je terug in Tabel 8.2.
seq duur(s) # beelden tijd(s) Grootte(kB) XML(kB) ZIP(kB) Factor(%) RAM(Mb)V1 10,0 300 14,3 6104 217 6,85 97 3,8V2 5,4 162 7,2 3317 119 4,28 96 2,8V3 3,4 102 4,6 2096 76 3,16 96 2,2V4 2,9 87 4,0 1791 65 2,88 96 2,2V5 2,4 72 3,4 1486 55 2,59 95 2V6 1,9 57 2,8 1181 44 2,30 95 1,8V7 1,4 42 2,2 876 33 2,01 94 1,5
Tabel 8.2: Statistieken BintoBSD MPEG-2 Video
Bij enkele metingen met korte videosequenties kwamen we tot ongeveer
dezelfde conclusies. De uitvoeringstijd van BinToBSD lag opnieuw hoger
dan de afspeeltijd van de videostroom zelf. De XML-beschrijving was heel
wat kleiner dan de bitstroom, terwijl bij MPEG-2 Systems de beschrijvingen
ongeveer 2/3 van de grootte van de bitstroom innamen. Dit komt door-
dat een programmastroom veel meer “pakketten” (element Packet) bevat
dan de videostroom “beelden” (element Picture) bevat. Het MPEG-2 Video
BSDL-schema presteert dus gevoelig beter qua grootte van de beschrijving.
De compressiefactor van de beschrijving ligt opnieuw boven de 95%. Het
geheugengebruik stijgt bovendien lineair met het aantal frames.
8.2 Performantie van de transformaties
We hebben enkele resultaten samengevat in Tabel 8.3.
seq transformatie # beelden tijd(s) geheugengebruik(Mb)S2 Weglaten Audio 7905 50s 400-S4 Weglaten Audio 3957 29s 256-V1 Weglaten B 300 2s 3-
Tabel 8.3: Enkele XSLT transformaties met behulp van Saxon
64
Uit de tabel volgt dat de transformaties relatief vlot worden uitgevoerd en
bijna de helft minder RAM-geheugen nodig hebben dan de binToBSD ope-
ratie op dezelfde sequentie. Het weglaten van B-beelden (Picture-elementen
in de XML-beschrijving) duurt ongeveer even lang als het weglaten van au-
diopakketten (Packet-elementen in de XML-beschrijving) bij een program-
mastroom. De grootste tijd van de transformaties, die werden uitgevoerd
met behulp van de Saxon XSLT en XQuery Processor, wordt dan nog eens
ingenomen door de I/O-operaties bij het uitschrijven van de resulterende
aangepaste XML-beschrijving.
8.3 Performantie van BSDToBin
8.3.1 Lange MPEG-2 Systems programmastroom
We hebben de performantieresultaten van verschillende lange programma-
stromen voor BSDToBin samengevat in Tabel 8.4. Hierbij hebben we de
verkregen XML-beschrijving terug omgezet naar de originele bitstroom (zon-
der dus enige aanpassing te doen aan de beschrijving).
seq duur # beelden tijd(s) RAM(Mb)S4 02:12 3957 43,5 600+S5 01:45 3156 28,9 500+S6 01:28 2646 24,9 430S7 01:06 1986 17,6 340S8 00:53 1575 14,9 260S9 00:44 1320 12,7 220
Tabel 8.4: Statistieken BSDToBin MPEG-2 Systems
De uitvoeringstijd van BSDToBin is opvallend lager dan van BinToBSD,
wat vooral te wijten is aan het feit dat BSDToBin immers geen behoefte heeft
aan een XPath-mechanisme om XPath-expressies te evalueren. Een sequentie
met afspeeltijd van ongeveer 2 minuten zal een 40 seconden duren om terug
te genereren. Dit is opvallend beter dan de BinToBSD-operatie op dezelfde
sequentie die 160 seconden duurde. Het geheugengebruik bij deze operatie
65
stijgt echter in vergelijking met de BinToBSD-operatie, wat voor nog grotere
getallen zorgt. Sequentie S4 gebruikt maar liefst meer dan 600 Mb RAM om
terug gegenereerd te worden. Deze parser kan men dus wellicht ook verder
optimaliseren. Ook aan dit probleem wordt gewerkt binnen Multimedialab.
Op Figuur 8.4 zien we het verloop van het geheugengebruik van de JVM
tijdens de BSDToBin-operatie van sequentie S6. Deze figuur kan men verge-
lijken met Figuur 8.3 die het geheugengebruik tijdens de BinToBSD-operatie
voorstelt.
Heap telemetry graph
Heap telemetry graph
Session: New session
Time of export: Monday, May 30, 2005 12:24:44 AM CEST
JVM time: 26:37
Vrij geheugen Gebruikt geheugen
file:///D|/2e Licentie/THESIS DVD/Performantiemetingen/BSDTo...ms (long sequence)/Chevy one sixth/Heap_telemetry_graph.html30/05/2005 2:19:23
Figuur 8.4: Geheugengebruik BSDToBin bij sequentie S6
66
8.3.2 Korte MPEG-2 Video bitstroom
We hebben dezelfde metingen uitgevoerd, nu eens op korte sequenties van
MPEG-2 Video. De resultaten vind je terug in Tabel 8.5.
seq duur(s) # beelden tijd(s) RAM(Mb)V1 10,0 300 1,5 4,0V2 5,4 162 1,2 3,0V3 3,4 102 1,0 2,2V4 2,9 87 0,9 2,0V5 2,4 72 0,9 2,0V6 1,9 57 0,8 2,0V7 1,4 42 0,7 2,0
Tabel 8.5: Statistieken BSDToBin MPEG-2 Video
Uit deze resultaten kunnen we ongeveer dezelfde conclusies halen. BSD-
ToBin presteert heel wat beter qua uitvoeringstijd maar niet qua geheugen-
gebruik.
67
8.4 Besluit
Het grote geheugengebruik vormt een grote “bottleneck” in de huidige BSDL-
referentiesoftware. De grote uitvoeringstijd van de BinToBSD-operatie is
ook noemenswaardig, al is dit een minder vervelend probleem aangezien de
BinToBSD-operatie slechts een keer hoeft te gebeuren waarbij de resulterende
XML-beschrijving wordt opgeslagen naast de bitstroom zelf.
Om grote programmastromen aan te passen in real-time zal er veel re-
kenkracht voor nodig zijn met de huidige BSDL-software. Door enkele op-
timalisaties kan men vermoedelijk een veel beter geheugengebruik realiseren
bij beide operaties. Voorlopig lijkt het real-time aanbieden van multimediale
data met behulp van aanpassingen via BSDL moeilijk realiseerbaar omwille
van het enorme geheugengebruik tot bijna 1 GB RAM voor een sequentie
van ongeveer 9 minuten afspeeltijd.
Toch blijft de tijd nodig voor de transformatie en de BSDToBin-operatie
onder de tijd van de sequentie zelf. Indien men dus enkel het geheugengebruik
tracht te optimaliseren (zonder neveneffecten op de uitvoeringstijd) zouden
we ook lange sequenties in real-time kunnen aanpassen.
68
Hoofdstuk 9
H.264/AVC in een MPEG-2
programmastroom
Een nieuw formaat voor de DVD duikt op. De “nieuwe” codec H.264/AVC
(MPEG-4 deel 10) kan in een programmastroom ondergebracht worden en
zo zou deze codec onder meer gebruikt worden op HD-DVD (High Definition
DVD). De H.264-technologie zorgt ervoor dat High Definition-video’s, kort-
weg HD-video’s genoemd, met een resolutie van 1280x720 en 1920x1080 ge-
comprimeerd kunnen worden naar een datastream van respectievelijk 8Mbps
of 10Mbps. Het nu nog veelgebruikte MPEG2-formaat (voor video) heeft
voor dezelfde kwaliteit een datastream van 15Mbps nodig. Vele bedrijven
hebben al maatregelen genomen omdat men verwacht dat deze nieuwe tech-
nologie een bloeiende toekomst voor zich heeft. Bedrijven als Apple, Main-
Concept, Ahead Software (Nero), Microsoft en ATI hebben zich al verdiept
in de H.264-wereld. ATI zal bijvoorbeeld zorgen voor een hardwarematige
H.264 ondersteuning.
Een nadeel van de verbeterde compressiemethode van H.264/AVC is dat
veel rekenkracht benodigd is voor het decoderen en dat ondersteuning van
de grafische hardware hard nodig is om beelden vloeiend weer te geven. Het
Canadese ATi heeft al laten weten toekomst te zien in HD-video als er ge-
bruikgemaakt zou worden van speciale hardware, omdat de huidige hardware
69
niet voldoende rekenkracht kan leveren. Op dit moment biedt ATi al video-
kaarten aan met hardwarematige ondersteuning van het MPEG4-formaat.
Die berekeningen worden uitgevoerd door ALU’s van pixel processors bin-
nen een videochip. Of de H.264-ondersteuning ook uitgevoerd zal worden
via een extra videochip of dat dit zal gebeuren via speciale instructies op de
bestaande chips, is nog niet bekend.
Een manier om H.264/AVC stromen, meer algemeen MP4-stromen, onder
te brengen in een MPEG-2 programmastroom vinden we terug op Figuur 9.1.
Deze programmastroom bestaat uit een Object Descriptor (OD) stroom, een
Scene Description stroom (SD - BIFS command - cfr. MPEG-4 XMT), een
BIFS-Anim stroom en een IPMP-stroom. Alle stromen zijn gemultiplexeerd
in een FlexMux stroom.
BIFS staat voor Binary Format for Scene Description, een soort “taal”
waarin men scenes kan beschrijven via een boomstructuur. Object Descrip-
tors zijn “toegangspunten” tot MPEG-4 data. Elementary Stream Descrip-
tors zijn onderdelen van de Object Descriptor en zorgen voor de identificatie
van een elementaire stroom (video, audio, ...). Een IPMP-stroom zorgt voor
IP-adres-beveiliging.
MPEG-4 XMT (eXtensible Textual Format) is gebaseerd op W3C XML
en is in feite een raamwerk voor de beschrijving van audiovisuele scenes. Een
SD-stroom (ofwel BIFS-stroom) kan men dus beschrijven met behulp van
XMT.
Doordat MPEG-4 XMT ook een extensie vormt op W3C XML, vormt
zich de vraag of BSDL en MPEG-4 XMT niet gecombineerd kunnen worden
voor bijvoorbeeld het beschrijven van een programmastroom die audiovisuele
scenes bevat (beschreven met MPEG-4 XMT). Een voorbeeld is om via BSDL
audiovisuele scenes te veranderen of toe te voegen aan de Object Descriptor
Stream, vervat in de programmastroom.
Wat volgt is een kleine “handleiding” om aan de ontvangerszijde een
programmastroom met H.264/AVC als video, te interpreteren en decoderen.
Deze programmastroom zal een Program Stream Map moeten bevatten; dit
is een PES-pakket met een startcode van 0x000001BC.
70
ISO/IEC 13818-1 : 2000 (E)
ITU-T Rec. H.222.0 (2000 E) 151
Objector Descriptor Stream
14496-1 FlexMux Stream
FMC = 0x01BIFS-Command Stream
FMC = 0x02OD Stream
PES Packet: stream_id = '1111 1011'
MPEG-2 Program Stream
PES Packet: stream_id = '1011 1100' PES Packet: stream_id = '1111 1011'
Program Stream Map
Initial Object Descriptor
FMC descriptor
14496-1 FlexMux Stream
FMC = 0x03BIFS_Anim Stream
FMC = 0x04IPMP Stream
Figure R.1 – Example of ISO/IEC 14496 content in a Program Stream
ObjectDescriptor { ES_Descriptor { ES_ID = 0x0013 streamType = "Visual stream" specificInfo = "BIFS-Anim" }}ObjectDescriptor { ES_Descriptor { ES_ID = 0x0014 streamType = "IPMP stream" }}
...ES_Descriptor { ES_ID = 0x0011 streamType = "SD stream" specificInfo = "BIFS-com"}ES_Descriptor { ES_ID = 0x0012 streamType = "OD stream"}...
...program_stream_info_length1st_descriptor_loop { IOD_descriptor {}}elementary_stream_map_length{ stream_type = 0x12 elementary_stream_id = '1111 1011' elementary_stream_info_length 2nd_descriptor_loop { FMC_descriptor {} }}CRC_32
(ES_ID, FMC) = (0x0011, 0x01)(ES_ID, FMC) = (0x0012, 0x02)(ES_ID, FMC) = (0x0013, 0x03)(ES_ID, FMC) = (0x0014, 0x04)
Figuur 9.1: H.264/AVC in een MPEG-2 programmastroom
• Haal de Program Stream Map uit het PES-pakket.
• Identificeer de Initial Object Descriptor (IOD) in de eerste descriptor
loop.
• Identificeer de ES-IDs (Elementary Stream IDs) van de Object Descrip-
tor, de Scene Description en andere stromen, beschreven in de IOD.
• Indien nodig, haal de SL Descriptor en de FMC (Flex Mux) Descriptor
in de tweede descriptor loop voor Elementary Stream IDs 0xFA en
0xFB op.
71
• Indien nodig, genereer van deze descriptors een Stream Map Table
tussen ES-IDs en de daarmee verbonden elementary stream ids in het
FlexMux kanaal.
• Identificeer de OD stroom (Object Descriptor) gebruik makende van
zijn ES-ID en de Stream Map Table.
• Identificeer andere stromen beschreven in de IOD gebruik makende van
hun ES-ID en de Stream Map Table.
• Houdt continu de OD stroom (Object Descriptor) in de gaten en iden-
tificeer ES-IDs van bijkomende stromen.
• Identificeer deze bijkomende stromen gebruik makende van hun ES-ID
en de Stream Map Table.
Met in het vooruitzicht de opkomst van de HD-DVD zullen we meer en
meer in contact komen met H.264/AVC-stromen. De HD-DVD bezit een
opslagcapaciteit van 20GB (single layer) met een doorvoersnelheid tot 36
Mbit/s, terwijl de huidige DVD 4.7 GB kan bevatten met een doorvoer-
snelheid tot 11 Mbit/s. Aangezien MPEG-4 videocodering mogelijk is bij
HD-DVD’s, zijn velen er nu al van overtuigd dat de H.264-videocodering
voor een nieuwe generatie DVD’s zal zorgen. Momenteel concurreert de HD-
DVD nog met een andere nieuwe technologie, genaamd Blu-Ray, dat op dit
moment (nog) geen support biedt voor MPEG-4 videocodering.
72
Hoofdstuk 10
Besluit
In deze thesis zochten we naar de mogelijkheden van BSDL op de MPEG-2
standaard, dat commercieel de meest succesvolle MPEG-standaard is, om-
wille van de brede waaier aan toepassingen zoals de DVD en HDTV.
In een eerste deel construeerden we een BSDL-schema voor MPEG-2 Vi-
deo dat een videosequentie (in MPEG-2 Video gecodeerd uiteraard) kon be-
schrijven tot op het niveau van de afzonderlijke beelden. Deze verkregen
beschrijvingen konden we vervolgens door middel van eenvoudige editeerbe-
werkingen aanpassen aan de hand van XSLT-transformaties. We voerden een
aantal “transformaties” uit op zo’n videosequenties, waarbij de belangrijkste,
het weglaten van B-beelden, temporele schaalbaarheid aantoont bij MPEG-2
Video.
Als tweede onderdeel bouwden we een BSDL-schema op voor de MPEG-2
Systems standaard, meer bepaald de programmastroom. Hierbij zagen we
dat we via BSDL relatief gemakkelijk bepaalde soorten pakketten konden
weglaten om zo een demultiplexer te verkrijgen. Zoals al vermeld, kan deze
demultiplexer nog verbetert worden om de elementaire stromen te reconstru-
eren uit de pakketgebaseerde programmastroom.
Met behulp van het ontworpen BSDL-schema voor een programmastroom
is het theoretisch mogelijk om een volledige DVD (.vob bestand) te beschrij-
ven. Het zou dan interessant zijn om de BSDL-beschrijving bijvoorbeeld te
73
verrijken met informatie over de posities van de hoofdstukken van een DVD,
of met een transformatie een bepaald hoofdstuk te selecteren, enzoverder...
In enkele performantiemetingen was het duidelijk dat de BSDL-referentie-
software nog heel wat geoptimaliseerd kon worden. Het geheugengebruik was
enorm bij beide operaties (binToBSD en BSDTobin), terwijl de uitvoerings-
tijd bij de BSDToBin-operatie binnen aanvaardbare normen bleef. Real-
time bitstromen aanpassen zou dus voor kleine videosequenties zeker geen
probleem mogen zijn. Voor grote bitstromen (en de beschrijving van een
volledige DVD in het bijzonder) is er de barriere van het geheugengebruik en
de trage BinToBSD-operatie.
Men zou beide BSDL-schema’s relatief eenvoudig verder kunnen uitbrei-
den door dieper in de syntax van de specificatie te duiken. Men moet dan
wel rekening houden met de toenemende grootte van de beschrijvingen. Voor
MPEG-2 Video kunnen we dan bijvoorbeeld tot op het (macro)blok-niveau
gaan parsen en enkele details in verband met de kleuren van de pixels pro-
beren te beschrijven.
Door het toenemende gebruik van H.264/AVC-videocodering kan men
ervoor zorgen om via BSDL ook beschrijvingen voor bijvoorbeeld de nieu-
we HD-DVD’s (met H.264 videocodering) te genereren. Een interessant
onderzoek zou dan kunnen liggen in het combineren van MPEG-4 XMT
(scenebeschrijving) en MPEG-21 BSDL Schema (bitstroombeschrijving), die
beide afstammen van het W3C XML Schema.
74
Bijlage A
Gebruik van de Thesis DVD
A.1 Overzicht
Op de DVD-ROM, behorende bij deze thesis, vinden we verschillende mappen
terug met volgende inhoud:
• de bestudeerde (gelezen) papers
• de bestudeerde standaarden
• de ontworpen BSDL-schema’s en demo’s
• de gebruikte tools
• wat bijkomende informatie en hulpbestanden
• de thesispresentatie
• de thesis in latex formaat
• de uitgevoerde performantiemetingen
75
A.2 Resultaten: Demo’s
In de map BSDL Schema’s en Demo’s vind je de belangrijkste praktische
resultaten terug van het werk dat we besproken hebben in deze thesis, zoals
de ontworpen BSDL-schema’s. In de map Demo’s tref je de verschillende
aanpassingen aan videostromen en programmastromen aan.
In de map ./BSDL Schema’s en Demo’s/Demo’s/MPEG-2 Video/ vinden
we drie submappen (aspect ratio, statistieken en weglaten beelden) waar-
in de demo’s staan van MPEG-2 Video. Klik op de verschillende video-
stromen (.mpg) om ze te bekijken in bijvoorbeeld Windows Media Play-
er. Analoge opmerkingen gelden ook voor de map ./BSDL Schema’s en
Demo’s/Demo’s/MPEG-2 Systems/ waar de demo’s voor programmastro-
men zich bevinden.
Als voorbeeld navigeren we naar de map ./BSDL Schema’s en Demo’s/
Demo’s/MPEG-2 Systems/Demultiplexer. Daar vinden we drie videostromen
terug: een originele programmastroom, de programmastroom zonder audio
en de programmastroom zonder video. Deze laatste twee sequenties werden
uiteraard bekomen door de demultiplexer via BSDL. Speel de bestanden
bijvoorbeeld af met Windows Media Player.
A.3 BinToBSD, BSDToBin en XSLT Demo’s
Je kan de operaties ook zelf doorvoeren als je de Java Runtime Environment
versie 1.5.0 of later hebt staan op je computer.
Navigeer daartoe naar de map ./BSDL Schema’s en Demo’s/binToBSD
en BSDToBin demo’s/CONTENT/MPEG-2. We zien dan deze vier sub-
mappen:
• MPEG-2 Systems BinToBSD : map met demo’s om de binToBSD-
operaties uit te voeren op programmastromen.
• MPEG-2 Video BinToBSD : map met demo’s om de binToBSD-operaties
uit te voeren op MPEG-2 videostromen.
76
• XSLT Transformaties Systems : map om de stylesheets toe te passen
en BSDtoBin-operaties uit te voeren op programmastromen.
• XSLT Transformaties Video : map om de stylesheets toe te passen en
BSDtoBin-operaties uit te voeren op videostromen.
Het enige wat men hoeft te doen is de .bat-bestanden uit te voeren. De
.jar-bestanden van de BSDL-referentiesoftware en de Saxon XSLT Processor
worden als classpath toegevoegd en staan ook (in de juiste mappen) op de
DVD. Merk op dat men eerst de hoofdmap zal moeten kopieren omdat deze
operaties anders proberen te schrijven naar de DVD.
Als voorbeeld navigeren we naar de map ./BSDL Schema’s en Demo’s/binToBSD
en BSDToBin demo’s/CONTENT/MPEG-2/XSLT Transformaties Video.
We vinden een .bat-bestand terug genaamd “bintobsd, remove B, bsdtobin”.
De inhoud van het .bat-bestand wordt hier als voorbeeld getoond:
java -cp ..\..\..\JavaAPIs\Xalan\xalan.jar;
..\..\..\JavaAPIs\Base64\base64.jar;
..\..\..\JavaAPIs\BSDL\BSDL.jar;
..\..\..\JavaAPIs\Log4J\log4j.jar;
..\..\..\BSDL\
BSDLParsers.BintoBSD
-in ./foreman2.mpg
-xsd ../../SCHEMAS/mpeg-2_video.xsd
-out foreman2.xml
java -cp .\saxonb8-3\saxon8.jar;.\saxonb8-3\saxon8sa.jar
net.sf.saxon.Transform foreman2.xml removeB.xsl > foreman2_B.xml
java -cp ..\..\..\JavaAPIs\Base64\base64.jar;
..\..\..\JavaAPIs\BSDL\BSDL.jar;
..\..\..\JavaAPIs\Log4J\log4j.jar;
..\..\..\BSDL\ BSDLParsers.BSDtoBin
-dom -in ./foreman2_B.xml -out ./foreman2_B.mpg
77
In dit bestand vinden we 3 commando’s terug die eerst de videosequen-
tie foreman2.mpg, in dezelfde map, beschrijft naar een XML-bestand fore-
man2.xml. Vervolgens zal de beschrijving worden aangepast via de stylesheet
voor het weglaten van B-beelden en tenslotte voert men de operatie BSDTo-
Bin uit om de resulterende bitstroom te verkrijgen met naam foreman2B.mpg.
Deze laatste videosequentie en de originele versie is afspeelbaar met onder
andere Windows Media Player.
Analoog kan men andere demo’s en operaties doorvoeren in andere map-
pen op deze DVD.
78
Bijlage B
MPEG-2 Basic Datatypes
Schema
Op de volgende pagina’s vinden we een XML-bestand dat de basis datatypes
declareert die we gebruiken in de BSDL-schema’s voor Video en Systems.
Dit zijn de types b1 - b16. De naam zelf is zodanig gekozen dat bijvoorbeeld
het type b3 een beperking is op een type unsignedShort, namelijk b3 heeft
een lengte van 3 bits. Deze types worden gedefinieerd aan de hand van de
maxExclusive-constructie.
79
<?xml version="1.0" ?> - <xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">- <xsd:annotation>
<xsd:documentation>This schema provides some datatypes definition for BSDL and gBSD Note that these types are not built-in BSDL datatypes, but are similar to user-derived types.</xsd:documentation>
</xsd:annotation> <!-- ################## Type for arrays of bits ################## -->
- <xsd:simpleType name="b16">
<xsd:restriction base="xsd:unsignedShort" /> </xsd:simpleType>
- <xsd:simpleType name="b15">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="32768" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b14">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="16834" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b13">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="8192" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b12">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="4096" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b11">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="2048" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b10">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="1024" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b9">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="512" />
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="b8">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="256" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b7">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="128" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b6">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="64" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b5">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="32" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b4">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="16" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b3">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="8" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b2">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="4" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="b1">
- <xsd:restriction base="xsd:unsignedShort">
<xsd:maxExclusive value="2" /> </xsd:restriction>
</xsd:simpleType> </xsd:schema>
Bijlage C
MPEG-2 Simple Types Schema
Op de volgende pagina’s vinden we een XML-bestand dat enkele types de-
clareert die we gebruiken in de BSDL-schema’s voor Video en Systems. Dit
zijn (onder andere) de types PackPayloadType en PicturePayloadType. De-
ze worden ook besproken in de hoofdstukken waar we de 2 schema’s (video
en systems) construeren. Ze zorgen voor een referentie naar de originele
bitstroom om zo blokken data gemakkelijk te kunnen “weglaten” in de be-
schrijving zelf.
82
<?xml version="1.0" encoding="UTF-8" ?> - <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bt="urn:mpeg:
mpeg21:2003:01-DIA-BasicDatatypes-NS" xmlns:bs0="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" xmlns:bs1="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" xmlns:bs2="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS">
- <xsd:annotation>
<xsd:documentation>Simple Types for the MPEG-2 syntax.</xsd:documentation>
</xsd:annotation> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" schemaLocation="BasicDatatypes.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" schemaLocation="BSDL-0.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" schemaLocation="BSDL-1.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" schemaLocation="BSDL-2.xsd" />
<!-- ******************************************* --> <!-- MPEG-2 Simple Types declaration --> <!-- ******************************************* --> - <xsd:simpleType name="StartCodeType">
- <xsd:restriction base="xsd:hexBinary">
<xsd:length value="4" /> </xsd:restriction>
</xsd:simpleType>- <xsd:simpleType name="Stuffing">
<xsd:restriction base="bs0:fillByte" /> </xsd:simpleType>
- <xsd:simpleType name="PackPayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<!-- packet start codes --> <bs2:startCode value="000001BC-000001FF" />
<!-- pack_start_code --> <bs2:startCode value="000001BA" />
<!-- program_end_code --> <bs2:startCode value="000001B9" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
- <xsd:simpleType name="PicturePayloadType">
- <xsd:restriction base="bs1:byteRange">
- <xsd:annotation>
- <xsd:appinfo>
<!-- Nieuw Beeld: Picture Start Code -->
<bs2:startCode value="00000100" /> <!-- In geval van een "laatste" beeld. --> <!-- Group Start Code --> <bs2:startCode value="000001B8" />
<!-- Sequence Header Start Code --> <bs2:startCode value="000001B3" />
<!-- Sequence End Code --> <bs2:startCode value="000001B7" />
</xsd:appinfo> </xsd:annotation>
</xsd:restriction> </xsd:simpleType>
</xsd:schema>
Bijlage D
MPEG-2 Video BSDL-Schema
Op de volgende pagina’s vinden we het ontworpen MPEG-2 Video BSDL-
Schema.
85
<?xml version="1.0" encoding="UTF-8" ?> - <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:mp2="MPEG2"
xmlns:bt="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" xmlns:bs0="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" xmlns:bs1="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" xmlns:bs2="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" targetNamespace="MPEG2" bs2:rootElement="mp2:MPEG2Video">
- <xsd:annotation>
<xsd:documentation>Schema for the MPEG-2 Video syntax.</xsd:documentation>
</xsd:annotation> <!-- The schemas are available in the SCHEMAS directory. --> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" schemaLocation="BasicDatatypes.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" schemaLocation="BSDL-0.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" schemaLocation="BSDL-1.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" schemaLocation="BSDL-2.xsd" />
<!-- xml.xsd is needed for the xml:base attribute of the root element. -->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd" /> <xsd:include schemaLocation="mpeg-2_simple_types.xsd" />
<!-- *************************************** --> <!-- MPEG2Video declaration --> <!-- *************************************** --> - <xsd:element name="MPEG2Video">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="bit_stuffing" type="mp2:Stuffing" minOccurs="0" /> - <xsd:element name="video_sequence" minOccurs="0"
maxOccurs="unbounded" bs2:ifNext="000001B3">- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:sequence_header" /> <xsd:element ref="mp2:sequence_extension" bs2:ifNext="000001B5" /> <xsd:element ref="mp2:extension_and_user_data" /> <xsd:element ref="mp2:GroupOfPictures" minOccurs="0" maxOccurs="unbounded" bs2:ifNext="000001B8" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <xsd:element name="sequence_end_code" type="mp2:StartCodeType" bs2:ifNext="000001B7" />
</xsd:sequence>
<xsd:attribute ref="xml:base" /> </xsd:complexType>
</xsd:element> <!-- *************************************** --> <!-- sequence_header declaration --> <!-- *************************************** --> - <xsd:element name="sequence_header">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="sequence_header_code" type="mp2:StartCodeType" /> <xsd:element name="horizontal_size_value" type="bt:b12" /> <xsd:element name="vertical_size_value" type="bt:b12" /> <xsd:element name="aspect_ratio_information" type="bt:b4" /> <xsd:element name="frame_rate_code" type="bt:b4" /> <xsd:element name="bit_rate_value_1" type="bt:b16" /> <xsd:element name="bit_rate_value_2" type="bt:b2" /> <xsd:element name="marker_bit" type="bt:b1" /> <xsd:element name="vbv_buffer_size_value" type="bt:b10" /> <xsd:element name="constrained_parameters_flag" type="bt:b1" /> <xsd:element name="load_intra_quantizer_matrix" type="bt:b1" /> - <xsd:element name="intra_quantizer_matrix" bs2:if="./mp2:
load_intra_quantizer_matrix != 0">- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="intra_quantizer_matrix_64" type="bt:b8" minOccurs="64" maxOccurs="64" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <xsd:element name="load_non_intra_quantizer_matrix" type="bt:b1" /> - <xsd:element name="non_intra_quantizer_matrix" bs2:if="./mp2:
load_non_intra_quantizer_matrix != 0">- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="non_intra_quantizer_matrix_64" type="bt:b8" minOccurs="64" maxOccurs="64" />
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element> <!-- *************************************** --> <!-- sequence_extension declaration --> <!-- *************************************** -->
- <xsd:element name="sequence_extension">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="extension_start_code" type="mp2:StartCodeType" /> <xsd:element name="extension_start_code_identifier" type="bt:b4" /> <xsd:element name="profile_and_level_indication" type="bt:b8" /> <xsd:element name="progressive_sequence" type="bt:b1" /> <xsd:element name="chroma_format" type="bt:b2" /> <xsd:element name="horizontal_size_extension" type="bt:b2" /> <xsd:element name="vertical_size_extension" type="bt:b2" /> <xsd:element name="bit_rate_extension" type="bt:b12" /> <xsd:element name="marker_bit" type="bt:b1" /> <xsd:element name="vbv_buffe_size_extension" type="bt:b8" /> <xsd:element name="low_delay" type="bt:b1" /> <xsd:element name="frame_rate_extension_n" type="bt:b2" /> <xsd:element name="frame_rate_extension_d" type="bt:b5" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- *************************************** --> <!-- GroupOfPictures declaration --> <!-- *************************************** --> - <xsd:element name="GroupOfPictures">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="group_start_code" type="mp2:StartCodeType" /> <xsd:element name="time_code_1" type="bt:b16" /> <xsd:element name="time_code_2" type="bt:b9" /> <xsd:element name="closed_gop" type="bt:b1" /> <xsd:element name="broken_link" type="bt:b1" /> <xsd:element name="bit_stuffing" type="mp2:Stuffing" minOccurs="0" /> <xsd:element ref="mp2:extension_and_user_data" /> <xsd:element ref="mp2:Picture" minOccurs="0" maxOccurs="unbounded" bs2:ifNext="00000100" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- *************************************** --> <!-- Extension_data declaration --> <!-- *************************************** --> - <xsd:element name="extension_and_user_data">
- <xsd:complexType>
- <xsd:sequence>
- <xsd:element name="extension_data" bs2:ifNext="000001B5">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="extension_start_code" type="mp2:StartCodeType" /> <xsd:element name="payload" type="mp2:PicturePayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element>- <xsd:element name="user_data" bs2:ifNext="000001B2">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="user_data_start_code" type="mp2:StartCodeType" /> <xsd:element name="payload" type="mp2:PicturePayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element> <!-- *************************************** --> <!-- Picture declaration --> <!-- *************************************** --> - <xsd:element name="Picture">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="picture_start_code" type="mp2:StartCodeType" /> <xsd:element name="temporal_reference" type="bt:b10" /> <xsd:element name="picture_coding_type" type="bt:b3" /> <xsd:element name="vbv_delay" type="bt:b16" /> - <xsd:element name="forward_motion_info" minOccurs="0" bs2:if="./
mp2:picture_coding_type = 2 or ./mp2:picture_coding_type = 3">- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="full_pel_forward_vector" type="bt:b1" /> <xsd:element name="forward_f_code" type="bt:b3" />
</xsd:sequence> </xsd:complexType>
</xsd:element>- <xsd:element name="backward_motion_info" minOccurs="0" bs2:if="./
mp2:picture_coding_type = 3">- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="full_pel_backward_vector" type="bt:b1" /> <xsd:element name="backward_f_code" type="bt:b3" />
</xsd:sequence> </xsd:complexType>
</xsd:element>- <xsd:element name="extra_info" minOccurs="0"
maxOccurs="unbounded" bs2:ifNext="80-FF">- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="extra_bit_picture" type="bt:b1" fixed="1" /> <xsd:element name="extra_information_picture" type="bt:b8" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <xsd:element name="extra_bit_picture" type="bt:b1" fixed="0" />
<!-- Make sure we are back byte-aligned. --> <xsd:element name="bit_stuffing" type="mp2:Stuffing" minOccurs="0" />
<!-- Picture Coding Extension has same syntax as extension_and_user_data -->
<xsd:element ref="mp2:extension_and_user_data" /> <!-- We are skipping the parsing of the slice stuff. -->
<xsd:element name="bit_stuffing" type="mp2:Stuffing" minOccurs="0" /> <xsd:element name="payload" type="mp2:PicturePayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd:schema>
Bijlage E
MPEG-2 Systems
BSDL-Schema
Op de volgende pagina’s vinden we het ontworpen MPEG-2 Systems BSDL-
Schema (programmastromen).
91
<?xml version="1.0" encoding="UTF-8" ?> <!-- ***************************************** -->
- <!--
MPEG2Systems Pack PackHeader ( + optional SystemHeader) packet VideoPacket -->
<!-- **************************************** --> - <xsd:schema targetNamespace="MPEG2" xmlns:xsd="http://www.w3.org/2001/
XMLSchema" xmlns:mp2="MPEG2" xmlns:bs0="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" xmlns:bs1="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" xmlns:bs2="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" xmlns:bt="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" elementFormDefault="qualified" bs2:rootElement="mp2:MPEG2Systems">
- <xsd:annotation>
<xsd:documentation>Schema for the MPEG-2 Systems Program Stream Syntax.</xsd:documentation>
</xsd:annotation> <!-- The schemas are available in the SCHEMAS directory: different Schemas for BSDL -->
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BasicDatatypes-NS" schemaLocation="BasicDatatypes.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL0-NS" schemaLocation="BSDL-0.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL1-NS" schemaLocation="BSDL-1.xsd" /> <xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-BSDL2-NS" schemaLocation="BSDL-2.xsd" />
<!-- xml.xsd is needed for the xml:base attribute of the root element. -->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd" /> <xsd:include schemaLocation="mpeg-2_simple_types.xsd" /> <xsd:include schemaLocation="mpeg-2_video.xsd" />
<!-- ************************************ --> <!-- MPEG2Systems declaration --> <!-- ************************************ --> - <xsd:element name="MPEG2Systems">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element bs2:ifNext="000001BA" ref="mp2:Pack" minOccurs="0" maxOccurs="unbounded" /> <xsd:element bs2:ifNext="000001B9" name="iso_11172_end_code" type="mp2:StartCodeType" />
</xsd:sequence> <xsd:attribute ref="xml:base" />
</xsd:complexType> </xsd:element> <!-- ************************************* --> <!-- Pack declaration --> <!-- Referenced by: - MPEG2Systems --> <!-- ************************************* --> - <xsd:element name="Pack">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PackHeader" /> - <xsd:element name="packet" minOccurs="0" maxOccurs="unbounded">
- <xsd:complexType>
- <xsd:choice>
<xsd:element bs2:ifNext="000001BC" ref="mp2:PSMapTable" /> <xsd:element bs2:ifNext="000001BD" ref="mp2:Private1Packet" /> <xsd:element bs2:ifNext="000001BE" ref="mp2:PaddingPacket" /> <xsd:element bs2:ifNext="000001BF" ref="mp2:Private2Packet" /> <xsd:element bs2:ifNext="000001C0-000001DF" ref="mp2:AudioPacket" /> <xsd:element bs2:ifNext="000001E0-000001EF" ref="mp2:VideoPacket" /> <xsd:element bs2:ifNext="000001F0" ref="mp2:Reserved0Packet" /> <xsd:element bs2:ifNext="000001F1" ref="mp2:Reserved1Packet" /> <xsd:element bs2:ifNext="000001F2" ref="mp2:Reserved2Packet" /> <xsd:element bs2:ifNext="000001F3" ref="mp2:Reserved3Packet" /> <xsd:element bs2:ifNext="000001F4" ref="mp2:Reserved4Packet" /> <xsd:element bs2:ifNext="000001F5" ref="mp2:Reserved5Packet" /> <xsd:element bs2:ifNext="000001F6" ref="mp2:Reserved6Packet" /> <xsd:element bs2:ifNext="000001F7" ref="mp2:Reserved7Packet" /> <xsd:element bs2:ifNext="000001F8" ref="mp2:Reserved8Packet" /> <xsd:element bs2:ifNext="000001F9" ref="mp2:Reserved9Packet" /> <xsd:element bs2:ifNext="000001FA" ref="mp2:Reserved10Packet" /> <xsd:element bs2:ifNext="000001FB" ref="mp2:Reserved11Packet" />
<xsd:element bs2:ifNext="000001FC" ref="mp2:Reserved12Packet" /> <xsd:element bs2:ifNext="000001FD" ref="mp2:Reserved13Packet" /> <xsd:element bs2:ifNext="000001FE" ref="mp2:Reserved14Packet" /> <xsd:element bs2:ifNext="000001FF" ref="mp2:Reserved15Packet" />
</xsd:choice> </xsd:complexType>
</xsd:element> </xsd:sequence>
</xsd:complexType> </xsd:element> <!-- ************************************* --> <!-- PackHeader declaration --> <!-- Referenced by: - Pack --> <!-- ************************************* --> - <xsd:element name="PackHeader">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="pack_start_code" type="mp2:StartCodeType" /> <xsd:element name="filler" type="bt:b2" fixed="1" /> <xsd:element name="system_clock_reference1" type="bt:b3" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="system_clock_reference2" type="bt:b15" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="system_clock_reference3" type="bt:b15" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="system_clock_ref_extension" type="bt:b9" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="mux_rate_part1" type="xsd:unsignedByte" /> <xsd:element name="mux_rate_part2" type="xsd:unsignedByte" /> <xsd:element name="mux_rate_part3" type="bt:b6" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="reserved" type="bt:b5" /> <xsd:element name="bit_stuffing" type="mp2:Stuffing" minOccurs="0" /> <xsd:element name="payload" type="mp2:PackPayloadType" /> <xsd:element bs2:ifNext="000001BB" ref="mp2:SystemHeader" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- SystemHeader declaration --> <!-- Referenced by: - PackHeader -->
<!-- ************************************* --> - <xsd:element name="SystemHeader">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="system_header_start_code" type="mp2:StartCodeType" /> <xsd:element name="header_length" type="bt:b16" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="rate_bound_part1" type="bt:b16" /> <xsd:element name="rate_bound_part2" type="bt:b6" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="audio_bound" type="bt:b6" /> <xsd:element name="fixed_flag" type="bt:b1" /> <xsd:element name="csps_flag" type="bt:b1" /> <xsd:element name="system_audio_lock_flag" type="bt:b1" /> <xsd:element name="system_video_lock_flag" type="bt:b1" /> <xsd:element name="marker_bit" type="bt:b1" fixed="1" /> <xsd:element name="video_bound" type="bt:b5" /> <xsd:element name="packet_rate_restriction_flag" type="bt:b1" /> <xsd:element name="reserved" type="bt:b7" /> <xsd:element bs2:ifNext="80-FF" ref="mp2:buffer" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- buffer declaration --> <!-- Referenced by: - SystemHeader --> <!-- ************************************* --> - <xsd:element name="buffer">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="stream_id" type="xsd:unsignedByte" /> <xsd:element name="bit_pattern" type="bt:b2" /> <xsd:element name="p_std_buffer_bound_scale" type="bt:b1" /> <xsd:element name="p_std_buffer_size_bound" type="bt:b13" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- PSMapTable declaration --> <!-- ************************************* --> - <xsd:element name="PSMapTable">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" />
<xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Private1Packet declaration --> <!-- ************************************* --> - <xsd:element name="Private1Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="packet_start_code" type="mp2:StartCodeType" /> <xsd:element name="packet_length" type="bt:b16" /> <xsd:element name="bit_stuffing" minOccurs="0" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- PaddingPacket declaration --> <!-- ************************************* --> - <xsd:element name="PaddingPacket">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Private2Packet declaration --> <!-- ************************************* --> - <xsd:element name="Private2Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="packet_start_code" type="mp2:StartCodeType" /> <xsd:element name="packet_length" type="bt:b16" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence>
</xsd:complexType> </xsd:element> <!-- ************************************* --> <!-- AudioPacket declaration --> <!-- ************************************* --> - <xsd:element name="AudioPacket">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="audio_stream_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- VideoPacket declaration --> <!-- ************************************* --> - <xsd:element name="VideoPacket">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="video_stream_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved0Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved0Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved1Packet declaration --> <!-- ************************************* -->
- <xsd:element name="Reserved1Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved2Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved2Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved3Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved3Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved4Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved4Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved5Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved5Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved6Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved6Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved7Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved7Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved8Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved8Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved9Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved9Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved10Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved10Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved11Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved11Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence>
</xsd:complexType> </xsd:element> <!-- ************************************* --> <!-- Reserved12Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved12Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved13Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved13Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved14Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved14Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ************************************* --> <!-- Reserved15Packet declaration --> <!-- ************************************* --> - <xsd:element name="Reserved15Packet">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element ref="mp2:PacketHeader" /> <xsd:element name="bit_stuffing" minOccurs="0" maxOccurs="1" type="mp2:Stuffing" /> <xsd:element name="pack_payload" type="mp2:PackPayloadType" />
</xsd:sequence> </xsd:complexType>
</xsd:element> <!-- ********************************** --> <!-- PacketHeader declaration --> <!-- *********************************** --> - <xsd:element name="PacketHeader">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element name="packet_start_code" type="mp2:StartCodeType" /> <xsd:element name="packet_length" type="bt:b16" /> <xsd:element name="skipbits_2" type="bt:b2" /> <xsd:element name="PES_scrambling_control" type="bt:b2" /> <xsd:element name="PES_priority" type="bt:b1" /> <xsd:element name="data_alignment_indicator" type="bt:b1" /> <xsd:element name="copyright" type="bt:b1" /> <xsd:element name="original_or_copy" type="bt:b1" /> <xsd:element name="PTS_DTS_flag_1" type="bt:b1" /> <xsd:element name="PTS_DTS_flag_2" type="bt:b1" /> <xsd:element name="ESCR" type="bt:b1" /> <xsd:element name="ES_rate" type="bt:b1" /> <xsd:element name="DSM_trick_mode" type="bt:b1" /> <xsd:element name="additional_copy_info" type="bt:b1" /> <xsd:element name="PES_CRC" type="bt:b1" /> <xsd:element name="PES_extension" type="bt:b1" /> <xsd:element name="PES_header_length" type="xsd:unsignedByte" />
<!-- Bug in Systems schema to define exact position of the beginning of the elementary stream --> - <!--
xsd:element name="Header_Payload"> <xsd:simpleType> <xsd:restriction base="bs1:byteRange"> <xsd:annotation> <xsd:appinfo> <bs2:length value="../mp2:PES_header_length"/> </xsd:appinfo> </xsd:annotation> </xsd:restriction>
</xsd:simpleType></xsd:element -->
</xsd:sequence> </xsd:complexType>
</xsd:element> </xsd:schema>
Bibliografie
[1] MPEG website. http://www.chiariglione.org/mpeg/.
[2] Barry G. Haskell, Atul Puri, and Arun N. Netravali. Digital Video: An
Introduction to MPEG-2. Chapman and Hall, 1997.
[3] Moving Picture Experts Group. ISO/IEC 13818-2 Generic Coding of
Moving Pictures and Associated Audio: Video. Mei 1994.
[4] Moving Picture Experts Group. ISO/IEC 13818-1 Generic Coding of
Moving Pictures and Associated Audio: Systems. November 1994.
[5] P.A. Sarginson. Mpeg-2: Overview of the systems layer. BBC Research
and Development Report No. 1996/2.
[6] A. Vetro, C. Christopoulos, and T. Ebrahimi. Universal multimedia ac-
cess. IEEE Signal Processing magazine, 20(2):16–16, Maart 2003.
[7] I. Burnett, R. Van de Walle, K. Hill, J. Bormans, and F. Pereira. Mpeg-
21: goals and achievements. IEEE Multimedia, 10(6):160–70, Oktober-
December 2003.
[8] Moving Picture Experts Group. ISO/IEC 21000-7 FDIS Part 7: Digital
Item Adaptation. December 2003. ISO/IEC JTC1/SC29/WG11 N6168.
[9] Saxon XSLT en XQuery Processor website.
http://saxon.sourceforge.net/.
104
