Studie en implementatie van mechanismen voor foutonderdrukking in H.264/AVC

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Studie en implementatie van mechanismen voor foutonderdrukking in H.264/AVC door Yves Dhondt Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. P. Lambert Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar

2

3 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Studie en implementatie van mechanismen voor foutonderdrukking in H.264/AVC door Yves Dhondt Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. P. Lambert Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar ii

4 Dankwoord Eerst en vooral wil ik een woord van dank richten tot de mensen die mij gedurende het afgelopen academiejaar geholpen hebben met dit afstudeerwerk. Vooreerst wil ik mijn promotor, Rik Van de Walle en in het bijzonder mijn begeleider, Peter Lambert bedanken voor de vele uren die ze vrijgemaakt hebben tijdens het jaar om me met raad en daad bij te staan. Ook wil ik hen bedanken omdat ze me tijdens het jaar de vrijheid gelaten hebben om zelf wat ideëen uit te werken. Ook wil ik mijn ouders, vrienden en medestudenten bedanken voor hun steun en luisterend oor tijdens dit drukke jaar. Zonder hen was het veel eenzamer en moeilijker geweest. i

5 De toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopïeren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Datum Handtekening ii

6 Studie en implementatie van mechanismen voor foutonderdrukking in H.264/AVC door Yves Dhondt Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in de Informatica. Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promoter: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. P. Lambert Samenvatting Trefwoorden: H.264/AVC standaard, flexibele macroblok ordening (FMO), datapartitionering, foutopvang Binnen dit afstudeerwerk wordt nagegaan welke mogelijkheden de nieuwe videocoderingsstandaard, H.264/AVC, biedt om fouten op te vangen tijdens het transport over netwerken met verlies. Meerbepaald wordt er gekeken naar flexibele macroblok ordening en datapartitionering. Ook worden, als deel van de opdracht, flexibele macroblok ordening en een foutrobuuste decoder geïmplementeerd. In een laatste deel wordt, via een groot aantal experimenten, flexibele macroblok ordening getest. Er wordt gezocht naar een verklaring voor het al dan niet wijzigen van de kosten en er wordt gekeken naar de verbeteringen in beeldkwaliteit bij het gebruik van flexibele macroblokken bij pakketverlies door gebruik te maken van spatiale interpolatietechnieken. iii

7 Inhoudsopgave Hoofdstuk 1 Inleiding Situering Doelstellingen Structuur...2 Hoofdstuk 2 Overzicht van de H.264/AVC standaard Ontstaan van de H.264/AVC standaard Enkele algemene begrippen Doelstellingen van de standaard en hun realisatie Bitsnelheid Netwerkvriendelijkheid Foutrobuustheid Flexibele vertragingsmechanismen bij codering Eenvoud Het coderingsproces Encoder Decoder Profielen en levels Eigenschappen van de H.264/AVC-profielen en hun betekenis Toepassingen van de H.264/AVC-profielen...14 Hoofdstuk 3 Een foutrobuuste decoder Inleiding Een model voor het versturen van bitstromen De verschillende soorten fouten in bitstromen en hun opvang Reconstructie van verloren macroblokken De originele referentiedecoder De nieuwe foutrobuuste decoder Software voor het maken van fouten NALURemover NALUReplacer NALURemover Hoofdstuk 4 Flexibele macroblok ordening Inleiding Wat is flexibele macroblok ordening Geschiedenis van FMO Wijzigingen in de codering Slicegroepen en de slicegroepmap Encoder Decoder De zeven FMO-types en hun syntax...31 iv

8 4.5.1 Waarom verschillende types gebruiken FMO in de H.264/AVC-syntax Type Type Type Type 3, 4 en Type Implementatie Een nieuw bestandsformaat De FrameInfo-structuur Picture Parameter Set Besluit...49 Hoofdstuk 5 Flexibele macroblok ordening in de praktijk: toepassingen en kosten Foutopvanging Inleiding Reconstructie met en zonder FMO De testopstelling Resultaten van het experiment: visuele verbetering Schaalbare kwaliteit: interessegebieden Inleiding Selectie van interessegebieden: een hulpprogramma De testopstelling Resultaten van het experiment Kosten Theoretische analyse Analyse van NAL-eenheden: een parser De testopstelling Resultaten van het experiment Besluit...68 Hoofdstuk 6 Datapartitionering Wat is datapartitionering Datapartitionering in H.264/AVC Reconstructie...72 Besluit...73 Appendix A: Eigenschappen van de functie bij FMO type Appendix B: Implementatie van FMO...77 Appendix C: CD-ROM...79 Bibliografie...80 v

9 Lijst van figuren Figuur 1 : ITU-T-aanbevelingen en ISO/IEC-standaarden...4 Figuur 2 : Tijdlijn voor de ontwikkeling van H.264/AVC...5 Figuur 3 : De verschillende delen van een beeld...6 Figuur 4: Bitsnelheden in MBit/s voor de verschillende standaarden...8 Figuur 5 : Het H.264/AVC lagenmodel...9 Figuur 6 : Schematische voorstelling van de H.264/AVC-encoder...11 Figuur 7 : Schematische voorstelling van de H.264/AVC-decoder...12 Figuur 8 : Bitstromen - (a) zonder fouten - (b) een ontbrekende NAL-eenheid - (c) een te vroege NAL-eenheid...16 Figuur 9 : Spatiale (a) en temporele (b & c) reconstuctie...18 Figuur 10: Bitstromen met fouten - (a) zonder fouten - (b) 2 slices gewisseld in frame 0 - (c) 2 slices gewisseld tussen frame 0 en 1 - (d) een verloren slice voor frame Figuur 11: Mogelijke slices in een beeld met FMO...26 Figuur 12 : Indeling van een beeld met (b) en zonder (a) slicegroepen...27 Figuur 13 : Slicegroepmap met zes slicegroepen voor een QCIF-beeld...28 Figuur 14: Slicegroepmap voor FMO type 0 met 3 slicegroepen...33 Figuur 15: Slicegroepmappen voor FMO type 1 met 3 (a) en 5 (b) slicegroepen...35 Figuur 16 : Slicegroepmappen voor FMO type 2 met 3 slicegroepen...36 Figuur 17 : Voorbeeld van het algoritme voor de constructie van een slicegroepmap aan de hand van FMO type Figuur 18 : Slicegroepmappen voor FMO type 3 met groeisnelheid Figuur 19 : Gedeeltelijke constructie van een slicegroepmap voor FMO type Figuur 20 : Slicegroepmappen voor FMO type 4 met groeisnelheid Figuur 21 : Slicegroepmappen voor FMO type 5 met groeisnelheid Figuur 22 : Stapsgewijze reconstructie van verloren macroblokken (zonder FMO)...51 Figuur 23 : Stapsgewijze reconstructie van verloren macroblokken (FMO)...52 Figuur 24 : Kwaliteitsverlies door pakketverlies bij Stefan met GOP-structuur IP...54 Figuur 25 : Kwaliteitsverlies door pakketverlies bij Stefan met GOP-structuur IBBP...54 Figuur 26 : Kwaliteitsverlies door pakketverlies bij Table met GOP-structuur IP...55 Figuur 27 : Kwaliteitsverlies door pakketverlies bij Table met GOP-structuur IBBP...55 Figuur 28 : Detail verschil in PSNR bij stefan met en zonder FMO bij hoge kwaliteit met 5 procent verlies...56 Figuur 29 : Fragment uit Stefan zonder B-slices met hoge kwaliteit bij een verlies van 5%...56 Figuur 30 : Screenshot van het programma om interessegebieden de selecteren...57 vi

10 Lijst van tabellen Tabel 1 : De verschillende soorten slices en hun voorspellingsmodi...6 Tabel 2 : Overzicht van de verschillende soorten NAL-eenheden...7 Tabel 3 : Eigenschappen van de profielen in H.264/AVC...13 Tabel 4 : Bewegingsveranderlijken en -richtingen bij FMO type Tabel 5 : Voorbeeld van de opbouw van een slicegroepmap voor FMO type 3 (tegen wijzerzin)...42 Tabel 6 : Overzicht van FMO type 3, 4 en Tabel 7 : Overzicht van de wijzigende parameters bij de testen rond foutopvang met behulp van FMO...53 Tabel 8 : Overzicht van de wijzigende parameters bij de testen rond schaalbaarheid met behulp van FMO...58 Tabel 9 : Coördinaten voor de interessegebieden in stefan_cif.yuv...58 Tabel 10 : Wisselende bitsnelheden in kbps bij wijzigende quantisatieparameters van het interessegebied (GOP = IP, sliceargument = 50)...60 Tabel 11 : Wisselende bitsnelheden in kbps bij wijzigende quantisatieparameters van het interessegebied (GOP = IP, sliceargument = 1000)...60 Tabel 12 : Wisselende bitsnelheden in kbps bij wijzigende quantisatieparameters van het interessegebied (GOP = IBP, sliceargument = 50)...60 Tabel 13 : Wisselende bitsnelheden in kbps bij wijzigende quantisatieparameters van het interessegebied (GOP = IBP, sliceargument = 1000)...61 Tabel 14 : Vergelijking bitsnelheden bij FMO type met verschillende parameters (in %)...61 Tabel 15 : Overzicht van de wijzigende parameters bij kostenbepaling FMO...64 Tabel 16 : Overzicht van de interessegebieden bij stefan en table...64 Tabel 17 : Relatieve kost voor FMO type 2 bij enkele CIF sequenties (in %)...65 Tabel 18 : Relatieve kost voor FMO type 1 bij enkele CIF sequenties (in %)...67 Tabel 19 : Overzicht van de verschillende elementen in de verschillende partities...71 vii

11 Lijst van codefragmenten Codefragment 1 : Structuur van de JM7.3 decoder...19 Codefragment 2 : Basis van de nieuwe decoder...21 Codefragment 3 : De nieuwe decoder voor IDR en SLICE NAL-eenheden...23 Codefragment 4 : Encoderingsalgoritme voor H.264/AVC zonder FMO...28 Codefragment 5 : Encoderingsalgoritme voor H.264/AVC met FMO...29 Codefragment 6 : Decoderingsalgoritme voor H.264/AVC zonder FMO...30 Codefragment 7 : Decoderingsalgoritme voor H.264/AVC met FMO...31 Codefragment 8 : Syntax voor FMO in een picture parameter set...32 Codefragment 9 : Constructie van MBToSliceGroupMap uit mapunittoslicegroupmap...33 Codefragment 10 : FMO type 0 H.264/AVC-syntax...34 Codefragment 11 : Constructie van de slicegroepmap voor FMO type Codefragment 12 : Constructie van de slicegroepmap voor FMO type Codefragment 13 : FMO type 2 H.264/AVC-syntax...36 Codefragment 14 : Constructie van de slicegroepmap voor FMO type Codefragment 15 : FMO type 3, 4 en 5 H.264/AVC-syntax...38 Codefragment 16 : Het aantal bits nodig om de slice_group_change_cycle voor te stellen...38 Codefragment 17 : Grootte van de slicegroepen bij FMO types 3, 4 en Codefragment 18 : Constructie van de slicegroepmap voor FMO type Codefragment 19 : Constructie van de slicegroepmap voor FMO type Codefragment 20 : Constructie van de slicegroepmap voor FMO type Codefragment 21 : FMO type 6 H.264/AVC-syntax...45 Codefragment 22 : Constructie van de slicegroepmap voor FMO type Codefragment 23 : Overzicht van de veranderlijken voor FMO in de referentiesoftware...46 Codefragment 24 : Overzicht van de nieuwe structuur van slicegroepmappen...47 Codefragment 25 : Voorbeelden van de verschillende mogelijkheden voor de nieuwe structuur van slicegroepmappen...48 Codefragment 26: Quantisatieparameter voor het interessegebied bij FMO type Codefragment 27 : Formule en voorbeeld voor de opdeling van de ideale foutopvangende slicegroepmap...68 Codefragment 28: H.264/AVC syntax voor datapartitionering...71 viii

12 Hoofdstuk 1 Inleiding 1.1 Situering Sinds een aantal jaren zit digitale video duidelijk in de lift. Steeds opnieuw worden er toepassingen bedacht en ontwikkeld, gaande van videoconferentie tot digitale televisie. Een groot deel van deze toepassingen steunen op eenzelfde ruggegraat, het Internet. Aan de ene kant zijn er de eisen van de gebruiker die alles snel, goedkoop en aan een hoge kwaliteit wil, anderzijds zijn er de systemen die hun beperkingen hebben. Denk bijvoorbeeld maar aan de netwerkbandbreedte of de capaciteit van de opslagmedia. De enige mogelijkheid om beelden snel door te sturen bestaat er in om ze zo goed mogelijk te comprimeren. Maar compressie brengt ook gevaren met zich mee. Het Internet is een reusachtig netwerk waarop wel eens iets mis durft lopen en kostbare gecomprimeerde data durft dus wel eens verloren geraken onderweg. Het International Telecommunication Union, Telecommunication Standardization Sector (ITU-T) en het International Stadardization Organization/International Electrotechnical Commission (ISO/IEC) zijn twee organisaties die hun krachten gebundeld hebben voor de ontwikkeling van een nieuwe compressiestandaard. Deze nieuwe standaard, H.264/AVC, laat alle bestaande standaarden ver achter zich door de beelden tot 50% meer te comprimeren. Maar er is ook slecht nieuws, want bij betere compressie kan meer data ineens worden meegezonden en kan dus ook meer data verloren gaan als er iets misloopt tijdens het transport. 1

