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
116
Embed
Methoden voor het manipuleren van MPEG-2 Video en MPEG-2 ...lib.ugent.be/fulltxt/RUG01/000/894/034/RUG01-000894034_2010_0001_AC.pdfToelating tot bruikleen “De auteur geeft de toelating
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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-
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)
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.
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.
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
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
<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 ################## -->