13 1.2 Doelstellingen De doelstellingen van dit eindwerk zijn om te kijken naar een aantal manieren waarop de nieuwe standaard probeert fouten op te vangen en tegen te gaan. Het is de bedoeling om voor beide delen ook een implementatie te maken op basis van de bestaande referentiesoftware. De verschillende technieken zullen aan de hand van experimenten worden beoordeeld op hun toepassingen en kosten in verschillende omgevingen. 1.3 Structuur De volgende paragrafen bevatten een kort overzicht van de verschillende delen van deze scriptie. Hoofdstuk 2 behandelt de grote lijnen van de nieuwe standaard. Naast een korte geschiedenis van de standaard, komt er eveneens een overzicht van de meest voorkomende termen in de standaard voor. Tot slot wordt op een redelijk abstract niveau omschreven hoe het coderingsproces verloopt. In hoofdstuk 3 wordt er nagegaan wat er zoal kan mislopen bij de transmissie van een gecodeerd beeld over een netwerk. Naast een theoretisch oplossing bevat het hoofdstuk ook een overzicht van een implementatie van een vereenvoudigde robuuste decoder. Hoofdstuk 4 gaat dieper in op één van de belangrijkste onderdelen in de standaard voor foutopvang, flexibele macroblok ordening. Naast een theoretisch overzicht van de verschillende delen komt ook een praktische implementatie van de H.264/AVC-encoder aan bod. Hoofdstuk 5 bespreekt een tweetal toepassingen van flexibele macroblok ordening. In een derde en laatste deel wordt er dieper ingegaan op de kosten van deze techniek. Alle delen zijn voorzien van een analyse van experimentele resultaten. In hoofdstuk 6 wordt een tweede techniek voor foutopvang besproken, datapartionering. Naast een omschrijving van wat de techniek inhoudt, worden de theoretische mogelijkheden tot reconstructie op een rijtje gezet. Deze scriptie wordt uiteindelijk afgesloten met een besluit. 2

14 Verder zijn er ook nog een drietal appendices in dit eindwerk opgenomen: Appendix A bevat een wiskundige analyse van een formule met betrekking tot flexibele macroblok ordening. Appendix B bevat een overzicht van de wijzigingen die aangebracht zijn in de encoder uit de referentiesoftware om flexibele macroblok ordening te implementeren. Appendix C tot slot bestaat uit een CD-ROM waarop, naast een nieuwe versie van de software, ook het cijfermateriaal met betrekking tot de verschillende experimenten is opgenomen. 3

15 Hoofdstuk 2 Overzicht van de H.264/AVC standaard 2.1 Ontstaan van de H.264/AVC standaard De geschiedenis van de videocompressietechnologie werd tot op heden altijd gedomineerd door twee groepen, namelijk de Moving Picture Experts Group (MPEG) en de Video Coding Experts Group (VCEG). Het MPEG-team is een onderdeel van het grotere ISO/IEC en bracht in het verleden verschillende standaarden uit onder de naam MPEG-x. Het VCEG-team, dat een tak vormt van de International Telecommunication Union Telecommunication Standardization Sector (ITU-T) brengt aanbevelingen (recommendations) uit. Afhankelijk van het onderwerp van die aanbevelingen krijgen deze een bepaalde prefix. Videocodering valt onder H.26x. Figuur 1 : ITU-T-aanbevelingen en ISO/IEC-standaarden In 1997 begon het VCEG-team met de ontwikkeling van de H.26L standaard. De basisbedoeling van de standaard was om een videocompressiealgoritme te ontwerpen voor 4

16 toepassingen die een lage bitsnelheid vereisen. De L in de benaming staat voor long-term. Het was namelijk de bedoeling om een zodanig goede standaard te ontwikkelen dat deze zich een hele tijd zou kunnen handhaven op het toneel van de videocompressie. Halfweg 2001 erkende de MPEG-groep de voordelen van H.26L en werd het Joint Video Team (JVT) op poten gezet. Na de oprichting van het JVT in december 2001, is begonnen met het ontwerpen van een Committee Draft die in februari 2002 openbaar gemaakt is. Tegen het einde van hetzelfde jaar ontstond de Final Draft International Standard (FDIS). De goedkeuring tot International Standard (IS) vond dan halfweg 2003 plaats [1]. Figuur 2 : Tijdlijn voor de ontwikkeling van H.264/AVC De standaard staat bekend onder de naam H.264 bij het ITU-T en als MPEG 4 part 10 (AVC) bij het ISO/IEC. 2.2 Enkele algemene begrippen Een videostroom bestaat uit een serie opeenvolgende beelden. Elk beeld wordt opgesplitst in kleine delen die gemakkelijker kunnen gecodeerd worden, de zogenaamde macroblokken. Elk van deze blokken is 16 op 16 pixels groot (Figuur 3). Meerdere macroblokken kunnen samengenomen worden tot een slice. Een beeld is dus opgebouwd uit slices. Binnenin elke slice zijn de macroblokken geordend volgens hun scan-order. Dat wil zeggen dat ze geordend zijn van links naar rechts en van boven naar onder. De standaard voorziet in vijf slicetypes: I, P, B, SI en SP. Het verschil zit hem in het type voorspelling en het aantal bewegingsvectoren dat toegestaan is bij dat type (Tabel 1). Bewegingsvectoren laten toe om het verschil in beweging te bekijken tussen twee beelden en temporele redundantie uit te buiten. 5

17 Figuur 3 : De verschillende delen van een beeld Wanneer een slice gecodeerd wordt, zijn de data onafhankelijk van de andere slices in hetzelfde beeld. Dit heeft als voordeel dat een slice los van andere slices binnen hetzelfde beeld verwerkt kan worden door de decoder. Tabel 1 : De verschillende soorten slices en hun voorspellingsmodi Type Voorspellingsmode (intra/inter) Maximaal aantal bewegingsvectoren I intra - P intra en inter 1 B intra en inter 2 SI intra - SP inter 1 H.264/AVC maakt gebruik van twee voorspellingstechnieken: intra en inter. Beiden kunnen op hun beurt nog eens opgedeeld worden in een aantal submodi. Bij intravoorspelling mag enkel gebruik worden gemaakt van macroblokken uit hetzelfde beeld die al gecodeerd zijn. De onafhankelijkheid van slices beperkt dit zelfs tot macroblokken uit dezelfde slice die al gecodeerd zijn. Bij intervoorspelling wordt er gebruikgemaakt van reeds vroeger gecodeerde beelden. De bedoeling is hierbij om de temporele redundantie uit te buiten. Bij P- macroblokken wordt enkel gebruikgemaakt van vroeger beelden. Bij B-macroblokken wordt gebruikgemaakt van een gewogen gemiddelde. 6

18 H.264/AVC maakt gebruik van een scalaire quantisatie om verschillende graden van compressie mogelijk te maken. Er zijn 52 mogelijk quantisatieparameters en, in tegenstelling tot vroegere compressiealgoritmes, kan elke macroblok zijn eigen parameters bezitten. Elke verhoging van de quantisatieparameter zorgt voor een 12,5% sterkere compressie. Alle gecodeerde data worden gegroepeerd in NAL-eenheden. NAL is een acroniem voor Network Abstract Layer. Er zijn 5 bits voorzien om het type NAL-eenheid weer te geven. Er kunnen dus maximaal 32 soorten NAL-eenheden zijn. Momenteel zijn enkel de types 1 tot en met 12 toegewezen zoals in Tabel 2. Tabel 2 : Overzicht van de verschillende soorten NAL-eenheden type inhoud type inhoud 1 niet-idr-slice 7 sequence parameter set 2 slice partitie A 8 picture parameter set 3 slice partitie B 9 access unit delimeter 4 slice partitie C 10 end of sequence 5 IDR-slice 11 end of stream 6 supplemental enhancement information 12 filler data In verband met de rest van dit afstudeerwerk zijn het voor de types 1 tot en met 5 en 7 en 8 die van belang zijn. De eerste vijf geven de manier aan waarop een slice gecodeerd is, hierbij vormen 2, 3 en 4 samen één slice die opgedeeld is in meerdere delen (zie Hoofdstuk 6 ). De types 7 en 8, respectievelijk de sequence parameter set (sps) en picture parameter set (pps), worden gebruikt om algemene informatie over een gecodeerde videosequentie door te geven. Beiden vormen het eerste deel van een bitstroom. Zonder deze kunnen de slices niet gedecodeerd worden. 2.3 Doelstellingen van de standaard en hun realisatie Bij de oprichten van het JVT werden een aantal doelstellingen op papier gezet waaraan de nieuwe standaard zou moeten voldoen. In de volgende subparagrafen worden de belangrijkste op een rij gezet samen met de oplossingen die de standaard voorziet [1] Bitsnelheid Zoals al vermeld is, was de belangrijkste doelstelling het omlaag krijgen van de bitsnelheid. Het doel was om een besparing van minstens 50% te bereiken tegenover vroeger 7

19 videocompressiealgoritmes. Figuur 4 [2] geeft de codering weer van dezelfde sequentie met dezelfde kwaliteit door de verschillende encoders. De enige verbetering in de bestaande technieken moeten gezocht worden in betere hardware, niet in de specificaties. Figuur 4: Bitsnelheden in MBit/s voor de verschillende standaarden De betere compressie in H.264/AVC wordt bereikt doordat de quantisatieparameters voor elke macroblok apart gekozen kunnen worden. Afhankelijk van zijn structuur kan voor elk blok de beste compressie bepaald worden. Zo kan een macroblok waarin elke pixel dezelfde kleur heeft met hoge parameter (bijvoorbeeld 50) gecodeerd worden omdat er toch geen groot verlies zal zijn in kwaliteit. Blokken met veel verschillende pixels kunnen dan weer beter met een lage parameter gecodeerd worden. Het algoritme kan verschillende waarden uitproberen om zo zelf de beste te vinden. Dit is natuurlijk wel erg rekenintensief. Een tweede middel dat zorgt voor de buitengewoon lage bitsnelheden is het voorspellingsmechanisme dat met meerdere referentiebeelden kan werken om zo de beste overeenkomst te vinden Netwerkvriendelijkheid Een andere doelstelling was om het transport over netwerken zo eenvoudig mogelijk te houden. Daartoe is ten eerste een nieuw lagenconcept ingevoerd in H.264/AVC. De standaard is opgesplitst in twee lagen : een Video Coding Layer (VCL) en een Network Abstraction 8

20 Layer (NAL) (Figuur 5). Beide lagen communiceren met elkaar aan de hand van NALeenheden. Er zijn twee soorten netwerken : pakketgebaseerde en bytestroomgebaseerde. Bij deze laatste wordt er nog een extra prefix toegevoegd aan de NAL-eenheid om de grens te kunnen onderscheiden tussen twee opeenvolgende NAL-eenheden in een bytestroom. Voor de rest doet de netwerkabstractielaag dienst als een soort proxy (Figuur 5). De laag zorgt er voor dat de bitstroom op een goede manier opgesplitst wordt om over het netwerk verzonden te worden. Hierbij wordt rekening gehouden met het vooropgestelde transferprotocol. Figuur 5 : Het H.264/AVC lagenmodel Een tweede punt waarbij aan netwerkvriendelijkheid gedacht is, is een systeem van prioriteiten. Elk geëncodeerd element krijgt een bepaalde prioriteit tussen 1 en 5 toegewezen. Hoe kleiner de prioriteit, hoe belangrijker de data. Wanneer er onvoldoende bandbreedte op het netwerk beschikbaar is, kan de zender besluiten om pakketten met een bepaalde prioriteit weg te laten. Zo is het bijvoorbeeld mogelijk om scene-informatie mee te geven in de bitstroom die geen enkel belang heeft op de manier van encoderen van het beeld waartoe de informatie behoort. De informatie kan interessant zijn voor de gebruiker maar als ze weg valt is het geen groot verlies Foutrobuustheid Meer en meer wordt er door consumenten gevraagd naar videostromen over een netwerk. Denken we maar aan bijvoorbeeld video-on-demand, videoconferenties, En hoewel netwerken hoe langer, hoe foutbestendiger worden, blijven er nog steeds fouten optreden tijdens het transport. Bovendien betekent de verhoogde compressie van de data in H.264/AVC dat er bij pakketverlies meer informatie verloren gaat dan bij vroegere specificaties. Daarom zijn een aantal mechanismen voorzien om de invloed van fouten zo beperkt mogelijk te 9

21 houden. De twee belangrijkste systemen zijn flexibele macroblok ordening en datapartitionering. Beiden worden later uitgebreid besproken Flexibele vertragingsmechanismen bij codering In videoconferentietoepassingen moet alles zo snel mogelijk gebeuren. Er kan en mag meestal niet gewacht worden op volgende beelden. Wanneer er wel gewacht kan worden, kan er gebruikgemaakt worden van bijvoorbeeld B-macroblokken. Door hun gewogen voorspelling kunnen zij vaak een betere compressie opleveren. De compressie hangt dus vaak af van de snelheid waarmee gecodeerd moet worden Eenvoud Een laatste belangrijke doelstelling voor de ontwerpers was het eenvoudig houden van de standaard. In het verleden is te vaak de fout gemaakt om tientallen uitzonderingsgevallen toe te voegen die het geheel onoverzichtelijk maakten. In H.264/AVC is het algoritme opgebouwd uit een aantal functionele blokken die aan elkaar gekoppeld worden. Dit laat toe om in de toekomst eventueel één van de blokken te vervangen door een beter systeem. 2.4 Het coderingsproces Net zoals bij vorige standaarden en aanbevelingen is ook bij H.264/AVC enkel de syntax van de bitstroom en de decoder gestandardiseerd en dit om verschillende redenen. Dat laat toe om encoders met een beperkte complexiteit te ontwerpen. Deze moeten niet alles ondersteunen, ze moeten enkel een geldige bitstroom genereren. Het laat bovendien ook toe om verdere optimalisaties door te voeren (cfr. MPEG-2) Encoder De encoder in Figuur 6[3] vertrekt vanuit een beeld F n. Allereerst wordt het beeld opgesplitst in macroblokken van 16 op 16 pixels. Deze macroblokken worden stuk voor stuk behandeld. Voor elke macroblok wordt een voorspeld macroblok P berekend. Deze P ontstaat door intra- of intercodering van het originele macroblok. In beide gevallen wordt gebruikgemaakt van vroeger gecodeerde macroblokken. Het verschil tussen beide modi is dat bij intravoorspelling enkel in het huidige beeld (F n ) wordt gekeken, terwijl bij intervoorspelling gekeken wordt in vroeger gecodeerde referentiebeelden (F n-1) en bewegingscompensatie (MC) gebruikt wordt. Vervolgens wordt een derde macroblok D n 10

22 geconstrueerd dat het verschil vormt tussen het originele macroblok en P. Dit resultaat wordt dan op zijn beurt getransformeerd (T) en gequantiseerd (Q) om tot een groep coëfficiënten (X) te komen. Het zijn deze coëfficiënten, samen met de gegevens over hoe ze bepaald zijn (voorspellingsmode, bewegingsvectoren, quantisatieparameter, ), die uiteindelijk worden toegevoegd aan de bitstroom via entropiecodering. De resulterende NAL-eenheid op het einde van het encoderingsproces bevat meestal een volledige slice en dus meerdere gecodeerde macroblokken. Eén stuk is in het bovenstaande algoritme achterwege gebleven, namelijk de bepaling van de referentiebeelden (F n-1) die gebruikt worden bij intervoorspelling. Deze beelden worden bepaald aan de hand van een decoderoperatie op de bekomen geëncodeerde data (X). Er wordt gebruikgemaakt van gedecodeerde beelden als referentiebeelden omdat de decoder enkel over deze beelden zal beschikken. De quantisatie zorgt er voor dat de gedecodeerde beelden niet dezelfde zijn als de originele beelden. Als de originele beelden zouden gebruikt worden door de encoder zouden de encoder en decoder over verschillende referentiebeelden beschikken. Dit zou drift, het evolueren van fouten over verschillende beelden heen,veroorzaken wanneer de bitstroom gedecodeerd zou worden. Het gebruik van intra-codering beperkt drift doordat er geen gebruik moet worden gemaakt van andere beelden. Figuur 6 : Schematische voorstelling van de H.264/AVC-encoder Decoder Zoals in Figuur 7[3] wordt weergegeven, aanvaart de H.264/AVC decoder-naleenheden als invoer. Na het uitvoeren van de entropiedecodering krijgen we terug de getransformeerde en gequantiseerde groep coëfficiënten (X). Op deze data worden de inverse 11

23 van de quantisatie en de transformatie uitgevoerd zodat we een nieuwe macroblok krijgen (D n). De rest van de data die meegecodeerd werd kan gebruikt worden om een exacte reconstructie te doen van P uit de referentiebeelden (F n-1). Door P en D n samen te nemen krijgen we het originele macroblok terug. Nadat de macroblokken behandeld zijn met een antiblok-filter om het blokeffect, dat langs de randen ontstaat, tegen te gaan, worden ze samengevoegd om het beeld F n te construeren. Dit beeld kan op zijn beurt gebruikt worden als referentiebeeld voor volgende beelden die gereconstrueerd worden. Figuur 7 : Schematische voorstelling van de H.264/AVC-decoder Dat verklaart waarom het tweede deel van de encoder bestaat uit een decoderoperatie. Dit garandeert namelijk dat encoder en decoder beschikken over dezelfde referentiebeelden waaruit ze P bepalen. 2.5 Profielen en levels Net zoals bij vorige standaarden is ook H.264/AVC ontwikkeld voor verschillende soorten toepassingen die elk hun eigen eisen stellen. Twee belangrijke termen in dit verband zijn profiel en level. Een profiel is een verzameling van algoritmes die een deelverzameling vormen van alle algoritmes die in de standaard opgenomen zijn. Toepassingen steunen op een bepaald profiel en mogen enkel de algoritmes en technieken uit dat profiel gebruiken. Een level is een verzameling van beperkingen die doorgevoerd worden op de waarden van een bepaald profiel. Tot nu toe zijn er 3 profielen en 14 levels gedefinieerd voor H.264/AVC. De 14 levels dienen om alle populaire formaten te ondersteunen, gaande van QCIF (176 op 144 pixels) tot D-Cinema (1920 op 1200 pixels). 12

24 In de volgende paragrafen wordt een overzicht gegeven van de verschillen tussen de profielen en hun belangrijkste toepassingen Eigenschappen van de H.264/AVC-profielen en hun betekenis De drie profielen zijn Baseline, Main en Extended. In Tabel 1 wordt een overzicht gegeven van hun belangrijkste eigenschappen. Uit de tabel valt gemakkelijk af te leiden dat het Extended-profiel een uitgebreide versie is van het Baseline-profiel. Tabel 3 : Eigenschappen van de profielen in H.264/AVC Baseline Main Extended I-slices x x x P-slices x x x B-slices x x SP- en SI-slices x UVLC/CAVLC encodering x x x CABAC encodering x Flexibele macroblok ordening x x Willekeurige volgorde van slices x x Redundante slices x x Datapartionering x Gewogen voorspelling x x Interlace x x B-slices laten meer voorspellingsmodes toe en leveren dus vaak een betere voorspelling voor een macroblok. Anderzijds hebben ze het nadeel dat het volgende beeld gekend moet zijn alvorens er tot de codering kan overgegaan worden. CABAC encodering is een efficiëntere encodering dan UVLC/CAVLC maar vereist wel een stuk meer rekenkracht. Flexibele macroblok ordening: zie verder Willekeurige volgorde van slices zorgt er voor dat de decoder steeds kan verderwerken en niet moet zitten wachten tot een bepaalde slice toekomt. Dit is vooral handig wanneer de datastroom ontvangen wordt via een netwerkwerkverbinding. Redundante slices zorgen ervoor dat dezelfde slices meer dan eens aan de decoder bezorgd worden. Dit is vooral handig bij het verzenden van de bitstroom over netwerken waar veel fouten optreden. Datapartitionering zorgt er voor dat de gegevens over de codering van macroblokken opgesplitst worden over verschillende NAL-eenheden afhankelijk van het belang van de data. 13

25 Gewogen voorspelling zorgt voor een betere codering bij een aantal speciale effecten zoals het veelvuldig veranderen van de luchtkleur, het vervagen van een beeld, Toepassingen van de H.264/AVC-profielen Baseline: ware-tijdstoepassingen waar zo weinig mogelijk vertraging mag optreden: o videoconferentie o draadloze toepassingen Main: broadcasting toepassingen via kabel, DSL of satteliet, vooral op het gebied van entertainment: o DVD o video-on-demand o multimediaservices Extended: een uitbreiding van het Baseline profiel, vooral voor toepassingen die niet draadloos zijn 14

26 Hoofdstuk 3 Een foutrobuuste decoder 3.1 Inleiding Hoewel dit werk zich concentreert op mechanismen voor foutopvang aan de kant van de encoder, onder het motto het is beter te voorkomen dan te genezen, is het van belang te beschikken over een decoder die in staat is om beschadigde bitstromen te verwerken. Het is namelijk de enige manier om een weergave te krijgen van de resultaten van de technieken voor foutopvang die toegepast zijn door de encoder. Visuele vergelijking mag dan wel onnauwkeurig zijn, uiteindelijk zal het toch dat zijn wat de doorslag geeft in toepassingen van de H.264/AVC-standaard. 3.2 Een model voor het versturen van bitstromen Wanneer een bitstroom over een netwerk verzonden wordt, kunnen er verschillende fouten optreden. Hoewel de standaard enkel voorziet in het decoderen van correcte bitstromen moet een goede decoder elke mogelijke fout kunnen opvangen. Het aantal mogelijke fouten kan echter vereenvoudigd worden door een aantal keuzes te maken over de manier waarop de bitstroom getransporteerd wordt. Allereerst wordt er een onderscheid gemaakt tussen gegevens die verloren mogen gaan en gegevens die dat zeker niet mogen. In dit werk wordt er van uitgegaan dat alle data die betrekking hebben op meerdere beelden over een veilige verbinding, bijvoorbeeld een TCPverbinding, verzonden worden. Enkel delen van een beeld, de zogenaamde slices, mogen verloren gaan. 15

27 Doordat het aantal macroblokken dat in een slice verwerkt wordt niet constant is, is het mogelijk om NAL-eenheden die slice-informatie bevatten, en over een verlieslatende verbinding verzonden worden, zo klein te maken dat ze tijdens het transport over het netwerk niet meer opgesplitst worden. Dit garandeert dat enkel volledige NAL-eenheden verloren gaan en er geen belang moet gehecht worden aan delen van een NAL-eenheid die verloren gaan. 3.3 De verschillende soorten fouten in bitstromen en hun opvang Vertrekkende van de eigenschappen die in de vorige paragraaf besproken werden, kunnen we de fouten die ontstaan tijdens transport over een netwerk opdelen in twee categorieën: een NAL-eenheid gaat verloren (Figuur 8b) een NAL-eenheid komt te vroeg of te laat toe (Figuur 8c) Hierbij stel F : x het nummer van het beeld (frame) voor en S : x het nummer van de slice. SPS en PPS staan dan respectievelijk voor sequence paramater set en picture parameter set. Figuur 8 : Bitstromen - (a) zonder fouten - (b) een ontbrekende NAL-eenheid - (c) een te vroege NALeenheid Maar wanneer is een NAL-eenheid feitelijk verloren? Zolang er nog nieuwe data ontvangen worden, kan er namelijk niet uitgesloten worden dat de NAL-eenheid in de toekomst niet ontvangen zal worden. Tijdens de decodering van een beeld kan er in het geval van intervoorspelling nood zijn aan informatie van een ander beeld. Indien een NAL-eenheid niet op tijd toekomt moet er dus gewacht worden met de decodering van volgende beelden. De enige correcte oplossing is om alle ontvangen NAL-eenheden in een buffer te plaatsen tot de juiste NAL-eenheid ontvangen wordt en er verder kan gegaan worden met het decoderen van het beeld. Dit betekent dat er 16

28 eerst en vooral een extra buffer zou nodig zijn voor tijdelijk opslag. Een ander gevolg is dat het decoderingsproces stil valt in afwachting van de correcte NAL-eenheid. Vooral het tijdelijk stilleggen van het decoderingsproces is geen goede zaak. Software voor videoconferenties en dergelijke rekent nu eenmaal op een continue stroom van data. Het Baseline en Extended profiel (zie ook Tabel 3) bieden een betere oplossing: willekeurige volgorde van slices. Dit laat toe dat de verschillende slices binnen een beeld in een willekeurige volgorde ontvangen worden door de decoder. Doordat elke slice een apart geheel vormt, los van de overige slices van een beeld, kan de slice zonder problemen gedecodeerd worden. Toch levert ook deze oplossing geen volledige voldoening op. Zolang niet alle slices van een beeld ontvangen zijn kan het beeld niet gebruikt worden als referentie. Met andere woorden, als slices van een volgend beeld toekomen zal de decoder toch weer opnieuw moeten wachten. De volgende oplossing is enkel vanuit theoretische hoek benaderd. Gebrek aan tijd en de verwarrende opbouw van de referentiesoftware lieten niet toe om dit ook praktisch uit te werken. Hoewel beelden vaak in ware tijd moeten weergegeven worden, denken we maar aan bijvoorbeeld videoconferenties, gebruiken veel toepassingen intern een buffer die een aantal beelden bevat. In plaats van de buffer op beeld-niveau te plaatsen kan deze op NAL-niveau geplaatst worden. De decoder zou dan een kleine buffer met NAL-eenheden bevatten waaruit telkens de beste NAL-eenheid gekozen wordt om als volgende te verwerken. De redenering achter dit idee is dat wanneer een NAL-eenheid te laat toekomt er meestal maar een beperkt aantal andere NAL-eenheden de gezochte eenheid voorbijsteken. Een NAL-eenheid zou dan als verloren gemarkeerd kunnen worden als de buffer vol is en de decoder die correcte NALeenheid niet kan vinden. Het voordeel van deze techniek is dat de decoder onderweg niet moet wachten op een NAL-eenheid. Enkel in het begin, wanneer de buffer opgevuld wordt, zou er een kleine vertraging zijn. 3.4 Reconstructie van verloren macroblokken Detectie van fouten is één iets, er iets aan doen is totaal iets anders. Afhankelijk van het type pakketverlies kan het verlies variëren van enkele macroblokken tot een volledig beeld. De eenvoudigste manier om fouten op te vangen is door spatiale interpolatie. Bij deze techniek wordt gebruikgemaakt van de buren van een macroblok in hetzelfde beeld. Als de macroblokken aan de rand van het beeld even buiten beschouwing gelaten worden, beschikt 17

29 elk macroblok over acht buren (Figuur 9a). Elk van de rondliggende macroblokken krijgt een waarde toegewezen die aangeeft of het macroblok correct is, verloren en nog niet geconstrueerd is of verloren en geconstrueerd is. Enkel de correct gedecodeerde en de gereconstrueerde macroblokken kunnen gebruikt worden bij het bepalen van het ontbrekende macroblok. Als interpolatie kan het gewogen gemiddelde van de beschikbare blokken genomen worden waarbij de correct ontvangen macroblokken een groter belang hebben dan de gereconstrueerde. Figuur 9 : Spatiale (a) en temporele (b & c) reconstuctie Elke macroblok bestaat uit 16 op 16 pixels. Wanneer we gebruik maken van de rondomliggende macroblokken is het mogelijk om de randen van het gezochte macroblok vrij correct te benaderen met zo n interpolatie. Het midden van de macroblok levert echter een probleem op. Daar kan enkel gewerkt worden met de rondomliggende pixels en die zijn op hun beurt al allemaal gecorrigeerde pixels. Een tweede, eveneens eenvoudige manier, wordt weergegeven in Figuur 9b. Hierbij wordt de data van het beeld dat vóór het huidige beeld komt, gekopieerd naar de verloren macroblokken. Wanneer een zeer groot aantal macroblokken binnen eenzelfde beeld verloren is, kan het beeld volledige vervangen worden door het vorige beeld. Het wissen van correcte data kan interessant zijn wanneer er bijvoorbeeld een scenewisseling optreedt tussen het vorige en het huidige beeld. Het gedeeltelijk kopiëren zou in dat geval een raar effect geven. Een laaste methode maakt gebruikt van temporele interpolatie. Dit algoritme maakt gebruik van één of meerdere referentiebeelden [4]. Het aantal referentiebeelden is vaak gelimiteerd door de buffer van de decoder of een tussenliggend I-beeld dat op een scenewisseling kan duiden. Elke pixel wordt apart bepaald. Voor een pixel (x,y) wordt allereerst een geschiedenis van bewegingsvectoren gegenereerd. Dit gebeurt door de bewegingsvectoren van de pixel (x n-1,y n-1 ) enerzijds bij te houden en anderzijds aan de hand van deze verder af te dalen in de lijst met referentiebeelden naar een pixel (x n-2,y n-2 ). Dit 18

30 proces kan dan herhaald worden voor de rest van de referentiebeelden. Uit al deze bewegingsvectoren wordt een nieuwe bewegingsvector gegenereerd. Dit kan op verschillende manieren gebeuren: gewogen gemiddelde, mediaan, De bekomen bewegingsvector wordt gebruikt om een pixel (p n-1,q n-1 ) in het meest recente referentiebeeld te vinden. Het is deze pixel die gekopieerd wordt naar (x,y). Het is duidelijk dat deze methode de beste resultaten zal geven. In tegenstelling tot de eerste methode hebben de pixels uit het centrum van de macroblok geen last van niet-gekende buren. Het nadeel van deze methode is dat ze zeer rekenintensief is. 3.5 De originele referentiedecoder De orginele JM7.3 decoder werkt met behulp van het aantal reeds gedecodeerde macroblokken om te bepalen of er een nieuw beeld gedecodeerd wordt of niet. Codefragment 1 geeft dit algoritme weer in pseudocode. aantal_gedecodeerde_mbs = 0; while (aantal_gedecodeerde_mbs!= aantal_mbs_in_een_beeld) decodeer_de_volgende_slice(); update(aantal_gedecodeerde_mbs) Codefragment 1 : Structuur van de JM7.3 decoder Zolang er met correcte bitstromen gewerkt wordt, is er niet echt een probleem. Het algoritme bevat echter verschillende zwakke punten wanneer we met bitstromen met fouten werken. De volgende voorbeelden maken gebruik van een standaard QCIF-beeld. Dit is een beeld dat bestaat uit 11 maal 9 macroblokken. Zoals in Figuur 10(a) te zien is, wordt elk beeld, herkenbaar aan F: x, opgesplitst in vier slices met maximal 25 macroblokken per slice. Dit betekent dat de laatste slice slechts 24 macroblokken zal tellen (11 * 9 modulo 25). De bitstroom begint zoals bij elke correcte bitstroom met een sequence parameter set (sps) en een picture parameter set (pps). Wanneer twee slices binnen eenzelfde beeld in omgekeerde volgorde toekomen, zoals in Figuur 10(b), heeft de decoder geen probleem want na vier slices is uiteindelijk precies één frame gedecodeerd. Wanneer het geval uit Figuur 10(c) optreedt is er wel een probleem: het aantal gedecodeerde macroblokken gaat van 0 naar 25 naar 50 naar 75 naar 100. Het geval van 99 19

31 gedecodeerde macroblokken, namelijk één beeld, komt dus niet voor. Daardoor zal de while voorwaarde van de lus niet vervuld worden. Bovendien zou de decodering van de laatste 25 macroblokken voor problemen zorgen. In het beste geval overschrijft de decoder de correcte macroblokken. In het ergste geval probeert de decoder via intervoorspelling op een niet bestaand beeld een decodering te doen. Het geval uit Figuur 10(d), waarbij effectief een NAL-eenheid verloren gaat, levert gelijkaardige problemen op. Figuur 10: Bitstromen met fouten - (a) zonder fouten - (b) 2 slices gewisseld in frame 0 - (c) 2 slices gewisseld tussen frame 0 en 1 - (d) een verloren slice voor frame De nieuwe foutrobuuste decoder De nieuwe decoder is op zó een manier ontwikkeld dat er zoveel mogelijk gebruikgemaakt wordt van de functionaliteit van de oude decoder. Terwijl de referentiedecoder alle mogelijke types van NAL-eenheden ondersteunt, was het bij de nieuwe decoder enkel de bedoeling om een goede basis te vormen van waaruit verder kan gebouwd worden om alle gevallen te ondersteunen. Daarom is er gekozen om de functionaliteit op te splitsen in een algemeen deel en aparte functies voor elk van de types NAL-eenheden (zie Codefragment 2). Op dit moment is, naast de verwerking van de sequence parameter sets en picture parameter sets, enkel de verwerking van SLICE en IDR type NAL-eenheden geïmplementeerd. Een mooie uitbreiding zou zijn om ook het deel voor datapartitionering, namelijk types 2 tot 4, te implementeren. 20

32 while (!end_of_bitstream) read_next_nalu(&nalu); switch (nalu->nal_unit_type) case NALU_TYPE_SLICE: case NALU_TYPE_IDR: ProcessIDR_SLICE2( ) case NALU_TYPE_SPS: ProcessSPS( ) Codefragment 2 : Basis van de nieuwe decoder Omdat de volgorde waarin de slices bij de decoder toekomen niet vast ligt, moet er gebruikgemaakt worden van een systeem om te bepalen tot welk beeld een slice behoort. Elk beeld bevat een uniek nummer, namelijk zijn picture order count of kortweg POC. Dit nummer bepaalt in welke volgorde de gedecodeerde beelden worden weergegeven. Voor een uitleg over de berekening van de POC van een beeld zie [5]. In geval van een NAL-eenheid van het type IDR of SLICE, bevat het eerste deel van de slice, de header, voldoende informatie om de POC te bepalen. De nieuwe decoder berekent eerst de POC voor de slice en aan de hand van dat resultaat wordt bepaald wat er moet gebeuren. Er zijn 4 mogelijkheden: De POC is dezelfde als deze van de voorgaande slice. In dat geval kan de decoder gewoon verder doen met zijn werk. De POC is niet gelijk aan deze van de voorgaande slice: o De slice behoort toe aan één van de beelden die nog in het geheugen opgeslagen zitten. In dit geval is het reconstrueren van het beeld aan te raden. Volgende beelden zouden namelijk gebruik kunnen maken van het beeld voor hun intervoorspelling. En het is nu eenmaal beter als ze over een correcte versie beschikken. o De slice behoort toe aan een beeld dat zo oud is dat het al niet meer in het geheugen zit, reconstrueren van het beeld is hier af te raden, tenzij het resultaat naar een harde schijf of zo wordt weggeschreven in plaats van onmiddellijk te worden weergegeven. o De slice behoort toe aan een beeld dat nog niet begonnen is. Het huidige beeld moet afgewerkt worden en een nieuw beeld moet geïnitialiseerd worden. Bij het afwerken van een beeld moet er rekening mee gehouden worden dat een beeld niet altijd volledig is. De logische benadering die gevolgd wordt bij de nieuwe decoder is dat 21

33 ontbrekende macroblokken met behulp van interpolatie van de rondomliggende data gereconstrueerd worden. Voor de eenvoud is momenteel enkel interpolatie binnen hetzelfde beeld mogelijk. De uitbreiding naar interpolatie vanuit andere beelden, dus niet enkel in de ruimte maar ook doorheen de tijd, zou op een eenvoudige wijze moeten toe te voegen zijn aan de decoder. Het is van belang dat alle ontbrekende macroblokken bepaald worden via een goede interpolatiemethode. Het kan namelijk best zijn dat de volgende slice die verwerkt wordt tot een beeld behoort dat gebruikmaakt van intervoorspelling op zijn voorgangers en dus nood heeft aan de data uit het zojuist afgewerkte beeld. Dankzij de interpolatie zou de decodering toch met iets nauwkeuriger waarden moeten kunnen werken. Wanneer een slice uiteindelijk toch nog toekomt kan deze dan nog altijd toegevoegd worden aan het beeld en dus de gereconstrueerde macroblokken vervangen door de correcte. De andere gedecodeerde slices die gebruikgemaakt hebben van het geinterpoleerde deel worden dan wel niet meer hersteld. De manier van opslag in de referentiesoftware leent zich echter niet tot het ophalen van een beeld uit de buffer om dan de decodering voort te zetten zonder heel wat omwegen te maken. Op dit moment verwijdert de nieuwe decoder alle slices die te laat toekomen. Er wordt wel een waarschuwing weergegeven of het over een slice gaat die nog gebruikt zou kunnen worden of over een slice die beter kan verwijderd worden. Ook het gebruik van een buffer met NAL-eenheden is niet voorzien. In het geval dat een nieuwe decoder vanaf nul geïmplementeerd zou worden zou overwogen moeten worden om de bovenstaande mogelijkheden te voorzien. Codefragment 3 tot slot geeft een schematisch overzicht van de nieuwe decoder voor IDR en SLICE NAL-eenheden. 22

34 while (haal_volgende_slice_op()) bepaal_poc_slice(&poc_huidige_slice); if (POC_huidige_slice!= POC_van_de_vorige_slice) for each(beeld_in_de_buffer) if (beeld_in_buffer[i]_poc == huidige_poc) return; // reconstructie theoretisch mogelijk POC_beeld_met_kleinste_POC_in_buffer(&kleinste_POC); if (POC_huidige_slice < kleinste_poc) return; // te oude slice, reconstructie is zinloos reconstrueer_de_gemiste_macroblokken(); sla_het_huidige_beeld_op(); start_een_nieuw_beeld_op(); decoder_een_slice(); reconstrueer_de_gemiste_macroblokken(); sla_het_huidige_beeld_op(); Codefragment 3 : De nieuwe decoder voor IDR en SLICE NAL-eenheden 3.7 Software voor het maken van fouten Elk programma dat ontwikkeld wordt, moet ook getest kunnen worden om te garanderen dat het correct werkt. De ontwikkeling van een foutrobuuste decoder gaat dus hand in hand met de ontwikkeling van een aantal toepassingen die in staat zijn om correcte bitstromen te beschadigen. De programma s die in de volgende paragrafen aan bod komen, werden in het kader van deze thesis geschreven in C# en werken via de commando lijn. Al deze programma s zijn, met hun broncode, eveneens opgenomen op de CD NALURemover Dit programma verwijdert NAL-eenheden uit een Annex B gecodeerde bitstroom. Het programma doet dit door de NAL-eenheden één voor één in te lezen en te controleren of de NAL-eenheid moet bewaard worden of niet. Indien deze bewaard moet worden, wordt de NAL-eenheid uitgeschreven naar de nieuwe beschadigde stroom. Het programma werkt als volgt: NALURemover <input> <output> <list of nalus to remove> met <input> : de correcte bitstroom. <output> : de beschadigde resulterende bitstroom. 23

35 <list of nalus to remove> : een 0-gebaseerde rij van getallen die aangeven welk NAL-eenheden er gewist mogen worden. Ze worden gescheiden door spaties NALUReplacer Dit programma laat toe om de willekeurige volgorde waarin slices toekomen te testen. Het laat namelijk toe om een bepaalde NAL-eenheid op een andere plaats te zetten in de gecodeerde stroom en zo het te laat toekomen bij de decoder van de NAL-eenheid te simuleren. Het programma werkt als volgt: NALUReplacer <input> <output> <old position> <new position> met <input> : de correcte bitstroom. <output> : de gewijzigde resulterende bitstroom. <old position> : de positie van de NAL-eenheid die verplaatst moet worden. <new position> : de positie waar de NAL-eenheid moet komen NALURemover2 NALURemover2 is een uitbreiding van NALURemover. In deze versie wordt gewerkt met een apart bestand dat enkel nullen en énen bevat. Ook nu weer worden de NAL-eenheden één voor één ingelezen. Er gebeuren echter twee controles die beslissen of een NAL-eenheid verwijderd wordt of niet. Allereerst wordt er gekeken naar het type van de NAL-eenheid. Enkel als het niet om een picture parameter set of sequence parameter set gaat kunnen de data verwijderd worden en wordt er overgegaan naar de tweede controle. Deze zorgt er voor dat de NAL-eenheid enkel verwijderd wordt uit de bitstroom als de index in het aparte bestand naar een één wijst. Het programma werkt als volgt: NALURemover2.exe <inputstream> <outputstream> <probabilityfile> met <inputstream> : de correcte bitstroom. <outputstream> : de beschadigde resulterende bitstroom. <probabilityfile> : het bestand met enkel nullen en énen. 24

36 Hoofdstuk 4 Flexibele macroblok ordening 4.1 Inleiding Dit hoofdstuk bevat een grondige studie van flexibele macroblok ordening. Omdat dit werk ook als naslagwerk bruikbaar zou zijn, zijn alle mogelijke algoritmes in de vorm van codefragmenten toegevoegd. Deze maken de tekst eerder aan de droge kant. Naast de codefragmenten is vooral gebruik gemaakt van figuren om de verschillende principes beter uit te leggen. Personen die enkel een algemeen beeld van flexibele macroblok ordening willen krijgen en geen interesse hebben in alle details, kunnen zich beperken tot de figuren. De codefragmenten kunnen ze dan links laten liggen. 4.2 Wat is flexibele macroblok ordening Flexibele macroblok ordening, kortweg FMO, maakt gebruik van de nieuwe slicestructuur in H.264/AVC. In Figuur 11 worden twee slices afgebeeld, één die het normale gebruik van slices met opeenvolgende macroblokken demonstreert en één die het gebruik van FMO demonstreert. Bij deze met FMO zijn de macroblokken genummerd volgens hun voorkomen in de slice. Net zoals bij een slice met aaneengesloten macroblokken worden ook hier de macroblokken in scan-order, en dus volgens hun nummering, gecodeerd in de slice. 25

37 4.3 Geschiedenis van FMO Figuur 11: Mogelijke slices in een beeld met FMO FMO is een nieuw concept in H.264/AVC en is ontstaan onder invloed van een aantal bestaande technieken en nieuwe voorstellen. Begin 2002 stelden S. Wenger en M. Horowitz voor scattered slices te voorzien in de nieuwe standaard [6]. Hierbij werd uitgegaan van ofwel een vaste functie die zowel bij de encoder als decoder gekend was en die de macroblokken volgens een bepaald patroon toevoegde aan de verschillende slices, ofwel een expliciete definïering tot welke slice elke macroblok behoorde. Volgens hen zou de functie vooral interessant zijn bij het versturen van gecodeerde beelden over netwerken die meer dan 3% pakketverlies hadden. De gebruiker zou zelf moeten bepalen hoeveel slices er gebruikt zouden worden. In H.263+ Annex K werden gestructureerde slices gedefinieerd die toelieten om een beeld op te delen in een rechthoekig deel, de zogenaamde region of interest, en de rest van het beeld. Beide delen zouden dan in een aparte slice gestopt worden. In mei 2002 stelt Peter Borgwardt voor om een gelijkaardige functionaliteit toe te voegen aan H.264/AVC [7]. Hij stelt voor om slices zodanig te ontwerpen dat het mogelijk wordt om een beeld op te splitsen in een stel rechthoeken die elk in een aparte slice zitten. Kort daarop stellen S. Wenger en M. Horowitz voor om FMO toe te voegen aan de standaard [8]. In de daarop volgende maanden wordt er gediscussieerd over de plaats van 26

38 flexibele macroblok ordening binnen de verschillende profielen. Uiteindelijk wordt beslist om FMO enkel toe te laten in het Baseline en Extended profiel. 4.4 Wijzigingen in de codering FMO kan niet zomaar toegevoegd worden aan de standaard. Er zijn verschillende wijzigingen nodig bij zowel de encoder als decoder Slicegroepen en de slicegroepmap Wanneer we terugvallen op de al vroeger gedefinieerde structuur van een beeld krijgen we een structuur zoals omschreven in Figuur 12a. Bij FMO wordt de indeling gewijzigd. Zoals in Figuur 12b te zien is wordt een beeld opgesplitst in een aantal slicegroepen die elk één of meer slices bevatten. Figuur 12 : Indeling van een beeld met (b) en zonder (a) slicegroepen Waneer een beeld slechts één slicegroep bevat krijgen we een gelijkaardig scenario als het geval zonder slicegroepen. Van zodra er meer dan één slicegroep is er sprake van FMO. Om de complexiteit beperkt te houden en de kosten te drukken, wordt het aantal slicegroepen beperkt tot acht. Dit is logisch want elke slicegroep moet minstens over één slice beschikken die elk over een header beschikken. Meer slices betekent dus meer kosten. Zowel de encoder als de decoder gebruiken een slicegroepmap om de verschillende slicegroepen voor te stellen. Elke macroblok uit een beeld komt overeen met één element in de slicegroepmap. Alle elementen krijgen dan als waarde de index van de slicegroep waartoe ze behoren. De slicegroepen worden genummerd van 0 tot en met 7, rekening houdend met de beperking van het aantal slicegroepen. Figuur 13 geeft de slicegroepmap voor een QCIFbeeld, dit is een beeld van 11 op 9 macroblokken weer. De macroblokken zijn willekeurig toegewezen aan de verschillende slicegroepen. 27

39 Figuur 13 : Slicegroepmap met zes slicegroepen voor een QCIF-beeld In de vorige paragrafen is al uitgelegd dat een slice wel de macroblokken in scan-order moet bevatten maar dat deze blokken niet noodzakelijk elkaars buur moeten zijn. Hierbij dient opgemerkt te worden dat wanneer we een slicegroep opsplitsen in meerdere slices die volgorde bewaard moet blijven over de slicegrenzen heen. Als dit toegepast wordt op Figuur 13 met twee macroblokken per slice wil dat zeggen dat, indien de macroblokken in scan-order genummerd zijn vanaf 0, de eerste slice macroblokken 0 en 6 en de tweede slice macroblokken 8 en 20 bevat. De combinatie 0 en 8 enerzijds en 6 en 20 anderzijds zijn dus ongeldig. De verklaring hiervoor ligt in het feit dat voor een slice enkel de index van het eerste macroblok wordt meegegeven. De decoder gebruikt de meegeleverde map om te vinden waar de locaties van de overige macroblokken in de slice zijn. Als de volgorde niet gerespecteerd zou worden, zou met elke macroblok zijn index moeten meegegeven worden om een correcte decodering te garanderen Encoder Wanneer er geen FMO gebruikt wordt, krijgen we een redelijk eenvoudig algoritme zoals gedefinieerd in Codefragment 4. MBAddress = 0; while (MBAddress < nr_of_mbs_in_picture) Start_Slice(); // Number of MBs already coded into the slice already_in_slice = 0; while (already_in_slice < nr_of_mbs_in_slice && MBAddress < nr_of_mbs_in_picture) EncodeOneMacroblock(MBAddress++); already_in_slice++; Finish_Slice(); Loopfilter() Codefragment 4 : Encoderingsalgoritme voor H.264/AVC zonder FMO 28

40 Het algoritme maakt gebruik van twee while-lussen. De buitenste lus garandeert dat alle macroblokken in de figuur behandeld worden, de binnenste zorgt er voor dat de macroblokken over de verschillende slices verspreid worden. Een gelijkaardig algoritme met FMO (zie Codefragment 5) zorgt voor enkele bijkomende problemen. Voor elk beeld moet er een slicegroepmap, ook wel macroblok allocation map of MBAmap genoemd, geconstrueerd worden. Wanneer die map niet dezelfde is als deze van het voorgaande beeld moet de encoder de map doorgeven aan de decoder. Dit gebeurt door een nieuwe picture parameter set te genereren. Op deze picture parameter set zal in de volgende paragrafen dieper ingegaan worden als de syntax van FMO besproken wordt. Een eenvoudige lus, die er voor zorgt dat alle macroblokken één voor één geëncodeerd zullen worden, voldoet niet langer. Nu moet elke slicegroep apart behandeld worden. Vervolgens kan een soortgelijk algoritme als bij het geval zonder FMO gebruikt worden. In plaats van het encoderen van elke macroblok in het beeld coderen we nu elke macroblok in de slicegroep. current_mbamap = LoadMBAmap(); if (current_mbamap!= previous_mbamap) Generate_New_Picture_Parameter_Set(); for (i = 0; i < nr_of_slice_groups; i++) MBAddress = GetFirstMBOfSliceGroup(i); while (MBAddress <= GetLastMBOfSliceGroup(i)) Start_Slice(); // Number of MBs already coded into the slice already_in_slice = 0; while (already_in_slice < nr_of_mbs_in_slice && MBAddress <= GetLastMBOfSliceGroup(i))) EncodeOneMacroblock(MBAddress); MBAddress = GetNextMBAddress(MBAddress,i,current_MBAmap); already_in_slice++; Finish_Slice(); Previous_MBAmap = current_mbamap; Loopfilter(); Codefragment 5 : Encoderingsalgoritme voor H.264/AVC met FMO 29

41 In het algoritme in Codefragment 5 worden drie nieuwe functies gebruikt: GetFirstMBOfSliceGroup, GetNextMBAddress en GetLastMB. Hun betekenissen zijn respectievelijk het bepalen van de index van de eerste macroblok in een slicegroep, het bepalen van de index van de macroblok volgend op een gegeven macroblok in dezelfde slicegroep en het bepalen van de index van de laatste macroblok in de slicegroep. Hierbij is GetNextMBAddress zo gedefinieerd dat wanneer de functie na het laatste element van de slicegroep wordt uitgevoerd een index groter dan het aantal macroblokken in het beeld wordt teruggeven Decoder De decoder heeft minder aanpassingen nodig bij het gebruik van FMO dan de encoder. Beide versies maken immers gebruik van dezelfde data. Alleen moet er bij de versie met FMO nog rekening gehouden worden met de constructie van de slicegroepmap. Deze is immers nodig om de index van het volgende macroblok in een slice te vinden. Doordat de slices correct geëncodeerd zijn moet er bovendien geen rekening gehouden worden met randgevallen zoals de laatste macroblok van een slicegroepmap. Codefragment 6 en Codefragment 7 geven de beide decoders weer. MarkAllMBsAsMissing(); while (!End_Of_Picture) GetSliceHeader(); GetFromSliceHeader(&MBAddress); GetFromSliceHeader(&PPSid); ActivatePictureParameterSet(&PPS, PPSid); while (!End_Of_Slice) DecodeOneMacroblock(MBAddress); MarkMBAsOk(MBAddress); MBAddress++; ErrorConcealment(); Loopfilter(); Codefragment 6 : Decoderingsalgoritme voor H.264/AVC zonder FMO De functie GetSGId in Codefragment 7 kan eventueel zelfs weggelaten worden, de functie GetNextMBAddress zal dan wel wat extra inspanning moeten doen bij het opsporen van de index van de volgende macroblok in de slicegroep. 30

42 MarkAllMBsAsMissing(); while (!End_Of_Picture) GetSliceHeader(); GetFromSliceHeader(&MBAddress); GetFromSliceHeader(&PPSid); ActivatePictureParameterSet(&PPS, PPSid); MBAmap = ConstructMBAmap(&PPS); slice_group_id = GetSGId(MBAddress, MBAmap); while (!End_Of_Slice) DecodeOneMacroblock(MBAddress); MarkMBAsOk(MBAddress); MBAddress = GetNextMBAddress(MBAddress, slice_group_id); ErrorConcealment(); Loopfilter(); Codefragment 7 : Decoderingsalgoritme voor H.264/AVC met FMO 4.5 De zeven FMO-types en hun syntax Waarom verschillende types gebruiken Wanneer een beeld gebruikmaakt van een nieuwe slicegroepmap moet de nieuwe map doorgegeven worden aan de decoder. Dit gebeurt via de picture parameter sets. De meest eenvoudige manier is door voor elke macroblok zijn slicegroepnummer mee te geven. Aangenomen dat alle acht de slicegroepen gebruikt worden, krijgt elk macroblok dus een nummer tussen nul en zeven toegewezen. Om dit nummer voor te stellen zijn er minstens drie bits nodig. De minimumkost, in bits, voor het transport van de map zou dus drie keer het aantal macroblokken zijn. Het is echter zo dat de slicegroepmap in veel gevallen een patroon vertoont dat veel beter gecomprimeerd kan worden en dus maar een aantal bits zou kosten. Wanneer we een beperkt aantal types gebruiken hebben we slechts een beperkt aantal bits nodig om het type voor te stellen. Samen met de goedkope kost van het gecomprimeerde patroon is het mogelijk om een zeer grote bitwinst te maken. Anderzijds kunnen we een type maken dat geen gebruikmaakt van patronen. De kost zal dan slechts toenemen met de kost om het type mee te geven en dat zal slechts weinig extra bits vereisen in vergelijking met de volledige map. Momenteel zijn er zeven types (0 tot en met 6) die gecodeerd worden in de syntax met behulp van een Golomb- 31

43 code. Het voordeel tegenover een codering met een vast aantal bits is dat in de toekomst nieuwe types kunnen toegevoegd worden aan de standaard zonder wijzigingen in de standaard aan te brengen. Golomb-codes hebben als eigenschap dat hoe groter het getal is, hoe meer bits er nodig zijn om het voor te stellen. Momenteel is 6 het grootste type. Omgezet naar een Golomb-code geeft dat of dus 5 bits. De maximale kost voor het doorgeven van het type patroon is dus zeer klein FMO in de H.264/AVC-syntax Zoals al in de vorige paragraaf opgemerkt werd, wordt de map met slicegroepnummers doorgegeven met behulp van picture parameter sets. Codefragment 8 bevat een overzicht van de basiselementen van de syntax van FMO in H.264/AVC zoals deze gedefinieerd zijn in [9]. Eerst wordt dus het aantal slicegroepen min één opgeslagen. Als er meer dan één slicegroep is, is er sprake van FMO en wordt het type gevolgd door de nodige informatie opgeslagen. In de volgende paragrafen wordt dieper ingegaan op de specifieke syntax voor elk type. num_slice_groups_minus1 if (num_slice_groups_minus1 > 0) slice_group_map_type if (slice_group_map_type == 0)... if (slice_group_map_type == 1)... if (slice_group_map_type == 2)... if (slice_group_map_type == 3)... if (slice_group_map_type == 4)... if (slice_group_map_type == 5)... if (slice_group_map_type == 6)... Codefragment 8 : Syntax voor FMO in een picture parameter set De informatie die bijgehouden wordt in de picture parameter set voor de verschillende types levert geen MBToSliceGroupMap op zoals men zou kunnen verwachten maar wel een mapunittoslicegroupmap. Het hangt er namelijk vanaf of een beeld als één geheel (frame) wordt gecodeerd of als twee apart beelden (fields). In dat laatste geval worden de pixels op de even rijen toegewezen aan het ene beeld en deze op de oneven rijen aan het andere beeld. Codefragment 9 geeft weer hoe de omzetting van de mapunittoslicegroupmap naar de MBToSliceGroupMap gebeurt. 32

44 if (frame_mbs_only_flag == 1 field_pic_flag == 1) MBToSliceGroupMap[i] = mapunittoslicegroupmap[i]; else if (MbaffFrameFlag == 1) MBToSliceGroupMap[i] = mapunittoslicegroupmap[i/2]; else MBToSliceGroupMap[i] = mapunittoslicegroupmap[(i/(2*picwidthinmbs)) *PicWidthInMBs + (i%picwidthinmbs)]; Type 0 Codefragment 9 : Constructie van MBToSliceGroupMap uit mapunittoslicegroupmap Het eerste patroon maakt gebruik van runlengths. Hierbij wordt gekeken naar het aantal macroblokken na elkaar die hetzelfde slicegroepnummer hebben. Bijkomende voorwaarde is wel dat deze patronen zich blijven herhalen. Een voorbeeld is te zien in Figuur 14. Hierbij is de figuur onderverdeeld in drie slicegroepen met respectievelijke runlength vier, twee en drie. Om de negen macroblokken komt hetzelfde patroon dus terug. Bij dit voorbeeld is de som van de runlengths toevallig een deler van het aantal macroblokken van het beeld. Dit moet echter niet zo zijn. De laatste keer dat het patroon terugkomt mag het gewoon afgekapt worden. Figuur 14: Slicegroepmap voor FMO type 0 met 3 slicegroepen De slicegroepmap kan volledig gereconstrueerd worden aan de hand van de gekende runlengths. Het zijn dan ook enkel deze die moeten doorgegeven worden in de picture parameter set. Aangezien de slicegroepen altijd minstens één macroblok bevatten kan in plaats van de runlength, de runlength-1 worden opgeslagen. Deze worden als Golomb codes opgeslagen. De syntax voor type 0 is weergegeven in Codefragment 10 en is redelijk eenvoudig. 33

45 if (slice_group_map_type == 0) for (igroup = 0; igroup <= num_slice_groups_minus1; igroup++) run_length_minus1[igroup] Codefragment 10 : FMO type 0 H.264/AVC-syntax Constructie van de slicegroepmap uit de syntax gebeurt volgens het algoritme dat gedefinieerd is in Codefragment 11. Er wordt gebruikgemaakt van drie lussen. De buitenste lus, de do-lus, zorgt er voor dat elke positie in de slicegroepmap een slicegroepnummer krijgt toegewezen. De buitenste for-lus overloopt de verschillende runlengths één voor één en de binnenste for-lus zorgt dat voor elk macroblok in een runlength de juiste index in de slicegroepmap terechtkomt. I = 0; do for (igroup = 0; igroup <= num_slice_groups_minus1 && i < PicSizeInMapUnits; i += run_length_minus1[igroup++] + 1) for (j = 0; j < run_length_minus1[igroup] && i + j < PicSizeInMapUnits; j++) mapunittoslicegroupmap[i+j] = igroup; while (i < PicSizeInMapUnits); Type 1 Codefragment 11 : Constructie van de slicegroepmap voor FMO type 0 Type 1 zorgt er voor dat de macroblokken verspreid liggen over het beeld. De technische term hiervoor is scattered slices. De encoder en decoder gebruiken een vaste functie die door beide gekend is. Deze functie steunt op drie dingen: de index van de macroblok waarvoor de slicegroep moet bepaald worden, de breedte van een beeld in macroblokken en het aantal slicegroepen. Het voordeel hiervan is dat de decoder over al deze data beschikt. Daardoor moet er geen extra data worden meegegeven in de picture parameter set voor dit type. Codefragment 12 beschrijft hoe een lus gebruikt wordt om voor elk element in de slicegroepmap het correcte nummer te bepalen. Figuur 15 toont de toepassing van de bovenstaande formule op een QCIF beeld waarbij num_slice_groups_minus1 2 of 4 is. 34

46 Figuur 15: Slicegroepmappen voor FMO type 1 met 3 (a) en 5 (b) slicegroepen De standaard verschaft geen enkele uitleg waarom deze functie gekozen is. Toch vertoont deze functie een aantal bijzondere eigenschappen. Zo wordt om de twee rijen hetzelfde patroon herhaald en kunnen twee opeenvolgende rijen nooit gelijk zijn. Ook twee naast elkaar liggende macroblokken op dezelfde rij kunnen nooit tot eenzelfde slicegroep behoren. Zie Appendix A voor bewijzen van deze stellingen. Deze eigenschappen zorgen voor een goede spreiding van de slicegroepen in de slicegroepmap. for (i = 0; i < PicSizeInMapUnits; i++) mapunittoslicegroupmap[i] = ((i % PicWidthInMBs) + (((i / PicWidthInMBs) * (num_slice_groups_minus1 + 1)) / 2)) % (num_slice_groups_minus1 + 1); Codefragment 12 : Constructie van de slicegroepmap voor FMO type Type 2 Dit is het type dat origineel beschreven werd in H.263 Annex K. Het introduceert het gebruik van rechthoekige slicegroepen in de standaard. Zoals in Figuur 16a is weergegeven, mogen er binnen eenzelfde beeld meerdere rechthoekige slicegroepen gedefinieerd worden. De macroblokken die niet toebehoren aan een van de rechthoeken, worden toegewezen aan een aparte slicegroep met een hoger nummer dan de overige slicegroepen. Dit houdt in dat er maximaal zeven rechthoeken per beeld gedefinieerd mogen zijn. De achtste slicegroep bevat immers de macroblokken die niet tot één van de overige zeven groepen behoren. Zoals in Figuur 16b getoond wordt, mogen de rechthoeken elkaar ook overlappen. Omdat een macroblok slechts tot één slicegroep mag behoren is een systeem van prioriteiten bedacht aan de hand van de slicegroepnummers. Een macroblok die tot meerdere slicegroepen kan behoren wordt toegewezen aan de slicegroep met het kleinste slicegroepnummer. In het voorbeeld is duidelijk te zien hoe slicegroep 0 zich boven slicegroep 1 bevindt. 35

47 Figuur 16 : Slicegroepmappen voor FMO type 2 met 3 slicegroepen Wanneer een beeld volledig opgesplitst wordt in rechthoeken, bijvoorbeeld een lijn die het beeld in twee deelt, mag de laatste rechthoek niet als een aparte rechthoekige slicegroep gedefinieerd worden. Dit zou er toe leiden dat de laatste slicegroep, die de macroblokken die niet tot een rechthoek behoren bevat, leeg zou zijn en dus zou de map niet efficiënt gecodeerd zijn. De goedkoopste manier om een rechthoek in H.264/AVC te definiëren is aan de hand van de linkerbovenhoek en de rechteronderhoek. Elke element van slicegroepmap heeft namelijk een unieke index. Het zijn deze twee hoekpunten die als Golomb-codes worden meegegeven in de picture parameter set (Codefragment 13). if (slice_group_map_type == 2) for (igroup = 0; igroup < num_slice_groups_minus1; igroup++) top_left[igroup]; bottom_right [igroup] Codefragment 13 : FMO type 2 H.264/AVC-syntax Codefragment 14 beschrijft het algoritme voor de constructie van de slicegroepmap uit de verzamelingen van elke twee hoekpunten. Alle macroblokken worden eerst toegewezen aan de laatste slicegroep. Vervolgens worden de rechthoeken in omgekeerde volgorde toegevoegd aan de slicegroep map. Figuur 17 bevat een voorbeeld van de werking van het algoritme voor de constructie van de slicegroepmap gedefinieerd in Figuur 16b. Eerst worden alle blokken toegewezen aan slicegroep 2 (Figuur 17a). Vervolgens wordt slicegroep 1 toegevoegd aan de map wat resulteert in Figuur 17b. Tot slot wordt ook de laatste rechthoek toegevoegd aan de slicegroepmap om zo tot Figuur 17c te komen. Het in omgekeerde volgorde toevoegen van de rechthoeken aan de slicegroepmap toont aan hoe de prioriteiten, voor blokken die tot meerdere rechthoeken behoren, verwerkt worden. 36

48 for (i = 0; i < PicSizeInMapUnits; i++) mapunittoslicegroupmap[i] = num_slice_groups_minus1; for (igroup = num_slice_groups_minus1 1; igroup >= 0; igroup--) ytopleft = top_left[igroup] / PicWidthInMBs; xtopleft = top_left[igroup] % PicWidthInMBs; ybottomright = bottom_right[igroup] / PicWidthInMBs; xbottomright = bottom_right[igroup] % PicWidthInMBs; for (y = ytopleft; y <= ybottomright; y++) for (x = xtopleft; x <= xbottomright; x++) mapunittoslicegroupmap[y * PicWidthInMBs + x] = igroup; Codefragment 14 : Constructie van de slicegroepmap voor FMO type 2 Figuur 17 : Voorbeeld van het algoritme voor de constructie van een slicegroepmap aan de hand van FMO type Type 3, 4 en 5 De types 3, 4 en 5 worden samen besproken omdat ze vrij veel gemeen hebben. Het zijn alledrie evoluerende types. Dat houdt in dat de twee slicegroepen, die in elk type gebruikt worden, voor elk nieuw beeld wijzigen en zo het beeld beetje bij beetje verversen. Elk van de drie types maakt gebruik van drie veranderlijken om de slicegroepmap op te bouwen: de groeisnelheid of slice_group_change_rate_minus1 de groeirichting of slice_group_change_direction_flag de positie in de groeicyclus of slice_group_change_cycle De eerste twee blijven constant, de derde, de groeicyclus, wijzigt bij elk beeld. De eerste twee parameters worden net zoals bij de andere FMO-types ondergebracht in de picture parameter set (Codefragment 15). De groeicyclus moet worden bijgehouden per beeld. De 37

49 H.264/AVC-syntax ondersteunt echter geen syntaxelementen op beeld-niveau, enkel op sliceniveau. De slice_group_change_cycle wordt daarom ondergebracht in de sliceheader (Codefragment 15). picture_parameter_set: if (slice_group_map_type == 3 slice_group_map_type == 4 slice_group_map_type == 5 ) slice_group_change_direction_flag; slice_group_change_rate_minus1; slice_header: if (slice_group_map_type == 3 slice_group_map_type == 4 slice_group_map_type == 5 ) slice_group_change_cycle; Codefragment 15 : FMO type 3, 4 en 5 H.264/AVC-syntax De slice_group_change_direction_flag wordt gecodeerd met behulp van één bit, de slice_group_change_rate_minus1 wordt gecodeerd met behulp van Golomb codes. De laatste parameter, de slice_group_change_cycle, wordt met een variabel aantal bits gecodeerd. Het aantal wordt bepaald aan de hand van de formule in Codefragment 16. Dit komt overeen met het aantal bits dat nodig is om het aantal mogelijke toestanden weer te geven. Ceil( Log2(PicSizeInMapUnits (slice_group_change_rate_minus1 + 1) + 1) ) Codefragment 16 : Het aantal bits nodig om de slice_group_change_cycle voor te stellen De grootte van beide slicegroepen wordt bepaald door de formules in Codefragment 17. Volgens deze definitie kan dus één van beide slicegroepen leeg zijn, MapUnitsInSliceGroup0 is immers 0 als slice_group_change_cycle 0 is en MapUnitsInSliceGroup1 is 0 als MapUnitsInSliceGroup0 gelijk is aan PicSizeInMapUnits. Op het eerste zicht lijkt dit vreemd want de types 0 en 2 lieten geen lege slicegroepen toe. Toch is er hier een goede reden voor. Als bij de types 0 en 2 lege slicegroepen toegelaten zouden worden, zou dit de efficiëntie van de codering beïnvloeden. Er zou dan namelijk overtollige data, extra runlengths voor type 0 en extra hoekpunten voor type 2 moeten meegegeven worden. Bij de types 3, 4 en 5 geldt dit niet. De slicegroepen evolueren voortdurend en er zal dan ook maar af en toe een beeld zijn dat maar met één slicegroep werkt. Voor dat beeld een apart picture parameter set zonder FMO voorzien zou juist een extra kost betekenen. 38

50 Type 3 MapUnitsInSliceGroup0 = Min(PicSizeInMapUnits, slice_group_change_cycle * (slice_group_change_rate_minus1 + 1) MapUnitsInSliceGroup1 = PicSizeInMapUnits MapUnitsInSliceGroup0 Codefragment 17 : Grootte van de slicegroepen bij FMO types 3, 4 en 5 Nu wordt wat dieper ingegaan de de drie verschillende evoluerende types. Bij type 3 wordt er vertrokken vanuit het centrum van het beeld en wordt er een spiraal gecreëerd in wijzerzin of tegenwijzerzin. Figuur 18(a)-(c) geeft een voorbeeld van type 3 in wijzerin met een groeisnelheid van vijf blokken per beeld. Figuur 18(d)-(f) geeft een voorbeeld van de tegenwijzerzin-versie. Figuur 18 : Slicegroepmappen voor FMO type 3 met groeisnelheid 5 Codefragment 18 bevat het algoritme dat gebruikt wordt bij de creatie van de slicegroepmap bij type 3. Het algoritme is nogal lang maar kan opgesplitst worden in een aantal kleinere stappen. Om te beginnen wordt een for-lus uitgevoerd die er voor zorgt dat het slicegroepnummer van alle blokken één is. Vervolgens worden een aantal veranderlijken gedeclareerd: 39

51 x en y : bepalen de kolom en rij waar het blok zich bevindt dat verwerkt moet worden. leftbound, topbound, rightbound en bottombound : bepalen het kader waarbinnen de spiraal zich bevindt. xdir en ydir : bepalen de richting waarin het algoritme loopt. Tabel 4 geeft een overzicht van de verschillende waarden en hun betekenis. Eén van beide veranderlijken zal altijd nul zijn. Tabel 4 : Bewegingsveranderlijken en -richtingen bij FMO type 3 Veranderlijke Waarde bewegingsrichting xdir -1 naar rechts 0 1 naar links ydir -1 naar onder 0 1 naar boven Vervolgens worden de elementen van slicegroep 0 stuk voor stuk bepaald aan de hand van een for-lus. Deze controleert eerst of het blok nog niet toegewezen is aan slicegroep 0. Daarna wordt de richting en positie van het volgende macroblok bepaald aan de hand van vijf opeenvolgende if-lussen. Om de werking van het algoritme te verduidelijken wordt er een voorbeeld gegeven in Tabel 5. Er wordt gewerkt met een QCIF-beeld, dat is een beeld van 11 op 9 blokken, en de spiraal loopt in tegenwijzerzin (slice_group_change_direction_flag = 1). Bij k = 81 wordt duidelijk waarom er gecontroleerd moet worden of een blok nog vrij. De verhouding van de hoogte en de breedte in een QCIF beeld zorgen er immers voor dat op een bepaald moment de slicegroepmap bestaat uit drie rechthoeken waarbij de middelste volledig opgebruikt is (zie Figuur 19). Doordat het algoritme maar één blok per keer opschuift moet er een aantal keer opgeschoven worden voordat de volgende vrije blok bereikt wordt. De hele berekening moet voor elk beeld herhaald worden. Bij een groeisnelheid van vijf blokken zal bij het eerste beeld vijf blokken en bij het tweede beeld tien blokken moeten berekend worden. Toch zijn voor beide de eerste vijf blokken gelijk. Om rekenkracht te sparen is het mogelijk om de volgorde van de blokken slechts één keer te bepalen en bij te houden in een rij of lijst. Een nieuwe beeld zou dan gewoon kunnen beginnnen aan het begin van de lijst en deze aflopen tot het gevraagde aantal blokken in slicegroep 0 bereikt is. 40

52 for (i = 0; i < PicSizeInMapUnits; i++) mapunittoslicegroupmap[i] = 1; x = ( PicWidthInMBs slice_group_change_direction_flag ) / 2; y = ( PicHeightInMapUnits - slice_group_change_direction_flag ) / 2; ( leftbound, topbound ) = ( x, y ); ( rightbound, bottombound ) = ( x, y ); ( xdir, ydir ) = ( slice_group_change_direction_flag 1, slice_group_change_direction_flag); for (k = 0; k < MapUnitsInSliceGroup0; k+= mapunitvacant) mapunitvacant = (mapunittoslicegroupmap[y*picwidthinmbs+x] == 1); if (mapunitvacant) mapunittoslicegroupmap[y*picwidthinmbs+x] = 0; if (xdir == -1 && x == leftbound) leftbound = Max( leftbound 1, 0 ); x = leftbound; ( xdir, ydir ) = ( 0, 2 * slice_group_change_direction_flag 1); else if (xdir == 1 && x == rightbound) rightbound = Min( rightbound + 1, PicWidthInMBs 1 ); x = rightbound; ( xdir, ydir ) = ( 0, 1 2 * slice_group_change_direction_flag); else if (ydir == -1 && y == topbound) topbound = Max( topbound 1, 0 ); y = topbound; ( xdir, ydir ) = ( 1-2 * slice_group_change_direction_flag,0 ); else if (ydir == 1 && y == bottombound) bottombound = Min( bottombound + 1, PicWidthInMBs 1 ); y = bottombound; ( xdir, ydir ) = ( 2 * slice_group_change_direction_flag 1,0 ); else ( x, y ) = ( x + xdir, y + ydir ); Codefragment 18 : Constructie van de slicegroepmap voor FMO type 3 41

53 Tabel 5 : Voorbeeld van de opbouw van een slicegroepmap voor FMO type 3 (tegen wijzerzin) K mapunit vrij x Y tb lb bb rb xd yd T T T T T T T T T T T F F F F F F F F F T T T 0-1 Figuur 19 : Gedeeltelijke constructie van een slicegroepmap voor FMO type 3 Type 4 Het tweede type in de reeks van evoluerende types vertrekt vanuit de linkerboven- of rechteronderhoek van het beeld en loopt de lijnen één voor één af. In Figuur 20 is de groeisnelheid 5. Figuren (a)-(c) zijn voorbeelden van de richting 0 terwijl (d)-(f) voorbeelden zijn van de richting 1. Het algoritme dat weergegeven is in Codefragment 19 is een stuk eenvoudiger dan dat van type 3. Eerst wordt er bepaald hoeveel blokken er in de meest links slicegroep moet komen. Daarna wordt de map aangemaakt door alle blokken één voor één in volgorde te overlopen en ze toe te kennen aan de eerste slicegroep zolang die nog niet vol is. Als die wel al vol is, worden de blokken in de tweede groep gestoken. 42

54 Figuur 20 : Slicegroepmappen voor FMO type 4 met groeisnelheid 5 Dit is een theoretisch algoritme dat geoptimaliseerd kan worden door de de for-lus te splitsen in twee lussen in plaats van een if-lus te gebruiken. Het aantal vergelijkingen die nodig zouden zijn voor de constructie van de map zou gehalveerd worden op die manier. Type 5 sizeofupperleftgroup = (slice_group_change_direction_flag? (PicSizeInMapUnits MapUnitsInSliceGroup0) : MapUnitsInSliceGroup0) for ( i = 0; i < PicSizeInMapUnits; i++) if ( i < sizeofupperleftgroup ) mapunittoslicegroupmap[i] = slice_group_change_direction_flag; else mapunittoslicegroupmap[i] = 1 - slice_group_change_direction_flag; Codefragment 19 : Constructie van de slicegroepmap voor FMO type 4 Het enige verschil tussen type 5 en type 4 is dat in plaats van lijn per lijn te werken, type 5 kolom per kolom werkt (zie Figuur 21). Het algoritme om de map te construeren is nu iets ingewikkelder. De for-lus wordt opgesplitst in twee delen, één voor de rij-index (binnenste) en één voor de kolom-index (buitenste). Dit zorgt er voor dat we rij per rij afhandelen. Net zoals bij type 4 wordt eerst bepaald hoeveel blokken er in de linkerbovenslicegroep moeten. Ook hier is het mogelijk om 43

55 de complexiteit van het algoritme te verminderen door beide groepen apart te vullen. De forlussen zullen dan wel niet gebruikt kunnen worden. Overzicht Figuur 21 : Slicegroepmappen voor FMO type 5 met groeisnelheid 5 sizeofupperleftgroup = (slice_group_change_direction_flag? (PicSizeInMapUnits MapUnitsInSliceGroup0) : MapUnitsInSliceGroup0) k = 0; for ( j = 0; j < PicWidthInMBs; j++) for ( i = 0; i < PicHeightInMapUnits; i++) if (k++ < sizeofupperleftslicegroup) mapunittoslicegroupmap[i*picwidthinmbs+j] = slice_group_change_direction_flag; else mapunittoslicegroupmap[i*picwidthinmbs+j] = 1 - slice_group_change_direction_flag; Codefragment 20 : Constructie van de slicegroepmap voor FMO type 5 Uit de voorgaande paragrafen blijkt duidelijk dat alhoewel ze alledrie dezelfde syntax hebben ze onderling toch nog heel wat verschillen. Tabel 6 geeft een overzicht van de officiële benaming voor elk type. Elk type is bovendien ook nog eens opgedeeld afhankelijk van de richting waarin de slicegroepen groeien. 44

56 4.5.7 Type 6 Tabel 6 : Overzicht van FMO type 3, 4 en 5 slice_group slice_group_change Benaming map_type direction_flag 3 0 Box-out clockwise 3 1 Box-out counter-clockwise 4 0 Raster scan 4 1 Reverse raster scan 5 0 Wipe right 5 1 Wipe left Soms zit er helemaal geen patroon in het beeld en is het wel nodig om de slicegroepmap volledig te transporteren. Codefragment 21 toont dat naast de verschillende elementen uit de map ook hun aantal (en dus de grootte van de map) wordt meegegeven. Diezelfde grootte kan nochthans bekomen door het produkt te nemen van de breedte en hoogte zoals gedefinieerd in de sequence parameter set die bij de picture parameter set hoort. Op het eerste zicht is er dus sprake van redundante data. De reden daarvoor moet gezocht worden in het feit dat, dankzij die redundantie, de picture parameter set los van de sequence parameter set kan gecodeerd worden. Dat betekent dat deze laatste niet actief moet zijn op het moment data de picture parameter set ontleed wordt. if (slice_group_map_type == 6) pic_size_in_map_units_minus1 for (i = 0; i < pic_size_in_map_units_minus1; i++) slice_group_id[i]; Codefragment 21 : FMO type 6 H.264/AVC-syntax Terwijl de grootte van de map met een Golomb-code wordt opgeslagen wordt elk element van de map gecodeerd met een bepaald aantal bits. Dat aantal wordt bepaald door de log 2 te nemen van het grootste slicegroepnummer en het resultaat naar boven af te ronden. Aangezien er maximaal acht slicegroepen zijn is het grootste nummer zeven en zijn er dus in dat geval drie bits nodig voor elk element. Codefragment 22 bevat dan het algoritme dat elke blok zijn slicegroepnummer geeft. for ( i = 0; i < pic_size_in_map_units_minus1; i++)..mapunittoslicegroupmap[i] = slice_group_id[i]; Codefragment 22 : Constructie van de slicegroepmap voor FMO type 6 45

57 4.6 Implementatie Een nieuw bestandsformaat De referentiesoftware maakt gebruik van een configuratiebestand met verandelijken en hun waarde. Dit bestand wordt als parameter meegegeven aan de encoder. Codefragment 23 bevat een overzicht van alle parameters uit het bestand met betrekking tot FMO. Het valt onmiddellijk op dat er heel wat tekortkomingen zijn. Zo is het bijvoorbeeld onmogelijk om runlengths mee te geven voor FMO type 1. Voor type 2 is het maar mogelijk om één rechthoek te definiëren terwijl er in theorie zeven mogen zijn. Daarenboven laat deze syntax niet toe om de slicegroepmap te laten wijzigen doorheen de tijd. num_slice_groups_minus1 = 0 FmoType = 0 # 0-6 FmoTopLeftMB = 24 # the top left MB of the rectangular # shape for slice groups, MB counted in # raster scan order FmoBottomRightMB = 74 # the bottom right MB of the rectangular # shape for slice groups FmoChangeDirection = 1 # 0: box-out clockwise, raster scan or # wipe right, # 1: box-out counter clockwise, reverse # raster scan or wipe left FmoChangeRate = 4 # SLICE_GROUP_CHANGE_RATE minus 1 FmoConfigFileName = "fmoconf.cfg" # not yet used, for future # fully flexible MBAmaps Codefragment 23 : Overzicht van de veranderlijken voor FMO in de referentiesoftware Om een dynamische versie van FMO te verkrijgen is het noodzakelijk dat het configuratiebestand uitbreidbaar is. Voor elk beeld kan er namelijk een nieuwe slicegroepmap gedefinieerd moeten worden. Daarom is er in de gewijzigde versie een apart bestand voorzien dat de informatie voor alle slicegroepmappen bevat. Om geen al te grote aanpassingen aan de referentiesoftware te moeten doen op het vlak van parameters wordt de naam van het bestand meegegeven via de bestaande parameter FmoConfigFileName. De meest aangename manier zou zijn om de parameters op te nemen in een XML-file. Er zou dan ook een valideringsschema voor de data aangemaakt kunnen worden. Maar de uitbreiding van de referentiesoftware met een XML-bibliotheek zou deze bijna laten verdubbelen in grootte. Bovendien is het niet de bedoeling om een commercieel hoogwaardig produkt te ontwikkelen. Een bijkomende eis is dat het bestand eenvoudig te wijzigen moet zijn. Daarom is er gekozen om een bestand met platte ASCII-tekst te gebruiken. Codefragment 24 geeft een overzicht van de nieuwe structuur die voorzien is. Er is voor gekozen om opeenvolgende beelden die dezelfde slicegroepmap bezitten samen te voegen tot één geheel via de start- en 46

58 stopveranderlijken. Daarna volgt het aantal slicegroepen in de map. Als dat één is, wordt de rest van de regel overgeslagen. Als er meer dan één slicegroep is, volgt het type en daarna eventueel de data die nodig is bij het type. Alle veranderlijken worden gescheiden door een. Het, -symbool dient om de FMO-data eventueel verder op te splitsen. Het # -symbool aan het begin van een lijn markeert de lijn als commentaar en laat de gebruiker toe om extra informatie toe te voegen. Codefragment 25 bevat een voorbeeld van de verschillende types bij FMO. De types 4 en 5 die niet in het voorbeeld zijn opgenomen vertonen precies dezelfde structuur als type 3. Definitie slicegroepmap: start stop nr_of_slices fmo_type fmo_data; Hierbij is: start = eerste beeld dat met deze slicegroepmap wordt gecodeerd stop = laatste beeld dat met deze slicegroepmap wordt gecodeerd nr_of_slices = het aantal slicegroepen in de slicegroepmap fmo_type = het type FMO fmo_data = de data om een slicegroepmap te construeren aan de hand van het type Type 0 : door komma gescheiden runlengths Type 1 : niets, nr_of_slices is het enige wat nodig is Type 2 : door komma gescheiden rechthoeken waarbij elke rechthoek bestaat uit: linkerbovenhoek,rechteronderhoek Type 3 : slice_group_change_direction_flag, slice_group_change_rate Type 4 : zie type 3 Type 5 : zie type 3 Type 6 : een aaneengesloten rij van getallen Codefragment 24 : Overzicht van de nieuwe structuur van slicegroepmappen # Beelden 0 tot 10 zitten elk in 1 slicegroep (geen fmo) # Beelden 11 tot 30 worden elk opgesplitst in 2 delen. Het gebruikte # type is 0 en de twee runlengths bij dit type zijn beiden ,12 # Beelden 31 tot 40 worden opgesplitst in 4 slicegroepen. FMO type 1 # wordt toegepast wat inhoud dat de mappen aan de hand van de vaste # functie worden gedefinieerd # Beelden 41 tot 50 worden opgesplitst in 3 slicegroepen. Twee van de # slicegroepen zijn gedefinieerd als rechthoeken: (24,74) en (62,98) ,74,62,98 # Beelden 51 tot 60 worden opgesplitst in 2 slicegroepen. Er wordt # gebruikgemaakt van FMO type 3 in tegenwijzerzin en met een #.groeisnelheid van 8 blokken 47

59 ,8 # Beelden 61 tot 200 worden opgesplitst in 6 slicegroepen. De data # toont het patroon van de verschillende groepen Codefragment 25 : Voorbeelden van de verschillende mogelijkheden voor de nieuwe structuur van De FrameInfo-structuur slicegroepmappen De data die uit het parameterbestand gehaald wordt moet op meerdere plaatsen in het programma beschikbaar zijn. De eenvoudigste manier om dit te bekomen is de data statisch te declareren. Op zich levert dit geen probleem maar er wordt wel gewerkt met een heel stel veranderlijken (afhankelijk van het FMO-type). Om het geheel overzichtelijk te houden is een nieuwe structuur toegevoegd: de FrameInfo. Naast al de nodige veranderlijken voor elk type bevat deze ook een volledig opgebouwde slicegroepmap. Telkens wanneer een nieuw beeld geëncodeerd wordt, wordt er gecontroleerd of de huidige FrameInfo-structuur nog wel de juiste data bevat. Zoniet wordt de informatie voor het beeld uit het bestand gehaald. Met behulp van die informatie wordt er ook een nieuwe slicegroepmap gemaakt die toegevoegd wordt aan de structuur. Het is ook op dat punt dat er een nieuwe picture parameter set gegenereerd moet worden. De code hiervoor is terug te vinden in de nieuwe software in de bestanden fmo.c en fmo.h Picture Parameter Set De implementatie van de picture parameter set in de referentiesoftware gebruikte een hard gecodeerde index (0) waardoor er slechts één picture parameter set voor de volledige beeldsequentie kan gegenereerd worden. In de nieuwe versie is gebruikgemaakt van een lokale veranderlijke die bij elke generatie van een picture parameter set met één verhoogd wordt. Wanneer de veranderlijke groter wordt dan het maximaal aantal toegestane picture parameter sets wordt deze terug op nul gezet. Doordat het interval waarover de veranderlijke beschikt redelijk groot is (standaard 128) is het hoogst onwaarschijnlijk dat het vervangen van zo n oude picture parameter set invloed zal hebben op de codering. De overige gegevens omtrent FMO worden dan uit de statisch gedeclareerde FrameInfo gehaald en geëncodeerd met de rest van de data. De uitgewerkte code is terug te vinden onder parset.h en parset.c. 48

60 4.6.4 Besluit De referentiesoftware die beschikbaar was bij het begin van dit project, JM73, beschikte niet over een implementatie van FMO aan de encoder-kant. De decoder had in principe een werkende versie van FMO aan boord. Tijdens dit werk is er een implementatie ontworpen conform de H.264/AVC-standaard voor alle zeven types. Bovendien is er ook een dynamische versie van FMO geïmplementeerd. Met dat laatste wordt bedoeld dat de slicegroepmap doorheen de sequentie mag wijzigen. De voorgaande paragrafen gaven een omschrijving van de hoofdmoot van die implementatie. Er zijn nog wel een aantal dingen aangepast maar deze worden niet in detail besproken. Voor een volledig overzicht van de wijzigingen wordt verwezen naar Appendix B. 49

61 Hoofdstuk 5 Flexibele macroblok ordening in de praktijk: toepassingen en kosten 5.1 Foutopvanging Inleiding Wanneer NAL-eenheden over een netwerk verzonden worden, kan er al eens een pakket verloren gaan. De decoder beschikt dan over twee mogelijkheden: ofwel het pakket opnieuw aanvragen ofwel proberen verder te doen met de decodering. Een eerste toepassing van FMO is het afbakenen van rechthoekige interessegebieden (type 2). Deze gebieden hebben dan automatisch een hoger slicegroepnummer volgens hun definitie ( 4.5.5). Een intelligente decoder zou dan bij pakketverlies kunnen controleren of het gemiste pakket een deel van het interessegebied bevat of niet. Indien dit laatste het geval is zou de decoder kunnen vragen om de gemiste NAL-eenheid opnieuw door te zenden. Wanneer de data betrekking zouden hebben op een gebied buiten het interessegebied, dan zou de decoder een reconstructie van de data kunnen uitvoeren. De gemiste informatie was in dat geval niet zo belangrijk. Een voorbeeld hiervan is een nieuwslezer in een studio. Enkel de persoon beweegt en dan nog heel beperkt. Het rondomliggende beeld wijzigt niet en als er dus een deel van verloren geraakt, zou reconstructie triviaal moeten zijn. Bij toepassingen zoals videoconferentie is er gewoon geen tijd om te wachten op een nieuwe versie van de verloren NAL-eenheid. Zelfs niet als deze zich in het interessegebied 50

62 bevindt. De decoder moet dus zelf proberen om de gemiste beelden zo goed mogelijk te reconstrueren. FMO type 1 kan hierbij helpen zoals uit de volgende paragrafen zal blijken Reconstructie met en zonder FMO In 3.4 zijn verschillende manieren van reconstructie van verloren macroblokken aan bod gekomen. Bij het ontwerp van de nieuwe decoder ( 3.6) is een vorm van interpolatie aan de hand van de rondomliggende macroblokken geïmplementeerd. Er is toen niet stilgestaan bij het reconstructieproces voor een macroblok in het geval er meerdere omliggende macroblokken verloren zijn zoals in Figuur 22. In Figuur 22(a) wordt een beeld weergegeven waarvan het witte deel ontbreekt. Slechts een beperkt aantal van de macroblokken beschikt over gekende buren die gebruikt kunnen worden bij de reconstructie. Figuur 22(b) toont de eerste stap in die reconstructie waarbij de donkergrijze macroblokken de gereconstrueerde voorstellen. Het zijn deze die moeten gebruikt worden om de overige ontbrekende slices te bepalen. Figuur 22(c) toont dan het uiteindelijke resultaat. Het verschil in kleurschakering geeft aan hoe veel de gereconstrueerde macroblokken afwijken van hun orginieel. Figuur 22 : Stapsgewijze reconstructie van verloren macroblokken (zonder FMO) Wanneer hetzelfde beeld gecodeerd wordt met behulp van FMO type 1 met 4 slicegroepen en er één slice verloren gaat tijdens het transport, wordt een beeld zoals in Figuur 23(a) bekomen. Interpolatie van de gekende macroblokken om de verloren blokken te reconstrueren levert Figuur 23(b). In vergelijking met Figuur 22(c) beschikt elke macroblok nu wel over gekende buren en moet er niet vertrokken worden van gereconstrueerde macroblokken om andere macroblokken te bepalen. Het lijkt dus niet meer dan logisch dat het gebruik van FMO een verbeterde reconstructie oplevert. In de volgende paragrafen wordt aan de hand van een aantal experimenten gekeken naar de verbetering in beeldkwaliteit door het gebruik van FMO en de kosten die dat met zich meebrengt. 51

63 Figuur 23 : Stapsgewijze reconstructie van verloren macroblokken (FMO) De testopstelling Tabel 7 biedt een overzicht van alle parameters die gewijzigd zijn tijdens de testen. Bij alle experimenten zijn twee beelden als referentie gebruikt bij intervoorspelling. Beide sequenties bestaan uit een 300-tal beelden met een snelheid van 30 beelden per seconde. Om over een voldoende grote hoeveelheid data te beschikken zijn de sequenties eerst geëncodeerd en is het resultaat daarna zes keer na elkaar geplakt om zo tot een sequentie van een kleine minuut te komen. De grootte van slices is beperkt tot 50 macroblokken. Experimentele resultaten hebben aangetoond dat bij deze grootte alle slices kleiner zijn dan 1500 byte. De NAL-eenheden met daarin de slices, kunnen dus verzonden worden over netwerk zonder opgesplitst te worden (zie ook 3.2). In een tweede fase zijn drie bestanden gegenereerd die uniform pakketverlies simuleren. Hierbij is uitgegaan van 1%, 2% en 5% verlies. Deze waarden zijn afgeleid uit de data van IBCN-werkgroup[10,11] binnen de Universiteit Gent. De experimenten beperken zich enkel tot uniform pakketverlies. Bursty pakketverlies wordt niet bestudeerd wegens tijdsgebrek enerzijds en wegens het feit dat uniform verlies wordt gezien als het slechts mogelijke scenario bij videodata anderzijds. Met behulp van de software uit zijn dan de beschadigde bitstromen gegenereerd. Vervolgens is gebruikgemaakt van de nieuw ontwikkelde decoder in 3.6. Enkel een kleine wijziging met betrekking tot het hernummeren van de beelden, het draait uiteindelijk om zes keer dezelfde stroom na elkaar, is aangebracht in de decoder. Om tijd te winnen zijn er geen bestanden met extra informatie gegenereerd door de decoder. Een belangrijke opmerking omtrent de reconstructie van de verloren macroblokken is dat de gebruikte technieken niet noodzakelijk de beste technieken zijn die er momenteel beschikbaar zijn. Het is enkel de bedoeling om een beeld te schetsen van de effecten van FMO, niet om een meesterwerk op het gebied van reconstructie af te leveren. 52

64 Tabel 7 : Overzicht van de wijzigende parameters bij de testen rond foutopvang met behulp van FMO Parameter Waarden Beeldsequenties stefan_cif.yuv table_cif.yuv GOP-structuur IPPPPPPPPPPPPPPPPPI IBBPBBPBBPBBPBBPBBI Quantisatieparameters I = 28 / P = 28 / B = 30 I = 40 / I = 40 / B = 42 FMO Geen FMO Type 1 met 4 slicegroepen In een laatste fase zijn de gedecodeerde en gerepareerde bestanden vergeleken met behulp van een PSNR analyse. PSNR, wat staat voor Peak Signal to Noise Ratio, is gebaseerd op de Euclidische afstand tussen twee beelden aan de hand van de gemiddelde kwadratische afwijking. Algemeen kan gesteld worden dat hoe hoger de PSNR van een beeld, hoe hoger de kwaliteit is van het betreffende beeld. De waarden zijn berekend met behulp van software ontwikkeld binnen MultimediaLab. Voor de experimenten is enkel gebruikgemaakt van PSNR-berekeningen voor de luminantie-component Resultaten van het experiment: visuele verbetering Figuur 24 tot Figuur 27 geven een overzicht van de bekomen resultaten voor de verschillende parameters. Hierbij zijn de lijnen die weergegeven zijn met HQ deze met een hoge kwaliteit en dus de kleinste quantisatieparameters, terwijl deze met LQ deze met de laagste kwaliteit en dus grootste quantisatieparameters. De weergegeven waarden zijn de gemiddelde van alle beelden in een sequentie. Uit alle figuren valt duidelijk af te leiden dat de kwaliteit van de sequenties die met FMO gecodeerd zijn, hoger is dan deze zonder FMO. Hoe groter het pakketverlies is, hoe groter ook de verschillen in PSNR voor beide gevallen. Uit de grafieken valt ook af te leiden dat het gebruik van B-beelden geen grote invloed heeft op de wijziging in kwaliteit. 53

65 HQ: FMO HQ: No FMO LQ: FMO LQ: No FMO Y-PSNR (db) % packet loss (uniform) Figuur 24 : Kwaliteitsverlies door pakketverlies bij Stefan met GOP-structuur IP 36 Y-PSNR (db) HQ: FMO HQ: No FMO LQ: FMO LQ: No FMO % packet loss (uniform) Figuur 25 : Kwaliteitsverlies door pakketverlies bij Stefan met GOP-structuur IBBP 54

66 HQ: FMO HQ: No FMO LQ: FMO LQ: No FMO Y-PSNR (db) % packet loss (uniform) Figuur 26 : Kwaliteitsverlies door pakketverlies bij Table met GOP-structuur IP HQ: FMO HQ: No FMO LQ: FMO LQ: No FMO 30 Y-PSNR (db) % packet loss (uniform) Figuur 27 : Kwaliteitsverlies door pakketverlies bij Table met GOP-structuur IBBP Figuur 28 geeft een detail van de PSNR voor een aantal beelden. Rond beeld 546 geraken enkele NAL-eenheden verloren. Terwijl de versie zonder FMO een val kent in PSNR en dus duidelijk beelden van een slechte kwaliteit oplevert, slaagt de versie met FMO er in om de kwaliteit nog een aantal beelden hoog te houden. Het is pas wanneer er nog meer fouten optreden dat ook bij de versie met FMO de kwaliteit nog verder daalt. Toch blijft het resultaat nog steeds een heel stuk beter dan in het geval zonder FMO. Dezelfde trend kan 55

67 waargenomen worden doorheen alle experimenten. De PSNR in het geval zonder FMO varieert doorheen de tijd veel meer dan in het geval met FMO Met FMO Zonder FMO Figuur 28 : Detail verschil in PSNR bij stefan met en zonder FMO bij hoge kwaliteit met 5 procent verlies PSNR is een manier om de kwaliteit te vergelijken op een objectieve manier maar uiteindelijk is het nog altijd de kijker die de techniek een verbetering moet vinden. De verschillende sequenties zijn dan ook aan een aantal mensen getoond om de verschillen in kwaliteit te beoordelen. De versies met FMO werden verkozen boven deze zonder FMO omdat vooral de gecorrigeerde banden (zie Figuur 29) storend overkwamen. Deze veroorzaakten een irriterende flikkering tijdens het afspelen van de gereconstrueerde sequentie. Figuur 29 : Fragment uit Stefan zonder B-slices met hoge kwaliteit bij een verlies van 5% 56

68 5.2 Schaalbare kwaliteit: interessegebieden Inleiding Naast het gebruik bij foutopvang kan FMO type 2 ook gebruikt worden om schaalbare kwaliteit in te voeren. Elke macroblok krijgt namelijk zijn eigen quantisatieparameter mee. Door de delen buiten de interessegebieden in een lagere kwaliteit te coderen kan een groot aantal bits bespaard worden zonder afbreuk te doen aan het deel in de interessegebieden. In extreme gevallen, bijvoorbeeld een zeer slechte verbinding,kan zelfs de volledige achtergrond worden weggelaten Selectie van interessegebieden: een hulpprogramma Het automatisch volgen van objecten is nog steeds een moeilijke taak. In het kader van deze thesis is een programma ontwikkeld dat manuele selectie toestaat. Het toont het laatst geselecteerde interessegebied en laat de gebruiker eventueel een nieuw interessegebied specifiëren. Dit laatste kan handig zijn waneer het object zich verplaatst. Een screenshot van het programma is te zien in Figuur 30. Figuur 30 : Screenshot van het programma om interessegebieden de selecteren 57