Digitale video: een overzicht van de JVT/AVC-standaard

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Digitale video: een overzicht van de JVT/AVC-standaard door Mieke Depaemelaere Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleiders: lic. W. De Neve en lic. P. Lambert Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar

2 Dankwoord Eerst en vooral een woord van dank aan de mensen die mij gedurende het afgelopen academiejaar geholpen hebben om deze scriptie te kunnen realiseren. In de eerste plaats ben ik mijn ouders zeer dankbaar voor hun geduld, bemoedigende woordjes en de tijd die ook zij in deze scriptie hebben gestoken. Ze hebben me gesteund en waren zeer begripvol in de periodes dat het niet wilde vlotten en hebben me gestimuleerd om verder te werken en niet op te geven. Ook wil ik mijn zus Griet en Les danken. De morele steun die ik soms nodig had, vond ik zeker ook bij hen. Mijn promotor, Rik Van de Walle en begeleiders, Wesley en Peter wil ik uiteraard ook bedanken. Wesley en Peter waren altijd bereid tijd voor me vrij te maken en hebben me gedurende het hele academiejaar veel informatie en raad gegeven. Bovendien hebben ze me de vrijheid gegeven om op mijn eigen manier te werk te gaan. Een laatste woordje van dank gaat uit naar enkele medestudenten en kotgenootjes: Laurence, Els, Iris, Lore, Hanne, Kathlyn, Nelly, Tina, Marieke, Wim, Tom, Ilse, Tine, Jeroen, Ine, Stijn, Sofie, Evelien, Klaerke en Sofie hebben me het leven deze laatste, soms zware werkweken heel wat aangenamer gemaakt. i

3 De toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren 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

4 Digitale video: een overzicht van de JVT/AVC-standaard door Mieke Depaemelaere Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleiders: lic. W. De Neve en lic. P. Lambert Samenvatting Trefwoorden: JVT/AVC-standaard, videocompressie, videocoderingslaag, netwerkabstractielaag, compressie-efficiëntie De compressie van video is een belangrijk onderdeel van veel hedendaagse multimediatoepassingen. Applicaties zoals DVD, satelliettelevisie en het stromen van video over het Internet, hebben beperkingen op de netwerkbandbreedte of op de opslagcapaciteit waardoor er een blijvende vraag is naar steeds efficiëntere compressietechnieken. Voor al deze verschillende toepassingen zijn er reeds verscheidene standaarden ontwikkeld, zoals bijvoorbeeld de MPEG-4- en H.263-standaard. Binnenkort zal een nieuwe standaard, de JVT/AVC-standaard het licht zien. Deze standaard is ontstaan uit de samenwerking tussen de Moving Pictures Experts Group van het ISO en de Video Coding Experts Group van het ITU-T. De doelstellingen bij het ontwikkelen van de JVT/AVC-standaard waren het bereiken van een verbeterde compressie-efficiëntie, het voorzien van een netwerkvriendelijke representatie en de specificatie van de syntax zo eenvoudig mogelijk houden. Men wilde een vermindering in bitsnelheid van 50% bekomen in vergelijking met eerdere standaarden en dit met behoud van kwaliteit. In deze scriptie wordt eerst en vooral een overzicht gegeven van de structuur en het ontwerp van de JVT/AVC-standaard. Er wordt uitgebreid ingegaan op de werking van de verschillende functionele eenheden waaruit de codec is opgebouwd en het verschil met eerdere standaarden wordt aangetoond. Daarnaast wordt een nieuw concept uit deze standaard namelijk, wisselbeelden, uitgelegd. Dit maakt het iii

5 efficiënt overschakelen tussen bitstromen mogelijk en kan daarom gebruikt worden voor een soort van schaalbare videocodering. Vervolgens wordt uitgelegd hoe de afbeelding naar het netwerk gebeurt. In het tweede deel van deze scriptie zal een overzicht gegeven worden van enkele experimenten die werden uitgevoerd met de referentiesoftware van de JVT/AVCstandaard. Het belangrijkste experiment geeft een vergelijking van de prestatie van de JVT/AVC-standaard en verschillende eerdere standaarden en ook bedrijfseigen videocompressietechnologie. Uit de voorgaande delen kan worden besloten dat de compressie-efficiëntie van de JVT/AVC-standaard inderdaad zeer goed is, maar dat rekening moet worden gehouden met de verhoogde geheugen- en rekencomplexiteit. Deze standaard biedt zeker een antwoord op bedrijfseigen initiatieven, maar de verspreiding kan misschien wat moeilijkheden ondervinden. Dit komt omdat de standaard niet compatibel is met de huidige, vaak gebruikte standaard namelijk, MPEG-4 deel 2 en er momenteel nog geen zekerheid is dat de licentie voor het Baseline Profile gratis zal zijn. iv

6 Inhoudsopgave 1 Inleiding Situering Doelstellingen Structuur Digitale video en compressie Inleiding Digitale video Structuur Kleurenruimtes Kwaliteit van video Standaardformaten voor digitale video Videocompressie Waarom compressie? Videocodec De JVT/AVC-standaard Ontstaan en standaardisatie van de JVT/AVC-standaard De JVT/AVC-codec De JVT/AVC-lagenstructuur Videocoderingslaag Beknopte beschrijving van de functionele eenheden Onderverdeling van een beeld Intravoorspelling Intervoorspelling v

7 3.3.4 Transformatie en quantisatie Entropiecodering Antiblokfilter Toepassingen Baseline Profiel Main Profiel Extended Profiel Detailstudie van de functionele eenheden Intravoorspelling Voorspelling voor 4x4-luminantieblokken Voorspelling voor 16x16-luminantieblokken Voorspelling voor de chrominantiecomponenten Intervoorspelling P-macroblokken B-macroblokken Subpixelbewegingsvectoren Codering van de bewegingsvectoren Transformatie en quantisatie Transformatie en quantisatie voor de 4x4-blokken met residudata (blokken 0-15 en 18-25) Transformatie en quantisatie voor de 4x4-DC-matrix van de luminantiecomponent (blok -1) Transformatie en quantisatie van de 2x2-DC-matrices van de chrominantiecomponenten (blokken 16 en 17) Het volledige transformatie-, quantisatie- en herschalingsproces VLC-gebaseerde entropiecodering UVLC CAVLC CABAC-gebaseerde entropiecodering Omzetting van symbolen in een binaire representatie Codeerproces De antiblokfilter vi

8 5 Schaalbaarheid in de JVT/AVC-standaard Schaalbare videocodering Schaalbaarheid Overzicht van de technieken voor schaalbare videocodering Schaalbaarheid in de JVT/AVC-standaard FGS met JVT/AVC-codering in de basislaag Temporele schaalbaarheid in de JVT/AVC-standaard Wisselbeelden SP-beelden Codering en decodering van SP-beelden SI-beelden Foutbestendigheid De netwerkabstractielaag Inleiding Concept van de netwerkabstractielaag Gecodeerde slice (NAL-eenheidtype 1) Datapartitionering (NAL-eenheidtypes 2,3 en 4) Parameter sets Supplemental Enhancement Information (NAL-eenheidtype 6) Andere NAL-eenheden Bytestroomformaat Praktisch deel Bespreking van een tracebestand NAL-eenheden SPS PPS Gecodeerde slice van het IDR-beeld (lijn ) Gecodeerde slice van het eerste P-beeld Gecodeerde slice van het eerste B-beeld (lijn ) Experimenten met de referentiesoftware Wisselwerking tussen de quantisatieparameter en de bitsnelheid116 vii

9 7.2.2 Vergelijking efficiëntie CABAC ten opzichte van UVLC/CAVLC Vergelijking van de codeerefficiëntie van P- en SP-beelden ten opzichte van I-beelden Efficiëntie van het gebruik van meerdere referentiebeelden Codering aan lage bitsnelheid Vergelijkende test: deel Vergelijkende test: deel Besluit 146 A Afkortingen 148 B Berekeningen 150 B.1 Omvorming van de 4x4-DCT tot de 4x4-geheelwaardige transformatie 150 C Tracebestand 152 D Figuren 164 E CD-ROM met testresultaten 171 Bibliografie 173 viii

10 Lijst van figuren 1.1 Ontwikkeling van videocoderingsstandaarden Opbouw van een digitale videosequentie Interlaced video Onderbemonsteringsformaten voor chrominantie Voorbeeld van een JND-map Beeldformaten Videocodec Onderverdeling van een beeld in macroblokken en opbouw van een macroblok Typische sequentie met I-, P- en B-beelden Origineel blok (a) en getransformeerd blok door middel van DCT (b) Gequantiseerd blok Gereconstrueerd blok (a) en het verschilblok (b) Sequentieel ordenen van de gequantiseerde coëfficiënten door zigzagscan (run,level)-codering ITU-T-recommendations en ISO/IEC-standaarden Lagenstructuur van de JVT/AVC-standaard JVT/AVC-encoder Gebruikte samples bij intra-4x4-voorspelling Voorspellingsrichting voor de verschillende modi voor intra-4x4-codering Intramodi Origineel macroblok en te voorspellen 4x4-blok Voorbeeld: intravoorspelling van een 4x4-blok ix

11 4.6 Naburige intragecodeerde 4x4-blokken Intra-16x16-voorspellingsmodi Te voorspellen 16x16-luminantieblok Intra-16x16 voorspellingen DC-voorspelling voor 8x8-blokken van chrominantiesamples Blokgroottes voor intervoorspelling Bidirectionele voorspelling Multihypothese-voorspelling Naburige blokken die gebruikt worden voor de voorspelling van de bewegingsvector Voorspelling van de bewegingsvector voor 8x16- en 16x8-partities Volgorde transformatie Overzicht van het transformatie- en quantisatieproces Volgorde van filtering in een macroblok Twee aangrenzende blokken (p en q) Samples gebruikt bij toepassing antiblokfilter Beeld uit foreman met de antiblokfilter (a) en zonder de antiblokfilter (b) Detail van een beeld met de antiblokfilter (a) en zonder de antiblokfilter (b) Systeemconfiguratie voor toepassing gericht op het stromen van data over het Internet Prestatie van verschillende soorten videocodering Structuur van een videosequentie bij temporele schaalbaarheid Vermindering van het aantal kb bij het weglaten van alle B-beelden (stefan) Vermindering van het aantal kb bij het weglaten van alle B-beelden (foreman) Moeilijkheden bij het overschakelen tussen 2 bitstromen Overschakelen tussen 2 bitstromen met behulp van een I-beeld Overschakelen tussen 2 bitstromen met behulp van SP-beelden Random access met behulp van SP-beelden Fast forward met behulp van SP-beelden x

12 5.11 Encoderen van een SP-beeld Decoderen van een SP-beeld Encoderen van SP-wisselbeeld Decoderen van een SP-wisselbeeld Splicing met behulp van SP- en SI-beelden Foutbestendigheid door gebruik van SP-beelden JVT/AVC-standaard en de transportlaag Volgorde transformatie Blok 0 van macroblok 0 van het IDR-beeld Blok 1 van macroblok 0 van het IDR-beeld Twee blokken met de DC-coëfficiënten van de chrominantiecomponenten Wisselwerking QP - bitsnelheid Beeld gecodeerd met QP=51 (ongefilterd en gefilterd) Wisselwerking QP - aantal bits per beeldtype (Foreman) Winst bij gebruik van CABAC in vergelijking met UVLC/CAVLC (news) Winst bij gebruik van CABAC in vergelijking met UVLC/CAVLC (container) Encoderingstijd bij gebruik van CABAC en UVLC/CAVLC voor een sequentie met P- en B-beelden (container) Vergelijking van de codeerefficiëntie van P- en SP-beelden ten opzichte van I-beelden (foreman) Vergelijking van de codeerefficiëntie van P- en SP-beelden ten opzichte van I-beelden (container) Vergelijking prestatie bij coderen aan lage beeldsnelheden (stefan) Vergelijking prestatie codecs (foreman) Vergelijking prestatie codecs (stefan) Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (foreman) Fluctuatie Y-PSNR-waarden 2100 kbps voor verschillende codecs (foreman) Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) xi

13 7.19 Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) Beelden 180 tot en met 185 uit de originele sequentie en de gecodeerde sequentie met DivX 5.04 tegen 2100 kbps (stefan) Deel van het logbestand bij het coderen van stefan (2100 kbps - DivX) Vergelijking prestatie JVT/AVC en 3D-EZBC (stefan) Vergelijking prestatie JVT/AVC en 3D-EZBC (foreman) Vergelijking prestatie JVT/AVC en andere codecs (stefan) Vergelijking prestatie JVT/AVC en andere codecs (foreman) D.1 Vergelijking prestatie codecs (foreman) D.2 Vergelijking prestatie codecs (stefan) D.3 Beelden 180 tot en met 185 uit de originele sequentie en de gecodeerde sequentie met DivX 5.04 tegen 2100 kbps (stefan) D.4 Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (foreman) D.5 Fluctuatie Y-PSNR-waarden 2100 kbps voor verschillende codecs (foreman) D.6 Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) D.7 Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) D.8 Vergelijking prestatie JVT/AVC en andere codecs (stefan) D.9 Vergelijking prestatie JVT/AVC en andere codecs (foreman) D.10 Vergelijking alle codecs (stefan) D.11 Vergelijking alle codecs (foreman) xii

14 Lijst van tabellen 2.1 Populaire beeldresoluties Golomb- en Rice-codes voor de parameters m=1 tot m=5 en parameter m= Onderdelen van MPEG Toegelaten macrobloktypes voor de verschillende slicetypes DC-voorspellingsmodus voor 4x4-luminantieblokken DC-voorspellingsmodus voor chrominantieblokken Waarden voor Qstep geïndexeerd volgens QP Positie van de schaalfactoren MF-waarden Waarden van de herschalingsfactor V Opbouw codewoorden voor de exponentiële Golomb-codering Codewoorden voor de exponentiële Golomb-codering Signed mapping Keuze tabel voor coeff token Grenswaarden die bepalen of het level tabelnummer wordt verhoogd Unaire binairisatie Overschakelen van stroom A naar stroom B door middel van SP-beelden NAL-eenheidtypes Gegevens voor het genereren van het tracebestand uit appendix C Lijn 1 uit het tracebestand Gegevens test xiii

15 7.4 Bitsnelheid en Y-PSNR-waarde bij maximale compressie Gegevens test Gegevens test Gegevens test Vergelijking gebruik van één ten opzichte van vijf referentiebeelden (30 beelden) Vergelijking gebruik van één ten opzichte van vijf referentiebeelden (120 beelden) Gegevens test Opgegeven bitsnelheid en benaderde bitsnelheid bij gebruik van ratecontrol Gegevens test Beeldnummer en PSNR-waarde bij coderen van de sequentie stefan aan 2100 kbps Winst in bitsnelheid van de JVT/AVC-standaard ten opzichte van DixX xiv

16 Hoofdstuk 1 Inleiding 1.1 Situering Sinds een tiental jaren kent de markt van de digitale video een spectaculaire groei. Er worden steeds nieuwe toepassingen ontwikkeld, gaande van digitale telefonie en videoconferenties tot DVD en digitale televisie. Deze grote expansie is hoofdzakelijk te danken aan de opkomst van goedkope en toch krachtige processors, snelle netwerktoegang, het Internet, grootschalig onderzoek en de ontwikkeling van videocoderingsstandaarden. Door beperkingen op de netwerkbandbreedte en de capaciteit van opslagmedia enerzijds en de eisen van gebruikers zoals video van hoge kwaliteit, snelle levering en een redelijke prijs anderzijds, was het noodzakelijk methodes te ontwikkelen om videosignalen te comprimeren. Tegenwoordig zijn er al tal van efficiënte standaarden ontwikkeld, elk bedoeld voor een specifieke groep van toepassingen. Deze zorgen voor interoperabiliteit tussen platformen en systemen van verschillende fabrikanten. Twee organisaties houden zich momenteel bezig met de ontwikkeling van videocoderingsstandaarden. De eerste is the International Telecommunications Union, Telecommunication Standardization Sector (ITU-T) en de tweede is the International Standardization Organization/International Electrotechnical Commission, Joint Technical Committee 1 (ISO/IEC JTC1). Binnen deze twee organisaties werken teams van deskundigen samen aan de ontwikkeling van videocoderingsstandaarden. Binnen het ISO/IEC is dit de Moving Picture Experts Group of kortweg MPEG. MPEG heeft de standaarden MPEG-1, MPEG-2, MPEG-4, MPEG-7 en 1

17 MPEG-21 ontwikkeld. Het belangrijkste toepassingsgebied waar MPEG zich op richt is de opslag van video (DVD), het broadcasten van video (kabel-, satelliet-, DSL-televisie) en toepassingen gericht op het stromen van videodata (video over het Internet of draadloos). In het ITU-T komt de ontwikkeling van videocoderingsstandaarden tot stand in de Video Coding Experts Group. De standaarden die door hen werden ontwikkeld, namelijk H.261, H.262 en H.263, worden Recommendations genoemd en zijn vooral bedoeld voor waretijdstoepassingen zoals videoconferentie en videotelefonie. De MPEG-2/H.262 standaard is uit de samenwerking van MPEG en VCEG ontstaan. Enkele jaren geleden hebben de twee groepen opnieuw hun krachten gebundeld met de oprichting van het Joint Video Team (JVT) voor de ontwikkeling van de H.264- of MPEG-4 AVC-standaard. Deze nieuwe standaard vormt het onderwerp van deze scriptie. In figuur 1.1 worden de twee standaardisatiegroepen, de teams van deskundigen en de ontwikkelde standaarden nog eens afgebeeld. ISO MPEG VCEG MPEG-1 MPEG-2 H.262 H.261 MPEG-7 MPEG-4 H.264 MPEG-21 H.263 Figuur 1.1: Ontwikkeling van videocoderingsstandaarden In de scriptie wordt verder de naam JVT/AVC-standaard (Joint Video Team/ Advanced Video Coding-standaard) gebruikt. 2

18 1.2 Doelstellingen Een eerste doelstelling van deze scriptie was inzicht te verwerven in algemene principes van videocodering. Vervolgens werd de werking van de JVT/AVC-standaard onderzocht. Hierbij werd gekeken naar het toepassingsgebied en doelstellingen van de JVT/AVC-standaard. Verder was het de bedoeling om de werking van de functionele eenheden en de verschillen in vergelijking met eerdere standaarden te onderzoeken en er een duidelijk overzicht van te geven. De tweede doelstelling was het nagaan van de prestatie van deze codec. Hierbij werd de complexiteit versus de efficiëntie van de JVT/AVC-standaard nagegaan en werd ook een vergelijking gemaakt met andere codecs. Er werd geprobeerd om dit alles in deze scriptie duidelijk weer te geven, zodat deze voor andere personen als naslagwerk kan dienen. 1.3 Structuur Volgende paragrafen geven een overzicht van de structuur van deze scriptie. Globaal gezien zijn er twee grote delen. Het eerste deel (hoofdstukken 2 tot 6) omvat het theoretisch gedeelte waarvan een klein stuk gewijd is aan algemene principes van videocodering. Het grootste stuk handelt echter specifiek over de JVT/AVCstandaard. Het tweede deel (hoofdstuk 7) handelt over het praktisch gedeelte van deze scriptie. In hoofdstuk 2 wordt een overzicht gegeven van de terminologie en enkele algemene concepten aangaande digitale video en videocompressie worden geïntroduceerd. Hoofdstuk 3 is een inleidend hoofdstuk over de JVT/AVC-standaard. Er wordt ingegaan op de ontwikkeling, de doelstellingen en de toepassingen van de standaard. Vervolgens wordt er een algemeen beeld geschetst van de verschillende componenten waaruit de codec is opgebouwd. In hoofdstuk 4 wordt een bespreking gegeven van de videocoderingslaag van de JVT/AVC-standaard. Er wordt uitgebreid ingegaan op de functionele eenheden 3

19 waaruit de JVT/AVC-codec is opgebouwd, namelijk intra- en intervoorspelling, transformatie en quantisatie, de verschillende mogelijkheden tot entropiecodering en de antiblokfilter. Hoofdstuk 5 bespreekt de mogelijkheid tot schaalbaarheid in de JVT/AVCstandaard. Eerst worden de term schaalbaarheid en de bedoeling ervan uitgelegd. Daarna wordt een nieuw concept uit de standaard, namelijk wisselbeelden, besproken die mogelijk efficiënt kunnen gebruikt worden in sommige toepassingen met schaalbaarheid. Hoofdstuk 6 handelt over de netwerkabstractielaag. In deze laag wordt de gecodeerde video afkomstig uit de videocoderingslaag verwerkt in eenheden zodat een afbeelding naar verschillende types van netwerken mogelijk is. Hoofdstuk 7 geeft een bespreking van de uitgevoerde testen. Het eerste deel bevat een bespreking van een tracebestand om de werking van de JVT/AVC-standaard te verduidelijken. Het tweede deel geeft een overzicht van de verschillende testen die werden uitgevoerd met de referentiesoftware om de complexiteit en de prestatie van de JVT/AVC-standaard te onderzoeken. Deze scriptie wordt uiteindelijk afgesloten met een besluit. Verder zijn er ook nog enkele appendices in deze scriptie opgenomen: Appendix A bevat een lijst met vaak gebruikte acroniemen en hun betekenis. Appendix B bevat enkele wiskundige berekeningen die eerder als achtergrondinformatie dienen. Appendix C bevat een stuk van het tracebestand dat in het eerste deel van hoofdstuk 7 werd besproken. In appendix D werden enkele grafieken die ook in hoofdstuk 7 aanwezig zijn, voor de duidelijkheid in kleur opgenomen. Appendix E bevat tenslotte een CD-ROM waarop alle bekomen resultaten, de gebruikte software, het tracebestand en enkele handige documenten werden verwerkt. 4

20 Hoofdstuk 2 Digitale video en compressie 2.1 Inleiding Alvorens meer in detail in te gaan op de JVT/AVC-standaard, wordt in dit hoofdstuk een overzicht gegeven van specifieke terminologie en concepten die verwant zijn met digitale video en compressie. Voor een meer gedetailleerde bespreking kunnen onder meer [23] en [15] geraadpleegd worden. Digitale video is visuele informatie die gerepresenteerd wordt in een discrete vorm, geschikt voor digitale opslag en transmissie. Eerst wordt de opbouw van een digitale videosequentie besproken, gevolgd door een beschrijving van de methodes gebruikt voor efficiënte compressie en transmissie. 2.2 Digitale video Structuur Een digitaal beeld is de projectie van een 3-dimensioneel tafereel op een 2-dimensioneel vlak. De continuïteit van een echte scène, zowel in tijd en ruimte, moet worden vertaald naar een discrete representatie. Spatiaal (ruimtelijk) wordt een beeld op een bepaald (rechthoekig) vlak voorgesteld bestaande uit beeldpunten. Temporeel (tijdsgebonden) bestaat een videosequentie uit een reeks beelden die elkaar opvolgen op vaste tijdstippen. Video bestaat dus niet uit bewegende beelden, de beweging 5

21 wordt gesimuleerd door het snel op elkaar volgen van beelden. Dit wordt verduidelijkt in figuur 2.1. ruimtelijke representatie temporele representatie Figuur 2.1: Opbouw van een digitale videosequentie De visuele kwaliteit van een beeld wordt bepaald door het aantal beeldpunten. Een groter aantal beeldpunten zorgt voor een betere kwaliteit, maar vereist ook een grotere opslagcapaciteit. In tabel 2.1 wordt een overzichtje gegeven van enkele veel voorkomende beeldresoluties 1. Naam Resolutie (lines x pixels) Sub-QCIF 128 x 96 QCIF 176 x 144 SIF 352 x 240 CIF 352 x 288 NTSC - Analoog 704 x 480 NTSC - Digitaal 720 x 480 PAL - Analoog (4CIF) 704 x 576 PAL - Digitaal (SDTV - progressive scan) 720 x CIF 1408 x 1152 HDTV (1080p) 1920 x 1080 Tabel 2.1: Populaire beeldresoluties Verder bepaalt het aantal beelden per seconde ook de visuele kwaliteit van bewegend beeld. Dit wordt de temporele resolutie (beeldsnelheid) genoemd. Een hogere 1 In [12], Annex A, tabel A-5 wordt een uitgebreider overzicht gegeven van frequent gebruikte beeldresoluties. 6

22 temporele resolutie zorgt voor een vloeiender uitzicht, maar daarvoor moeten meer beelden worden opgeslagen, wat opnieuw een hogere opslagcapaciteit vereist. Interlaced en progressive scan video Analoge of digitale video (of televisie) kan onderverdeeld worden volgens het gebruik van interlaced of progressive scanning. NTSC, PAL en SECAM zijn standaarden die gebruik maken van interlacing en worden toegepast bij het tonen van televisiebeelden. Bij interlaced video wordt elk beeld opgedeeld in twee velden (fields), namelijk het bovenste en het onderste veld. Elk veld bevat de helft van de lijnen van het originele beeld. Het onderste veld bevat alle even lijnen en het bovenste alle oneven lijnen. Dit wordt getoond in figuur 2.2. Door de twee velden afwisselend te tonen, kan de temporele resolutie verdubbeld worden, maar de totale hoeveelheid data blijft gelijk. Het eerste veld dat wordt afgebeeld, toont de helft van de lijnen van het originele beeld. Het tweede veld vult de andere lijnen op. Bijvoorbeeld, PAL- en SECAM-beelden getoond aan 25 Hz, bevatten twee velden getoond aan 50 Hz. NTSC-video toont de velden aan 60 Hz, dus een volledig beeld wordt getoond aan 30 Hz. Volledig beeld Bovenste veld Onderste veld Figuur 2.2: Interlaced video 7

23 Video die gebruikmaakt van progressive scan, toont telkens het volledige beeld. Bijvoorbeeld, computermonitors tonen het beeld als progressive scan. Meer informatie hierover is onder andere te vinden in [4] [23] [17] Kleurenruimtes Een digitale afbeelding wordt opgeslagen als een verzameling beeldpunten of pixels. Bij een zwart/wit-beeld (monochroom) volstaat één waarde per pixel. Deze waarde stelt de luminantie of helderheid (grijswaarde) voor. Een hoge waarde betekent een helder beeldpunt. Doorgaans wordt luminantie gerepresenteerd door 8 bits per pixel. Voor gespecialiseerde toepassingen zoals medische beelden worden soms 12 bits per pixel gebruikt. Bij het gebruik van 8 bits wordt de kleur zwart voorgesteld door de waarde 0 en wit door de waarde 255. Voor de voorstelling van kleur zijn er meerdere waarden (samples) per pixel vereist. Er bestaan verschillende systemen voor de representatie van kleur, deze worden kleurenruimtes genoemd. De meest gebruikte kleurenruimtes RGB (Rood/ Groen/ Blauw) en YCbCr (Luminantie/ Blauwe Chrominantie/ Rode Chrominantie) worden in volgende paragrafen besproken. [23] [27] RGB In de RGB-kleurenruimte wordt elk pixel voorgesteld door drie getallen die de relatieve hoeveelheid rood, groen en blauw aangeven. Dit zijn de drie additieve primaire kleuren waaruit licht is opgebouwd. Elke andere kleur kan bekomen worden door de drie kleuren in bepaalde proporties met elkaar te combineren. De drie kleurcomponenten hebben ongeveer dezelfde belangrijkheid en worden daarom met dezelfde precisie voorgesteld. Veelal worden er 8 bits per component gebruikt, wat dus wil zeggen dat voor elk pixel 24 bits nodig zijn. RGB is geen efficiënte manier om kleur voor te stellen. Het menselijk oog is doorgaans beter in staat om helderheid (luminantie) waar te nemen dan kleur. Het gebruik van de RGB-kleurenruimte maakt het niet mogelijk om deze eigenschap te gebruiken voor een compactere voorstelling omdat helderheid aanwezig is in alle drie de componenten. Een ander kenmerk van het oog is dat het meest gevoelig is voor groen, daarna rood en het minst voor blauw. 8

24 YCbCr YCbCr is een kleurenruimte die informatie over helderheid en kleur van elkaar scheidt. De Y-component is de luminantiecomponent en die zorgt dus voor een monochrome voorstelling. Y is het gewogen gemiddelde van R, G en B, waarbij de R-, G- en B-waarden in het interval [0,1] liggen: Y = k r R + k g G + k b B (2.1) waarbij de k-waarden gewichtsfactoren zijn met de waarden: k r = k g = k b = (2.2) Kleurinformatie wordt voorgesteld door het verschil tussen de kleur Rood, Groen en Blauw en de luminantie: Cr = R Y Cb = B Y Cg = G Y (2.3) De som van de drie chrominantiecomponenten, namelijk Cr + Cb + Cg, is gelijk aan een constante, waardoor twee van de componenten volstaan voor de kleurinformatie. De derde component kan immers afgeleid worden uit de andere twee. In de YCbCrkleurenruimte is de groene chrominantiecomponent weggelaten. De uiteindelijke vergelijkingen om een RGB-beeld om te zetten naar de YCbCr-kleurenruimte zijn: Y = 0.299R G B Cb = (B Y ) Cr = (R Y ) (2.4) Het grote voordeel van de YCbCr-voorstelling is dat de Cb- en Cr-componenten kunnen worden voorgesteld met een lagere resolutie dan de Y-component. Dit wordt ook wel onderbemonstering of subsampling van kleur genoemd. Bij een 4:4:4- onderbemonsteringsformaat wordt er geen informatie weggelaten. Bij een 4:2:2- formaat is de chrominantie horizontaal bemonsterd. De chrominatiecomponenten hebben horizontaal de helft van de nauwkeurigheid van de luminantie. Bij een 4:2:0-formaat is de chrominantie in twee dimensies bemonsterd, wat wil zeggen dat voor de Cb- en Cr-componenten zowel horizontaal als verticaal de helft van de nauwkeurigheid van de luminantie wordt gebruikt. Een illustratie van de verschillende formaten is te zien in figuur 2.3. Meer infor- 9

25 matie over deze kleurenruimte is te vinden in [9] en [27]. 4:4:4 4:2:2 4:2:0 Y-component Cb-component Cr-compontent Figuur 2.3: Onderbemonsteringsformaten voor chrominantie Kwaliteit van video Om een vergelijking te kunnen maken tussen verschillende codecs (zie paragraaf 2.3.2), moet de kwaliteit van het beeld na reconstructie kunnen worden beschreven. Dit is niet zo gemakkelijk omdat er vele factoren zijn die de kwaliteit van een beeld bepalen. Visuele kwaliteit is eigenlijk subjectief en dit maakt het moeilijk een kwaliteitsmaat op te stellen. Een maat voor videokwaliteit kan ook gegeven worden op basis van objectieve criteria, maar er is slechts een benaderend verband met de zichtbare fouten waargenomen door het menselijk oog. Vaak gebruikte objectieve maten voor beeldkwaliteit zijn de Peak Signal to Noise Ratio (PSNR) en het Just Noticeable Distortion Model (JND-model). PSNR De berekening van de PSNR-waarde komt overeen met het bepalen van de Euclidische afstand tussen twee beelden. Volgende vergelijking geeft aan hoe de PSNR- 10

26 waarde (uitgedrukt in decibels) berekend wordt : P SNR db = 10 log 10 (2 n 1) 2 MSE = 20 log 10 (2 n 1) MSE (2.5) In vergelijking 2.5 is n gelijk aan het aantal bits waarmee het sample wordt voorgesteld (typisch 8 bits). De Mean Squared Error (MSE) voor een NxM beeld met f het originele beeld en f het gereconstrueerde beeld, wordt gegeven door: MSE = 1 N M N 1 x=0 M 1 y=0 Voor identieke beelden is de MSE gelijk aan nul. [f(x, y) f (x, y)] 2 (2.6) De PSNR-waarde wordt gemeten op een logaritmische schaal en geeft de verhouding weer tussen de MSE en het hoogst mogelijke signaal (typisch 255). In het algemeen is de kwaliteit van een beeld relatief hoog als de PSNR hoog is en omgekeerd. Toch wijst een hogere PSNR-waarde niet altijd op een hogere subjectieve kwaliteit bij de vergelijking van twee beelden. [18] JND-model Het JND-model is een objectieve kwaliteitsmaat die rekening houdt met de eigenschappen van het menselijk visueel systeem. Het model heeft als input het origineel beeld en het gereconstrueerd beeld. Op basis van deze twee beelden wordt een JNDmap berekend. De samplewaarden in de JND-map worden beschreven in eenheden van JND s. Een JND van waarde 1 komt overeen met een kans van 75% dat het verschil tussen de twee beelden zal worden gezien. Een JND van waarde 2 komt overeen met een kans op zichtbaarheid van 93,75% (0, , 75 (1 0, 75)). Een voorbeeld wordt getoond in figuur 2.4. De helderheid van de samples bepaalt de grootte van het verschil tussen het origineel beeld. Naast de grootte geeft de JNDmap ook de plaats van de JND s weer. Deze informatie kan bijvoorbeeld de encoder helpen om meer bits toe te wijzen aan deze regio s. Uitgebreide informatie over het JND-model kan gevonden worden in [1] [3]. 11

27 Origineel beeld Gereconstrueerd beeld JND-map Figuur 2.4: Voorbeeld van een JND-map Standaardformaten voor digitale video Voor toepassingen van digitale video, wordt de video vaak eerst geconverteerd naar een intermediair formaat. Een populaire set van resoluties is gebaseerd op het Common Intermediate Format (CIF), waarbij elk beeld een resolutie heeft van 352 x 288 pixels. De formaten zijn voorgesteld in figuur Videocompressie Waarom compressie? Videocompressie is noodzakelijk voor de transmissie van digitale video over de hedendaagse netwerken met beperkte bandbreedtes of om compacte opslag mogelijk te maken. Een twee uur durende video zou zonder compressie een opslagcapaciteit van ongeveer 194 Gbytes vereisen, wat overeenkomt met 42 DVD s. Maar videocompressie is niet alleen belangrijk voor deze grote bestanden. Tegen- 12

28 4CIF 704 x 576 CIF 352 x 144 QCIF 176 x 144 SQCIF 128 x 96 Figuur 2.5: Beeldformaten woordig bevatten bijvoorbeeld heel veel websites korte stukjes video of muziek. Al deze bestandjes moeten opgeslagen worden op een server. Zelfs al lijkt één kort videofilmpje niet groot, dan mag er niet vergeten worden dat dit ene filmpje één van de zeer vele is. De som van de grootte van al deze kleine bestandjes loopt snel op. Ook hier is dus compressie nodig Videocodec Compressie van digitale video is mogelijk omdat een videosequentie bestaat uit een groot deel redundante informatie. Deze redundantie kan statistisch (spatiaal of temporeel) en subjectief (gerelateerd aan de karakteristieken van het menselijk visueel systeem) zijn. Spatiale statistische redundantie wordt verklaard doordat de waarden van naburige samples sterk gecorreleerd zijn (bijvoorbeeld de achtergrondkleur is vaak over grote gebieden gelijkaardig) en temporele statistische redundantie is aanwezig door de correlatie van de opeenvolgende videobeelden. Het grootste percentage van compressie wordt bereikt door het verwijderen (verminderen) van temporele redundantie. De compressiefactor is een maat voor de hoeveelheid compressie 13

29 en wordt gegeven door: Compressief actor = originele grootte gecomprimeerde grootte (2.7) Een videocodec is een encoder-decoder paar dat zorgt voor de compressie en decompressie van digitale video. Figuur 2.6 geeft een beeld van de typische opbouw van een videocodec. Het verwijderen van de statistische redundantie gebeurt in de entropiecoderingsfase. De meest efficiënte (in termen van complexiteit) entropiecoders gaan uit van een stationaire bron die statistisch onafhankelijke symbolen genereert. Daarom wordt het beeld eerst via broncodering omgezet in een andere representatie. Broncodering reduceert de data en vertaalt deze in symbolen die minder gecorreleerd zijn dan de originele data. origineel videosignaal bronencoder symbolen entropie-encoder gecomprimeerde data opslag / transmissie gedecodeerd videosignaal brondecoder entropiedecoder Figuur 2.6: Videocodec Om de video te decomprimeren moet achtereenvolgens de inverse entropiecodering en de inverse broncodering worden toegepast. Als het gereconstrueerde signaal identiek is aan het originele wordt gesproken van verliesloze compressie. Anderzijds, als er een vermindering aan kwaliteit is of vervorming na reconstructie, wordt gesproken over verlieshebbende compressie. Het coderen van video is meestal een proces met verlies. [23] 14

30 Blokgebaseerde voorspelling Een videosequentie is opgebouwd uit een reeks beelden bestaande uit drie matrices met pixelinformatie, één voor de luminantiecomponent en twee voor de chrominantiecomponenten. Elk beeld wordt verder onderverdeeld in een reeks macroblokken. Een macroblok bestaat uit een matrix van 16x16 luminantiesamples en twee matrices met chrominantiesamples. Het aantal chrominantiesamples is afhankelijk van het gebruikte onderbemonsteringsformaat. Macroblokken worden gegroepeerd tot slices zodanig dat elk macroblok tot juist één slice behoort. In figuur 2.7 wordt dit geïllustreerd voor een QCIF-beeld. Het beeld wordt onderverdeeld in 99 macroblokken. De structuur van één van deze macroblokken is ook in de figuur te zien. Het onderbemonsteringsformaat is 4:2:0, wat wil zeggen dat de matrices van de chrominantiecomponenten bestaan uit 64 elementen (8x8). Y slice Cb 8 Cr macroblok Figuur 2.7: Onderverdeling van een beeld in macroblokken en opbouw van een macroblok Inter- en intracodering Een beeld kan individueel gecomprimeerd worden, dit wordt intracodering genoemd. Een betere compressie wordt echter bereikt door het exploiteren van de temporele redundantie in een videosequentie. Dit wordt bekomen doordat een voorspelling van het huidige beeld wordt gemaakt op basis van één of meerdere referentiebeelden. 15

31 Deze voorspelling wordt vervolgens afgetrokken van het huidige beeld wat het residubeeld oplevert. Het berekenen van het residubeeld uit de voorspelling wordt ook wel Motion Compensation (MC) genoemd. Het coderen van beelden gebaseerd op hun relatie met eerder gecodeerde videobeelden wordt intercodering genoemd. Intercodering is zeer efficiënt wanneer opeenvolgende beelden sterk op elkaar lijken. Dit is het geval wanneer er weinig beweging in de sequentie voorkomt. Wanneer er veel beweging aanwezig is, zal het residubeeld ook veel informatie bevatten. Een betere prestatie kan worden bereikt wanneer een schatting wordt gemaakt van de beweging. Dit wordt Motion Estimation (ME) genoemd. Voor een bepaald macroblok op een zekere positie in het huidige beeld wordt in het referentiebeeld gezocht naar de beste match (beste benadering van het huidige blok) in de buurt van deze positie. Deze match geeft het kleinste verschil bij de MC. Naast het doorsturen van het verschil, moet per macroblok ook een bewegingsvector worden doorgestuurd, die de locatie aangeeft van deze beste match. Het opstellen van de voorspelling kan op twee verschillende manieren. Er kan gebruikgemaakt worden van referentiebeelden die het huidige beeld voorafgaan ofwel van referentiebeelden die het huidige beeld voorafgaan en opvolgen. In het laatste geval wordt het blok voorspeld op basis van het gewogen gemiddelde van twee blokken. Het ene blok is afkomstig uit het voorafgaand referentiebeeld en het ander blok uit het volgend referentiebeeld. Om deze twee blokken te identificeren, moeten er twee bewegingsvectoren worden verstuurd namelijk, de voorwaartse en de achterwaartse bewegingsvector. Dit resulteert in drie beeldtypes. Bij een I-beeld (Intra picture) wordt geen gebruikgemaakt van andere referentiebeelden, bij een P-beeld (Predictive picture) worden enkel referentiebeelden gebruikt die eerder voorkomen in de stroom en tenslotte bij een B-beeld (Bipredictive picture) worden zowel eerdere als nog toekomstige beelden gebruikt voor de voorspelling. Een voorbeeld van een bitstroom met de drie types beelden wordt gegeven in figuur 2.8. Het eerste beeld is altijd een I-beeld aangezien er nog geen informatie beschikbaar is om de voorspelling te construeren. De pijlen in de figuur geven aan welke beelden als referentiebeelden worden gebruikt. Beelden worden geordend per Group Of Pictures (GOP). Een GOP begint altijd met een I-beeld. Verder kan de GOP een willekeurig aantal P- en B-beelden bevatten. Er kan random acces gebeuren naar het begin van elke GOP omdat met een I-beeld begonnen wordt. De GOP-structuur van de sequentie uit figuur 2.8 is gelijk 16

32 aan IBPBP.... Voor het coderen van B-beelden moeten de achterliggende beelden, gebruikt voor de voorspelling reeds gecodeerd zijn. De codeervolgorde van bijvoorbeeld de sequentie uit figuur 2.8 is gelijk aan Wanneer de beelden aan de output verschijnen moeten ze eerst opnieuw geordend worden in de originele volgorde namelijk, Dit is de afspeelvolgorde. I B P B P B P Figuur 2.8: Typische sequentie met I-, P- en B-beelden Om een P- of B-beeld te kunnen reconstrueren, moeten dezelfde referentiebeelden die door de encoder gebruikt werden, ook in de decoder aanwezig zijn. Stel dat de encoder een voorspelling P maakt van beeld 5 (zie figuur 2.8) op basis van het origineel beeld 3. Om beeld 5 te reconstrueren, is zowel P als beeld 3 nodig. Beeld 3 is echter niet voorhanden in de decoder, maar wel de gereconstrueerde versie, beeld 3. Deze twee beelden zijn niet identiek omdat er verlies optreedt tijdens het coderingsproces. Hierdoor kan de reconstructie van beeld 5 op basis van beeld 3 ook niet correct gebeuren. Het gereconstrueerde beeld 5 kan nadien ook als referentiebeeld worden gebruikt. De fout zal op deze manier verder propageren in de volgende beelden. Dit wordt ook wel drift genoemd en geeft dus aanleiding tot een verlies aan kwaliteit in de decoder. De drift kan enkel gestopt worden bij het volgende I-beeld. De oplossing voor dit probleem is vrij eenvoudig. Aan de encoderzijde kan een gedecodeerd beeld gebruikt worden voor het opstellen van de voorspelling. De encoder zal alle beelden die als referentiebeeld worden gebruikt ook decoderen en deze gedecodeerde versie bijhouden in de buffer. Beeld 5 zal in de encoder dus voorspeld worden op basis van beeld 3. Encoder en decoder gebruiken nu dezelfde referentiebeelden. 17

33 Transformatie en quantisatie De originele data zijn via inter- of intracodering sterk gereduceerd. Om de correlatie te verwijderen wordt een transformatie toegepast om deze data om te zetten in symbolen. Een vaak gebruikte transformatie is de Discrete Cosine Transformation (DCT). Deze werkt in op 8x8-blokken en zorgt ervoor dat de energie wordt geconcentreerd in een klein aantal coëfficiënten die sterk gedecorreleerd zijn. DCT is een methode om een blok te ontleden tot een gewogen som van spatiale frequenties. Elk van deze spatiale frequenties heeft een corresponderende coëfficiënt, namelijk de amplitude nodig om het aandeel van dat frequentiepatroon in het blok te analyseren. Elk spatiaal frequentiepatroon wordt vermenigvuldigd met zijn coëfficiënt en de resulterende 64 8x8-amplitudematrices worden opgeteld (sample per sample) om het 8x8-blok te reconstrueren. De eerste coëfficiënt is de DC-waarde, die een gemiddelde waarde weergeeft van het blok overeenkomend met de laagste frequentie. De andere coëfficiënten zijn de AC-coëfficiënten en geven het fijner detail in het blok weer. Deze coëfficiënten komen overeen met de hogere frequenties, waarvoor het menselijk oog minder gevoelig is. Een voorbeeld van een 8x8-blok getransformeerd door middel van DCT wordt gegeven in figuur 2.9. DC-coëfficiënt (a) origineel blok (b) getransformeerd blok Figuur 2.9: Origineel blok (a) en getransformeerd blok door middel van DCT (b) Omdat er een verlies aan nauwkeurigheid is omwille van afrondingsfouten, is een exacte reconstructie door toepassing van de Inverse DCT (IDCT) niet mogelijk. De transformatie wordt gevolgd door quantisatie van de coëfficiënten. In dit stadium wordt er een trade-off gemaakt tussen enerzijds een verlies aan kwaliteit 18

34 en anderzijds een hogere compressiefactor. Niet-significante data gaan verloren bij quantisatie en deze kunnen niet meer achterhaald worden. Voor elk element in de DCT-outputmatrix, wordt een corresponderende gequantiseerde waarde berekend door elke DCT-coëfficiënt te delen door een quantisatieparameter. Afhankelijk van de grootte van deze parameter, worden de data meer gecomprimeerd, maar treedt er ook meer verlies op. Het netto-effect is een gereduceerde variantie tussen de gequantiseerde coëfficiënten in vergelijking met de variantie tussen de DCT-coëfficiënten en een vermindering van het aantal nietnulcoëfficiënten. In figuur 2.10 is het gequantiseerde blok te zien van het getransformeerde blok uit figuur 2.9 (b) Figuur 2.10: Gequantiseerd blok Het transformatie- en quantisatieproces is verlieshebbend. Na toepassing van de inverse quantisatie en transformatie bekomen we het gereconstrueerd blok. Dit blok is niet volledig identiek aan het origineel. In figuur 2.11 wordt het gereconstrueerde blok getoond van het blok uit figuur Ook het verschil tussen het originele (zie figuur 2.9 (a)) en het gereconstrueerde blok wordt weergegeven. Om de kwaliteit van het gereconstrueerd blok te meten, kan de PSNR-waarde berekend worden: MSE = [f(x, y) f (x, y)] 2 = 2, 26 (2.8) 64 x=0 y=0 waaruit volgt: P SNR db = 10 log 10 (255) 2 19 = 41, 04 db (2.9) (2, 26) 2

35 (a) gereconstrueerd blok (b) verschilblok Figuur 2.11: Gereconstrueerd blok (a) en het verschilblok (b) De PSNR-waarde is vrij hoog, wat wil zeggen dat het gereconstrueerd blok een goede benadering is van het origineel blok. 2 Entropiecodering Na transformatie en quantisatie zal een macroblok veel nulcoëfficiënten bevatten en maar weinig significante niet-nulcoëfficiënten. Deze statistische redundantie wordt verwijderd door middel van entropiecodering. Een entropie is een maat voor de hoeveelheid informatie van een alfabet en wordt gegeven door volgende formule: met 0 log 2 0 = 0. N H = p x (α j )log 2 (p x (α j )) (2.10) j=1 Hierbij is N gelijk aan het aantal symbolen in het bronalfabet. α j is een symbool uit het alfabet en x is een statistische variabele. De informatieve inhoud van één symbool wordt gegeven door log 2 (p x (α j )) en p x (α j ) stelt de probabiliteit dat x de waarde α j aanneemt voor. De gemiddelde informatieve inhoud van een bronalfabet wordt berekend door de som te maken van de informatieve inhoud van elk symbool maal zijn probabiliteit van voorkomen. H laat toe iets over de efficiëntie van een codeertechniek te zeggen want het vormt een ondergrens voor de verwachte codelengte. [2] 2 Normaalgezien worden PSNR-waarden van verschillende beelden (of sequenties) met elkaar vergeleken. Eén afzonderlijke PSNR-waarde zegt eigenlijk niet veel. 20

36 Vóór het toepassen van de entropiecodering worden de gequantiseerde coëfficiënten sequentieel geordend. De belangrijkste niet-nulcoëfficiënten bevinden zich bij natuurlijke beelden rond de linker bovenhoek van het blok (dit zijn de lage frequenties). Via zigzag-scan wordt de matrix omgezet in een sequentiële rij, waarbij de meest significante coëfficiënten eerst voorkomen (eerst de DC-coëfficiënt, gevolgd door de AC-coëfficiënten). In figuur 2.12 wordt gedemonstreerd hoe de zigzag-scan gebeurt. Figuur 2.12: Sequentieel ordenen van de gequantiseerde coëfficiënten door zigzag-scan De rij waarden na zigzag-scan bevat af en toe een niet-nulcoëfficiënt gevolgd door een groep nullen. Dit kan efficiënt worden voorgesteld door (run,level)-codering toe te passen. De run stelt een rij nullen voor, gevolgd door een niet-nulcoëfficiënt. Het level is gelijk aan de niet-nulcoëfficiënt. Dit wordt getoond in figuur sequentiële rij (run,level)-paren (0,79) (1,-2) (0,-1) (0,-1) (2,-1) Figuur 2.13: (run,level)-codering Nadien wordt entropiecodering toegepast op de (run,level)-paren. De bedoeling hiervan is frequent voorkomende (run,level)-paren voor te stellen door een kort codewoord en minder frequent voorkomende (run,level)-paren toe te wijzen aan langere 21

37 codewoorden. Op deze manier worden de (run,level)-paren gecomprimeerd in een kleiner aantal bits (reductie van de statistische redundantie). Vaak gebruikte entropiecoderingen zijn de prefixcodes en de aritmetische codes. Tot de prefixcodes behoren onder andere de Huffman-code en de Golomb- en Ricecodes; Context-based Adaptive Binary Arithmetic Coding (zie paragraaf 4.5) is een voorbeeld van een aritmetische code. Golomb- en Rice-codes Beide codes worden gekarakteriseerd door een parameter m. De symbolen worden geordend volgens dalende waarschijnlijkheid en met elk symbool wordt een natuurlijk getal geassocieerd, beginnend bij 0 voor het meest waarschijnlijke symbool. Om een symbool n te coderen met parameter m, wordt eerst n/m berekend en dit wordt gecodeerd door evenveel 1 tjes naar buiten te brengen. Dit is het unaire deel van de code. Daarna wordt n mod m berekend en dit wordt binair gecodeerd met ofwel log 2 m ofwel log 2 m bits. Dit is het aangepast binair deel. De Rice-code met parameter k is hetzelfde als de Golomb-code met parameter m = 2 k. In tabel 2.2 worden enkele Golomb- en Rice-codes getoond voor verschillende waarden van de parameter m. [2] [29] [32] Golomb m = 1 m = 2 m = 3 m = 4 m = 5... m = 8 Rice k = 0 k = 1 k = 2... k = Tabel 2.2: Golomb- en Rice-codes voor de parameters m=1 tot m=5 en parameter m=8 22

38 De Rice-codes kunnen efficiënt geïmplementeerd worden door: 1. unair deel := n >> m 2. aangepast binair deel := n & (maskeren van de k laagste bits) Aritmetische codes De optimale lengte van een codewoord is gelijk aan log 2 (1/P ) met P gelijk aan de probabiliteit van het symbool. [23] [29] Dit is meestal een niet-geheel aantal bits en Golomb-codes bijvoorbeeld kunnen dit optimum niet bereiken omdat elk codewoord een geheel aantal bits heeft. Aritmetische codes kunnen dit wel. Een aritmetische coder stelt een volledige datastroom voor in één codewoord. Het codewoord stelt eigenlijk een halfopen interval voor, dat in het eenheidsinterval [0, 1[ ligt. Bij elk symbool dat moet worden gecodeerd, wordt het interval verfijnd met de waarschijnlijkheid van het symbool. Het uiteindelijke interval wordt gecodeerd met voldoende bits, zodat dit van alle andere intervallen te onderscheiden is. Voor meer uitleg en een voorbeeld kan [23] geraadpleegd worden. 23

39 Hoofdstuk 3 De JVT/AVC-standaard Na het inleidend hoofdstuk met algemene principes en terminologie rond videocodering, wordt in dit hoofdstuk de globale structuur besproken van de JVT/AVCstandaard. In het volgende hoofdstuk wordt meer in detail ingegaan op de functionele eenheden waaruit de codec is opgebouwd. 3.1 Ontstaan en standaardisatie van de JVT/AVCstandaard MPEG-4 (Deel 2) 1 [16] en H.263 [10] zijn beide standaarden die ontwikkeld zijn op basis van videocompressietechnologie uit circa De groepen die verantwoordelijk zijn voor deze standaarden zijn de Moving Picture Experts Group (ISO/IEC JTC1) en de Video Coding Experts Group (ITU-T). Deze hebben samen een nieuwe standaard, Advanced Video Coding ontwikkeld die veel efficiënter is dan H.263 en MPEG-4. De ontwikkeling van de standaard werd in 1997 gestart door de VCEG van het ITU-T (oorspronkelijk voor videocommunicatietoepassingen aan lage bitsnelheid). Het was de bedoeling dat het een standaard voor een lange termijn zou zijn en de draft kreeg daarom de naam H.26L 2. In 2001 werden de voordelen van H.26L door de MPEG-groep van ISO/IEC erkend en de samenwerking werd gestart met de oprichting van het Joint Video Team (JVT). Deskundigen van MPEG en VCEG werken 1 MPEG-4 is ook bekend als Coding of audiovisual objects. 2 De L staat voor long-term. 24

40 in het JVT samen met als doel de H.26L-draft af te werken tot een International Standard (IS). In december 2002 is de overgang van Final Committee Draft (FCD) naar Final Draft International Standard (FDIS) gebeurd. De goedkeuring tot International Standard is voorzien voor half Uiteindelijk zullen er twee identieke internationale standaarden worden goedgekeurd, namelijk MPEG-4 deel 10 en ITU- T Rec. H.264. MPEG-4 deel 10 wordt ook wel MPEG-4 Advanced Video Coding genoemd of ISO/IEC De standaard vormt dus een nieuw onderdeel binnen MPEG-4. In tabel 3.1 wordt een overzicht gegeven van de onderdelen van MPEG-4. Officieel nummer ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC Officiele naam (werknaam) Systems Visual Audio Conformance Testing Reference Software DMIF (Delivery Multimedia Integration Framework) Optimized Visual Reference Software 4onIP Reference Hardware Description Advanced Video Coding Scene Description and Application Engine ISO Media File Format IPMP Extensions MP4 File Format AVC File Format Animation Framework Extension (AFX) Tabel 3.1: Onderdelen van MPEG-4 De verschillende videostandaarden van zowel het ISO/IEC als van het ITU-T worden in figuur 3.1 weergegeven. 3.2 De JVT/AVC-codec In overeenkomst met eerdere standaarden zoals MPEG-1, MPEG-2 en MPEG-4, wordt een codec in de standaard niet expliciet gedefinieerd. De standaard definieert wel de syntax van een geëncodeerde videostroom, samen met een methode om deze bitstroom te decoderen. 25

41 ITU-T-recommendations H.261 H.263 H.263+ H Standaarden ontstaan uit de samenwerking van ITU-T en ISO/IEC H.262/MPEG-2 H.264/MPEG-4 deel 10 ISO/IEC-standaarden MPEG-1 MPEG Figuur 3.1: ITU-T-recommendations en ISO/IEC-standaarden De JVT/AVC-lagenstructuur Een nieuw concept in de JVT/AVC-standaard is de scheiding tussen de Video Coding Layer (VCL) of videocoderingslaag en de Network Abstraction Layer (NAL) of netwerkabstractielaag. Dit wordt getoond in figuur 3.2. De videocoderingslaag heeft als doel de videodata te comprimeren tot een efficiënte representatie en werkt in op macroblokken. De gecodeerde macroblokken worden gegroepeerd tot slices (zie paragraaf 3.3.1). De netwerkabstractielaag deelt deze data in volgens een bepaald formaat en voorziet headerinformatie aangepast aan het beoogde netwerk. Alle data (afkomstig van de VCL en ook controledata) worden ingedeeld in NAL-eenheden. Deze indeling is een generiek formaat dat geschikt is voor zowel pakketgebaseerde netwerken als bytestroomgebaseerde netwerken. Het NAL-eenheidformaat is voor beide types netwerken identiek behalve dat voor bytestroomgebaseerde netwerken een NAL-eenheid wordt voorafgegaan door een startcode-prefix. De scheiding tussen de twee lagen zorgt voor een netwerkvriendelijke representatie. JVT/AVC-bitstromen kunnen gemakkelijk over verschillende types netwerken getransporteerd worden. In hoofdstuk 5 wordt dieper ingegaan op de netwerkabstractielaag. 26

42 Controledata Videocoderingslaag (VCL) Datapartitionering gecodeerde macroblok gecodeerde slice/partitie Netwerkabstractielaag (NAL) H.32x MPEG-2 RTP... Figuur 3.2: Lagenstructuur van de JVT/AVC-standaard Videocoderingslaag In deze sectie wordt een globaal overzicht gegeven van de videocoderingslaag. Een meer gedetailleerde bespreking wordt gegeven in hoofdstuk 4. Het VCL-ontwerp is een voorbeeld van blokgebaseerde hybride videocodering. Dit houdt in dat het broncoderingsalgortime op blokken samples inwerkt en een combinatie is van intervoorspelling en transformatie van het residu na voorspelling. Bij intervoorspelling worden temporele statistische afhankelijkheden geëxploiteerd. Transformatie exploiteert spatiale statistische afhankelijkheden. De verbetering in compressie-efficiëntie in vergelijking met andere standaarden is niet te danken aan één bepaalde component maar het is de som van veranderingen in verschillende componenten die tot deze verbetering heeft geleid. De functionele eenheden waaruit een JVT/AVC-encoder zou moeten bestaan, worden afgebeeld in figuur 3.3. De basiseenheden (voorspelling, transformatie, quantisatie en entropiecodering) verschillen weinig van eerdere standaarden (MPEG-1, MPEG-2, MPEG-4, H.261 en H.263); de belangrijkste wijzigingen in de JVT/AVCstandaard zijn te vinden in de details van elk element. 27

43 inkomend videosignaal verdeeld in macroblokken van 16 x 16 pixels + - inter/intra codeercontrole transformatie / quantisatie intravoorspelling controledata getransformeerde coëfficiënten inverse quantisatie / transformatie + entropiecodering + NAL antiblokfilter uitgaande bitstroom motion compensation buffer bewegingsvectoren motion estimation Figuur 3.3: JVT/AVC-encoder Encoderingsproces Voor het encoderen van een beeld wordt dit verdeeld in macroblokken elk behorende tot juist één slice (zie paragraaf 3.3.1). Het eerste beeld van een sequentie wordt altijd intragecodeerd. Op vaste intervallen wordt meestal ook een intragecodeerd beeld toegevoegd zodat eventuele fouten niet verder propageren (drift). Voor een intramacroblok wordt een voorspelling opgesteld gebruikmakend van informatie uit het beeld zelf. Elk sample van een blok wordt voorspeld op basis van naburige, reeds gecodeerde en opnieuw gedecodeerde samples. Deze samples werden nog niet gefilterd (zie paragraaf 3.3.6). Andere beelden uit de sequentie worden intergecodeerd. Hierbij wordt de voorspelling gevormd door ME/MC van samples van één of meerdere referentiebeelden. Deze referentiebeelden bevinden zich in de buffer. Vervolgens wordt de opgestelde voorspelling afgetrokken van het huidige macroblok om het residumacroblok (verschilmacroblok) te bekomen. De samples van dit 28

44 residumacroblok worden getransformeerd en gequantiseerd. De bekomen coëfficiënten, de bewegingsvectoren (indien intermodus werd gebruikt) en andere syntaxelementen worden vervolgens gecomprimeerd door middel van entropiecodering. Het resultaat hiervan wordt samen met de codeerparameters verwerkt tot NAL-eenheden. In de encoder wordt het beeld ook opnieuw gereconstrueerd. De getransformeerde en quantiseerde coëfficiënten worden onderworpen aan de inverse transformatie en quantisatie. Nadien wordt de voorspelling van dit macroblok (dit is dezelfde voorspelling als daarstraks) hierbij opgeteld zodat het gedecodeerd macroblok bekomen wordt. Op deze manier wordt het volledige beeld gereconstrueerd. Vervolgens wordt de antiblokfilter (zie paragraaf 3.3.6) op het beeld toegepast. Het uiteindelijke beeld komt in de buffer terecht en volgende beelden kunnen dit als referentiebeeld gebruiken. Decoderingsproces Uit de NAL-eenheid worden de syntaxelementen en de gecodeerde data gehaald. Deze gecodeerde data worden onderworpen aan de inverse entropiecodering, waardoor de gequantiseerde transformatiecoëfficiënten en de bewegingsvectoren bekomen worden (bij intermodus). Deze coëfficiënten worden omgezet door toepassing van de inverse transformatie en quantisatie. Aan de decoderzijde wordt dezelfde voorspelling opgesteld voor elk macroblok als aan de encoderzijde. Deze voorspelling wordt opgeteld bij de gedecodeerde data waaruit een ongefilterde versie van het originele beeld bekomen wordt. Dit beeld is niet identiek aan het oorspronkelijke omdat bij het coderingsproces informatie verloren gaat. Om het effect van blokvorming te verminderen wordt het beeld gefilterd voor het aan de output verschijnt. 3.3 Beknopte beschrijving van de functionele eenheden Onderverdeling van een beeld Elk beeld van de videosequentie, dit kan een frame of een veld zijn, wordt verdeeld in macroblokken die 16x16 luminantiesamples bevatten en 8x8 samples van de twee 29

45 chrominantiecomponenten. Deze macroblokken behoren tot slices, die een subset van het beeld zijn en onafhankelijk van elkaar worden gecodeerd. De onderverdeling (partitionering) in slices zorgt voor een zekere foutbestendigheid omdat een fout in één bepaalde slice nooit het decoderingsproces van andere slices zal beïnvloeden. De JVT/AVC-standaard ondersteunt vijf verschillende slicetypes. Het eenvoudigste type is de I-slice 3. In een I-slice worden alle macroblokken gecodeerd zonder gebruik te maken van informatie uit andere beelden. Bij P- en B-slices is dit wel het geval. De ander twee slicetypes zijn SP (Switching Predictive) en SI (Switching Intra) en worden gebruikt bij het overschakelen tussen verschillende bitstromen. Hierdoor is onder andere een triviale vorm van schaalbare videocompressie mogelijk. Meer uitleg hierover wordt gegeven in hoofdstuk 6. Slices kunnen afhankelijk van hun type verschillende types van macroblokken bevatten. Tabel 3.2 geeft hier een overzicht van. Slicetype I-slice P-slice B-slice SI-slice SP-slice Toegelaten macrobloktypes I-macrobloktype P- en I-macrobloktype B- en I-macrobloktype SI- en I-macrobloktype P- en I-macrobloktype Tabel 3.2: Toegelaten macrobloktypes voor de verschillende slicetypes Flexible Macroblock Ordening Alle macroblokken van een beeld kunnen optioneel ook toegewezen worden aan een slicegroep. De toewijzing gebeurt op basis van de macroblock to slice group map. Dit is een lijst met nummers, één voor elk gecodeerd macroblok, die aangeeft tot welke slicegroep elk gecodeerd macroblok behoort. Er kunnen maximaal 8 slicegroepen per beeld voorkomen. De ordening van de macroblokken in de slicegroepen kan volgens verschillende patronen, bijvoorbeeld rechthoekige patronen of schaakbordpatronen. Maar het is ook mogelijk dat de macroblokken volledig verspreid zijn over de verschillende slicegroepen. Elke slicegroep wordt afzonderlijk over het netwerk 3 In de standaard wordt een beeld bestaande uit enkel I- of SI-slices een Instantaneous Decoding Refresh picture (IDR-beeld) genoemd. 30

46 verstuurd. Wanneer één slicegroep werd verloren, kunnen naburige macroblokken uit andere slicegroepen gebruikt worden om de macroblokken van de verloren slicegroep te verbergen. Deze optie wordt ook Flexible Macroblock Ordening (FMO) genoemd. FMO is efficiënt voor toepassingen over foutgevoelige netwerken die een lage vertraging vereisen. De verloren macroblokken kunnen verborgen worden door de naburige macroblokken uit andere slicegroepen. Arbitrary Slice Ordening Arbitrary Slice Ordening (ASO) is een optionele mogelijkheid die toelaat dat slices van een beeld in een willekeurige volgorde kunnen worden verstuurd. Wanneer ASO niet is toegestaan moeten de slices worden verstuurd volgens stijgend macroblokadres van het eerste macroblok van elke slice. Deze optie verhoogt de flexibiliteit voor toepassingen zoals videoconferentie, die een lage vertraging vereisen. De slices kunnen in willekeurige volgorde gedecodeerd worden Intravoorspelling In elk van de slicetypes kunnen intragecodeerde macroblokken voorkomen. Voor de codering van I-macroblokken worden in de standaard twee modi voorzien, waarvoor verder de benamingen intra-4x4-modus en intra-16x16-modus worden gebruikt. De voorspelling voor een I-blok wordt in het spatiaal domein uitgevoerd op basis van naburige samples van reeds gecodeerde blokken. Bij intra-4x4-modus wordt voor elke 4x4-blok van de luminantiecomponent gekozen tussen één van de 9 voorspellingsmodi. Bij het gebruik van de intra-16x16-modus wordt een uniforme voorspelling uitgevoerd voor de volledige luminantiecomponent van het macroblok. Hiervoor zijn vier mogelijke voorspellingsmodi. De intra-16x16-modus is vooral geschikt voor delen van het beeld waarbij de helderheid globaal gezien weinig varieert (dus voor lage spatiale frequenties). Voor de chrominantiesamples van het macroblok zijn er ook vier voorspellingsmodi, gelijkaardig aan deze van de intra-16x16-modus. Om de onafhankelijkheid tussen slices te behouden, wordt intravoorspelling over slicegrenzen niet toegelaten. 31

47 3.3.3 Intervoorspelling De intervoorspelling van de JVT/AVC-standaard vertoont zeer sterke gelijkenissen met eerdere standaarden, maar er is een grotere flexibiliteit en functionaliteit mogelijk. Intervoorspelling is gebaseerd op ME/MC en heeft als doel het uitbuiten van de temporele redundantie. Hierdoor is een veel grotere compressie mogelijk dan bij intravoorspelling. Er zijn twee soorten intervoorspelling, namelijk voor P- (in P- en SP-slices) en B-macroblokken (in B-slices). Voor P-macroblokken wordt enkel gebruikgemaakt van referentiebeelden die eerder voorkomen in de bitstroom. Bij B- macroblokken kan de voorspelling worden opgebouwd uit het gewogen gemiddelde van twee verschillende MC-voorspelde waarden. Voor B-slices wordt gebruikgemaakt van twee lijsten met referentiebeelden. Voor de MC ondersteunt de JVT/AVCstandaard blokgroottes van 16x16 tot 4x4 samples in de luminantiecomponent. De luminantiecomponent van een macroblok kan onderverdeeld worden in 16x16-, 16x8-, 8x16- en 8x8-blokken. Deze blokken worden partities genoemd. Wanneer de 8x8- blokgrootte wordt gekozen, kan elk van de vier 8x8-blokken verder verdeeld worden in 8x8-, 8x4-, 4x8- en 4x4-blokken. Dit zijn de subpartities. Deze methode voor het partitioneren van een macroblok in kleinere blokgroottes wordt tree structured motion compensation genoemd. Voor elke partitie of subpartitie moet een bewegingsvector worden doorgestuurd. Wanneer een macroblok volledig werd gepartitioneerd in 4x4-blokken, moeten dus 16 bewegingsvectoren voor het macroblok worden verstuurd. Ook de keuze van de partitionering moet worden verstuurd. Grotere blokken vereisen minder bewegingsvectoren, maar voor blokken met veel detail, kan het residu van de MC nog veel energie (informatie) bevatten. De keuze van kleinere blokken kan efficiënter zijn omdat het residu waarschijnlijk minder energie zal bevatten, maar er moeten meer bewegingsvectoren worden verstuurd. Bijgevolg bepaalt de keuze van partitionering sterk de compressieprestatie. Over het algemeen worden grote blokken gekozen voor vrij egale macroblokken en zijn kleine blokken eerder geschikt voor fijn detail. De resolutie van de chrominantiecomponenten is de helft van deze van de luminantiecomponent. De partitionering gebeurt op dezelfde manier als bij de luminantiecomponent, maar de grootte van de partities is zowel horizontaal als verticaal gehalveerd. Elke partitie van een intergecodeerd macroblok wordt voorspeld op basis van een 32

48 blok van dezelfde grootte uit het referentiebeeld. De offset tussen deze twee blokken (bewegingsvector) heeft een resolutie van 1/4 van een pixel. De subpixelposities worden via interpolatie op basis van naburige pixels berekend. De JVT/AVC-standaard ondersteunt ook de selectie uit meerdere referentiebeelden. Het zoeken naar een match voor ME, kan in verscheidene beelden gebeuren, waardoor de kans groter is om een vrij gelijkaardig blok te vinden. Deze optie leidt wel tot grotere vertraging bij het coderingsproces en vereist een hogere geheugencapaciteit aan zowel encoder- als decoderzijde Transformatie en quantisatie De JVT/AVC-standaard maakt gebruik van een nieuw type transformatie. In eerdere standaarden wordt de DCT-transformatie (op 8x8-blokken) gebruikt. De transformatie in de JVT/AVC-standaard is een geheelwaardige (integer) transformatie die inwerkt op 4x4-blokken. Deze transformatie is verwant met de 4x4- DCT, maar doordat enkel met gehele waarden wordt gerekend, is er geen mismatch mogelijk bij de inverse transformatie. Er gaat bij de transformatie dus geen informatie verloren. Bij gewone DCT was geen exacte reconstructie mogelijk omwille van afrondingsfouten. Een extra 2x2-transformatie wordt toegepast op de 4 DC-coëfficiënten van elke chrominantiecomponent. Wanneer een macroblok werd gecodeerd in intra-16x16-modus, wordt een gelijkaardige transformatie toegepast op de 4x4 DC-coëfficiënten van de luminantiecomponent. De JVT/AVC-standaard ondersteunt een scalaire quantisatie. Er zijn 52 mogelijke quantisatie parameters (QP s) die elk leiden tot een verschillende graad van compressie. Deze QP kan voor elk macroblok afzonderlijk worden gekozen, dit in tegenstelling tot eerdere standaarden. Wanneer de QP met één wordt verhoogd, leidt dit tot een compressie die 12,5% sterker is. [12] Alle bewerkingen bij transformatie en quantisatie kunnen geïmplementeerd worden gebruikmakend van enkel optel- en bitshiftoperaties op de 16-bits gehele waarden. 33

49 3.3.5 Entropiecodering De laatste stap in het coderingsproces is de entropiecodering. Kortere codewoorden worden toegewezen aan symbolen met een hogere probabilteit en langere codewoorden aan symbolen met een lagere probabiliteit. Alle syntaxelementen worden entropiegecodeerd. Voor de syntaxelementen uit de slice- en macrobloklaag ondersteunt de JVT/AVC-standaard twee types van entropiecodering. De eerste methode is een combinatie van Universal Variable Length Coding (UVLC) en Context-based Adaptive Variable Length Coding (CAVLC). De tweede methode maakt gebruik van Context-based Adaptive Binary Arithmetic Coding (CABAC). UVLC/CAVLC Deze combinatie van entropiecodering is de standaardmethode van de JVT/AVCstandaard. Voor alle syntaxelementen, behalve de coëfficiënten na transformatie en quantisatie, wordt gebruikgemaakt van één universele tabel van codewoorden, die oneindig uitbreidbaar is. Enkel de afbeelding naar deze VLC-tabel is verschillend voor elk syntaxelement aangepast aan het type van het syntaxelement. Voor de getransformeerde en gequantiseerde coëfficiënten wordt CAVLC gebruikt. Afhankelijk van de reeds verstuurde codewoorden, wordt de keuze van de gebruikte VLC-tabel aangepast. De verschillende VLC-tabellen geven een optimale codering voor een bepaald aantal aanwezige niet-nulcoëfficiënten van het blok. CABAC CABAC is een efficiëntere entropiecodering dan UVLC/CAVLC, maar vereist meer rekenkracht. Het is een aritmetische entropiecodering waardoor een niet-geheel aantal bits kan worden toegewezen aan een symbool. Het is een zich aanpassende code wat voordelig is als de probabiliteit van de symbolen varieert. Er wordt bovendien gebruikgemaakt van contextmodellering (zie paragraaf 4.5.2), zodat rekening gehouden wordt met reeds gecodeerde symbolen. 34

50 3.3.6 Antiblokfilter De standaard voorziet een antiblokfilter die inwerkt op de randen van de 4x4- blokken om blokartefacten te verwijderen (verminderen). Blokranden worden gereconstrueerd met een lagere nauwkeurigheid dan pixels binnen het blok, waardoor de randen van de blokken vrij goed te zien zijn. Bij de aanpassende antiblokfilter van de JVT/AVC-standaard wordt de sterkte van de filter bepaald door verschillende syntaxelementen. De grens tussen twee intragecodeerde blokken, elk afkomstig van een verschillend macroblok, zal het sterkst worden gefilterd. De filter zorgt niet voor vervaging van het beeld, waardoor de subjectieve visuele kwaliteit sterk verbeterd wordt. 3.4 Toepassingen Om aan het grote aantal toepassingen te voldoen, worden in de JVT/AVC-standaard drie profielen voorzien 4. Een profiel is een subset van de volledige syntax van de bitstroom waarbij een afweging wordt gemaakt tussen enerzijds prestatie en anderzijds resourcegebruik. Op die manier wordt voldaan aan de vereisten van een bepaalde set van toepassingen. Binnen elk profiel worden levels gedefinieerd. Een level beschrijft de beperkingen op de waarden van bepaalde syntaxelementen in de bitstroom. In de volgende paragrafen komen enkele termen aan bod die nog niet werden uitgelegd. Hierbij wordt telkens verwezen naar de paragraaf waar de uitleg kan worden gevonden Baseline Profiel Het Baseline Profiel is conversatiegeoriënteerd en richt zich op videoconferentie en draadloze toepassingen. Deze waretijdstoepassingen vereisen een zo minimaal mogelijke vertraging. Bitstromen conform dit profiel moeten voldoen aan volgende voorwaarden: Geen bidirectionele voorspelling mogelijk (enkel I- en P-slicetypes) Geen datapartitionering (zie paragraaf 6.2.2) 4 zie Annex A in [12] 35

51 Ondersteunt enkel progressieve video Geen gewogen voorspelling mogelijk bij intervoorspelling van P-macroblokken (zie paragraaf 4.2.2) VLC-gebaseerde entropiecodering (geen CABAC) Maximaal 8 slicegroepen Main Profiel Het Main Profiel is bedoeld voor broadcasting toepassingen en entertainment video (DVD en MMS). Bitstromen moeten aan volgende voorwaarden voldoen: Enkel I-, P- en B-slicetypes mogelijk Geen datapartitionering Arbitrary Slice Ordening wordt ondersteund Geen redundante beelden aanwezig in de bitstroom 5 Interlaced of progressive scan is level-afhankelijk CABAC-entropiecodering Dit profiel is geen uitbreiding van het Baseline profiel Extended Profiel Het derde profiel, Extended Profiel, is geschikt voor toepassingen gericht op het stromen van videodata en is een uitbreiding van het Baseline Profiel. Hiervoor moet voldaan zijn aan volgende voorwaarden: Alle mogelijke slice-types worden ondersteund VLC-gebaseerde entropiecodering (geen CABAC) 5 Dit zijn extra beelden, kopieën van andere beelden die in de bitstroom worden toegevoegd om een betere foutbestendigheid te bekomen. Enkel wanneer het originele beeld fouten bevat of niet werd ontvangen, wordt het redundante beeld gedecodeerd. 36

52 Maximaal 8 slicegroepen Interlaced of progressive scan is level-afhankelijk 37

53 Hoofdstuk 4 Detailstudie van de functionele eenheden In dit hoofdstuk wordt dieper ingegaan op de functionele eenheden waaruit de JVT/AVC-standaard is opgebouwd. De twee voorspellingsmodi, de gebruikte transformatie en quantisatie, de entropiecoderingen en de antiblokfilter worden beschreven. De bespreking in de volgende paragrafen is geldig voor progressive scan video. Voor interlaced video zijn sommige details verschillend, maar de basis, die hier verder wordt besproken, blijft behouden. 4.1 Intravoorspelling Bij intravoorspelling 1 wordt enkel spatiale redundantie uit een beeld verwijderd. Wanneer een blok of macroblok wordt voorspeld in intramodus, wordt een voorspelling P gevormd op basis van reeds gecodeerde en opnieuw gedecodeerde blokken uit het huidige beeld. Deze blokken werden nog niet gefilterd. De blokken van een beeld worden namelijk doorlopen in raster-scanvolgorde, beginnend bij het blok in de linker bovenhoek en zo lijn per lijn tot aan het blok de rechter onderhoek. Het voorspelde blok P wordt afgetrokken van het huidige blok vooraleer dit blok wordt gecodeerd. Voor de luminantiecomponent kan P opgesteld worden voor een 4x4- blok of voor een 16x16-blok. In het totaal zijn er negen voorspellingsmodi voor 4x4- blokken (zie paragraaf 4.1.1). Voor een 16x16-luminantieblok zijn er vier optionele 1 zie [12]

54 voorspellingsmodi (zie paragraaf 4.1.2). Voor de 8x8-chrominantieblokken zijn er ook vier voorspellingsmodi (zie paragraaf 4.1.3). Intracodering wordt toegepast op macroblokken met type I en SI. [23] [20] Voorspelling voor 4x4-luminantieblokken De luminantiecomponent van een macroblok bestaat uit 16 blokken van 4x4 samples. De samples gelegen boven en links van het huidige 4x4-blok zijn reeds gecodeerd en gereconstrueerd en dus in de encoder en decoder beschikbaar voor het opstellen van de voorspelling. Ook de voorspellingsmodus die werd gebruikt voor de naburige blokken, is gekend. Het voorspellingsblok P wordt berekend op basis van de samples A-M (zie figuur 4.1). Belangrijk hierbij op te merken is dat de gebruikte sampels voor de voorspelling steeds uit hetzelfde slice komen. M I J K L A B C D E F G H a b c d e f g h i j k l m n o p Figuur 4.1: Gebruikte samples bij intra-4x4-voorspelling Voorspellingsmodi De negen voorspellingsmodi voor intra-4x4-codering (zie ook figuur 4.2) zijn 2 [20]: Modus 0 (verticaal): De samples A, B, C, D worden verticaal geëxtrapoleerd. Bijvoorbeeld: de samples a, e, i en m (zie figuur 4.1) krijgen de waarden van het sample A. Modus 1 (horizontaal): De samples I, J, K, L worden horizontaal geëxtrapoleerd. Bijvoorbeeld: de samples a, b, c en d krijgen de waarde van het sample I. 2 De formules voor de berekening van de waarden van alle samples kunnen gevonden worden in [12]

55 Modus 2 (DC-voorspelling): Alle samples in P worden voorspeld door het gemiddelde van de samples A tot D en I tot L. Modus 3 (diagonaal linksonder): De voorspelling wordt berekend op basis van de samples A tot H (interpolatie over een hoek van 45 ). Bijvoorbeeld: a = (A + 2B + C + 2)/4 en p = (G + 3H + 2)/4 Modus 4 (diagonaal rechtsonder): Berekening van de voorspelling gebruikmakend van de samples A tot D en I tot M (extrapolatie over een hoek van 45 in de richting rechtsonder). Bijvoorbeeld: a = (A + 2M + I + 2)/4 en b = (M + 2A + B + 2)/4 Modus 5 (verticaal rechts): Berekening van de voorspelling gebruikmakend van de samples A tot H (extrapolatie (of interpolatie) over een hoek van 22, 5 in de richting rechts verticaal). Bijvoorbeeld: a = (A + B + 1)/2 en e = (A + 2B + C + 2)/4 Modus 6 (horizontaal onder): Berekening van de voorspelling gebruikmakend van de samples A tot D en I tot M (extrapolatie over een hoek van 22, 5 in de richting onder horizontaal). Bijvoorbeeld: a = (M + J + 1)/2 en f = (M + 2I + L + 2)/4 Modus 7 (verticaal links): Berekening van de voorspelling gebruikmakend van de samples A tot D en I tot M (extrapolatie over een hoek van 22, 5 in de richting links verticaal). Bijvoorbeeld: a = (M + A + 1)/2 en e = (I + 2M + A + 2)/4 Modus 8 (horizontaal boven): Berekening van de voorspelling gebruikmakend van de samples I tot G (interpolatie over een hoek van 22, 5 in de richting boven horizontaal). Bijvoorbeeld: a = (I + J + 1)/2 en b = (I + 2J + K + 2)/4 In figuur 4.2 geven de pijlen de voorspellingsrichting aan van de verschillende modi (behalve modus 2). Slices worden onafhankelijk van elkaar gecodeerd, waardoor het mogelijk is dat niet alle samples A-M beschikbaar zijn. Voor het huidige macroblok worden de 40

56 Figuur 4.2: Voorspellingsrichting voor de verschillende modi voor intra-4x4-codering beschikbare en niet-beschikbare samples gespecificeerd. Een sample is niet beschikbaar als het buiten het huidige beeld of het huidige slice is gelegen, als het sample in een macroblok ligt dat nog moeten worden gecodeerd of als het sample in een intermacroblok ligt en dit niet mag gebruikt worden bij intravoorspelling (aangegeven door de vlag constrainted intra pred flag). Een voorspellingsmodus (behalve modus 2) mag niet worden gebruikt wanneer de benodigde samples niet beschikbaar zijn. Een uitzondering hierop is wanneer de samples E tot H niet beschikbaar zijn, maar het sample D wel, dan worden deze gesubstitueerd door D. Modus 2 (DC-voorspelling) kan altijd worden toegepast en de berekening van de voorspelling wordt aangepast naargelang de beschikbaarheid van de samples. De berekening van de DC-voorspelling is te vinden in tabel 4.1. Beschikbare samples Voorspelling alle (A + B + C + D + I + J + K + L + 4)/8 I tot L (I + J + K + L + 2)/4 A tot D (A + B + C + D + 2)/4 geen 128 Tabel 4.1: DC-voorspellingsmodus voor 4x4-luminantieblokken Een meer gedetailleerde voorstelling van de verschillende modi wordt gegeven in figuur

57 Modus 0: verticaal Modus 1: horizontaal Modus 2: DC M A B C D E F G H M A B C D E F G H M A B C D E F G H I I I J K L J K L J K L Gemiddelde (A..D en I..L) Modus 3: diagonaal linksonder Modus 4: diagonaal rechtsonder Modus 5: verticaal rechts M A B C D E F G H M A B C D E F G H M A B C D E F G H I I I J J J K K K L L L Modus 6: horizontaal onder Modus 7: verticaal links Modus 8: horizontaal boven M A B C D E F G H M A B C D E F G H M A B C D E F G H I I I J J J K K K L L L Figuur 4.3: Intramodi De modus die het kleinste verschil oplevert tussen P en het originele blok wordt door de encoder gekozen. Hiervoor kan bijvoorbeeld 3 voor elke voorspellingsmodus de Sum of Absolute Errors (SAE) berekend worden. De SAE wordt gegeven door: 3 3 SAE = f(x, y) f (x, y) (4.1) x=0 y=0 Met f het originele blok en f het voorspelde blok. De modus die leidt tot minimale SAE wordt gekozen. Voorbeeld In figuur 4.4 wordt een macroblok voorgesteld dat via intravoorspelling moet worden gecodeerd. Het omlijnde 4x4-blok, is het volgende blok dat moet worden gecodeerd. 3 Eventueel kan ook een ander criterium worden gekozen. Het gebruik van de SAE is niet normatief. 42

58 De negen voorspellingen van dit blok worden getoond in figuur 4.5. Voor elke modus wordt de SAE gegeven. Voor dit blok is modus 7 het meest efficiënt want de SAE is minimaal. Origineel macroblok Te voorspellen 4x4-blok Figuur 4.4: Origineel macroblok en te voorspellen 4x4-blok Codering van de 4x4-voorspellingsmodi Wanneer voor elk 4x4-blok de voorspellingsmodus moet worden meegegeven, zouden veel extra bits moeten worden gecodeerd. De intravoorspellingsmodus is voor naburige blokken vaak sterk gecorreleerd. Wanneer blok A en blok B (zie figuur 4.6) voorspeld worden met modus 2, is de kans groot dat modus 2 ook het meest efficiënt zal zijn voor het blok C. Voor elk blok C, wordt de meest waarschijnlijke modus berekend op basis van de modi van de blokken A en B. De meest waarschijnlijke modus is gelijk aan het minimum van de modi van de blokken A en B. Wanneer een blok A of B niet gelegen is in het huidige slice, wordt de meest waarschijnlijke modus voor blok C modus 2 (DC-voorspelling). De encoder zendt voor elk 4x4-blok een vlag (prev intra4x4 pred mode flag) die aangeeft hoe de intramodus moet worden berekend. Indien de vlag gelijk is aan één, dan is de huidige modus gelijk aan de voorspelde modus. Indien de vlag gelijk is aan nul, wordt nog een extra parameter (rem intra4x4 pred mode) verzonden waaruit de nieuwe modus kan berekend worden. Als rem intra4x4 pred mode 43

59 Modus 0: SAE=619 Modus 1: SAE=657 Modus 2: SAE=607 Modus 3: SAE=200 Modus 4: SAE=1032 Modus 5: SAE=908 Modus 6: SAE=939 Modus 7: SAE=187 Modus 8: SAE=399 Figuur 4.5: Voorbeeld: intravoorspelling van een 4x4-blok kleiner is dan de voorspelde modus, dan is de nieuwe modus gelijk aan deze parameter. Anders is de nieuwe modus gelijk aan deze parameter + 1. Op deze manier moet de parameter rem intra4x4 pred mode slechts acht waarden kunnen hebben om alle modi aan te geven zodat slechts 3 bits nodig zijn voor de voorstelling ervan. Voorbeeld: Stel dat blok A werd voorspeld met modus 3 en blok B met modus 4. In dat geval is 44

60 A B C Figuur 4.6: Naburige intragecodeerde 4x4-blokken de meest waarschijnlijke modus gelijk aan min(3,4) = 3. Als prev intra4x4 pred - mode flag gelijk is aan 1, dan is de modus voor blok C gelijk aan de meest waarschijnlijke modus, dus gelijk aan 3. Indien prev intra4x4 pred mode flag gelijk is aan nul, wordt gekeken naar de parameter rem intra4x4 pred mode. De berekening van de modus van blok C gaat als volgt: Als rem intra4x4 pred mode < 3 dan is de huidige modus gelijk aan de parameter rem intra4x4 pred mode. Als rem intra4x4 pred mode 3 dan is de huidige modus gelijk aan de parameter rem intra4x4 pred mode Voorspelling voor 16x16-luminantieblokken In dit geval zijn er 33 naburige samples die gebruikt kunnen worden voor de voorspelling van het 16x16-blok. Voor de voorspelling van de luminantiecomponent van een 16x16-blok zijn er 4 modi beschikbaar. Modus 0, 1 en 3 kunnen enkel worden toegepast als alle nodige samples beschikbaar zijn. Modus 2 kan altijd toegepast worden, waarbij de berekening wordt aangepast aan de beschikbaarheid van de samples. De verschillende modi zijn (zie ook figuur 4.7): Modus 0 (verticaal): Extrapolatie van de bovenliggende samples (H). Modus 1 (horizontaal): Extrapolatie van de linkse samples (V). Modus 2 (DC-voorspelling): Gemiddelde van de bovenliggende (H) en linksliggende (V) samples. 45

61 Wanneer H en V beschikbaar zijn, is de voorspelling gelijk aan (H + V + 16)/32. Wanneer H niet beschikbaar is, dan is de voorspelling gelijk aan (V + 8)/16 en als V niet beschikbaar is, dan is de voorspelling gelijk aan (H + 8)/16. In het geval zowel H als V niet beschikbaar zijn, is de voorspelde samplewaarde gelijk aan 128. Modus 3 (Plane): Een lineaire functie 4 wordt toegepast op de samples H, V en het sample x. Modus 0 : verticaal Modus 1: horizontaal Modus 2: DC Modus 3: plane H H H x H V... V... V Gemiddelde (H + V) V Figuur 4.7: Intra-16x16-voorspellingsmodi Modus 3 is geschikt voor gebieden met een traag variërende luminantie. Voorbeeld In figuur 4.8 wordt een te voorspellen 16x16-blok van luminantiesamples afgebeeld met omliggende samples die gebruikt worden voor de voorspelling. In figuur 4.9 worden de 4 voorspellingen afgebeeld. Voor elke modus wordt opnieuw de SAE berekend tussen het originele blok f en het voorspelde blok f. Deze wordt hier als volgt berekend: SAE = x=0 y=0 f(x, y) f (x, y) (4.2) Modus 3 geeft hier de beste voorspelling omdat de SAE het kleinst is. 4 De lineaire functie is vrij ingewikkeld en kan gevonden worden in [12]

62 Figuur 4.8: Te voorspellen 16x16-luminantieblok Modus 0: SAE=8990 Modus 1: SAE=10898 Modus 2: SAE=11210 Modus 3: SAE=6264 Figuur 4.9: Intra-16x16 voorspellingen Voorspelling voor de chrominantiecomponenten De samples van de twee 8x8-chrominantieblokken worden voorspeld op een gelijkaardige manier als bij de intra-4x4-modi. Er zijn ook 4 modi beschikbaar die 47

63 gebruikmaken van de samples links van en boven het huidige blok. Voor beide chrominantiecomponenten wordt dezelfde voorspellingsmodus toegepast. Modus 0 is de DC-voorspelling, modus 1 de horizontale, modus 2 de verticale en modus 3 de plane -voorspelling. De laatste drie modi mogen enkel worden toegepast als alle benodigde samples beschikbaar zijn. Modus 0 kan altijd worden toegepast ook al zijn bepaalde van de omliggende samples niet beschikbaar. Bij het gebruik van modus 0 wordt het 8x8-blok verdeeld in vier 4x4-blokken. Dit wordt voorgesteld in figuur S0, s1, s2 en s3 stellen de som voor van de vier samples gelegen aan die grens. Afhankelijk van de beschikbaarheid van s0, s1, s2 en s3, wordt de berekening van de voorspelling van a, b, c of d aangepast. Dit wordt in tabel 4.2 weergegeven. Voor de blokken a, b, c en d zijn telkens 4 mogelijkheden om de DC-voorspelling te berekenen. Bij voorspelling 1 zijn alle nodige samples aanwezig, bij voorspelling 2 is ofwel s2 ofwel s3 niet beschikbaar, bij voorspelling 3 is ofwel s0 of s1 niet beschikbaar en bij voorspelling 4 zijn geen samples beschikbaar. s0 s1 s2 a b s3 c d Figuur 4.10: DC-voorspelling voor 8x8-blokken van chrominantiesamples Blok Voorspelling 1 Voorspelling 2 Voorspelling 3 Voorspelling 4 a (s0 + s2 + 4)/8 (s0 + 2)/4 (s2 + 2)/4 128 b (s1 + 2)/4 (s1 + 2)/4 (s2 + 2)/4 128 c (s3 + 2)/4 (s0 + 2)/4 (s3 + 2)/4 128 d (s1 + s3 + 4)/8 (s1 + 2)/4 (s3 + 2)/4 128 Tabel 4.2: DC-voorspellingsmodus voor chrominantieblokken 48

64 4.2 Intervoorspelling Intervoorspelling 5 wordt toegepast op macroblokken van het type P en B (uit P- en B-slices). Voor beide types is het mogelijk om het macroblok verder onder te verdelen in partities. De mogelijke blokgroottes worden afgebeeld in figuur De 16x16-matrix met luminantiesamples kan gepartitioneerd worden in één 16x16- blok, twee 8x16- of 16x8-blokken of vier 8x8-blokken. Een 8x8-blok wordt ook wel een submacroblok genoemd. Voor een submacroblok wordt een extra parameter verstuurd die aangeeft of het blok nog verder wordt onverdeeld in subpartities. Een submacroblok kan worden verdeeld in één 8x8-blok, twee 4x8- of 8x4-blokken of vier 4x4-blokken. De matrices met chrominantiesamples worden op dezelfde manier gepartitioneerd, maar met de helft van de horizontale en verticale dimensie (omwille van het onderbemosteringsformaat). Deze onderverdeling in partities en subpartities wordt tree structured motion compensation genoemd. [23] [24] Macrobloktypes 16 x x 8 8 x 16 8 x Submacrobloktypes 8 x 8 8 x 4 4 x 8 4 x Figuur 4.11: Blokgroottes voor intervoorspelling Voor elke partitie of subpartitie van de luminantiecomponent, moet een afzonderlijke bewegingsvector en een index van het gebruikte referentiebeeld worden verstuurd. De bewegingsvectoren voor de chrominantiecomponenten kunnen worden afgeleid van de bewegingsvector van de luminantiecomponent (gedeeld door twee) en hoeven dus niet verstuurd te worden. 5 zie [12]

65 Het is ook mogelijk dat een macroblok wordt gecodeerd in skipmodus. In dit geval worden geen macroblokdata verstuurd. Het corresponderende macroblok (op dezelfde positie) uit het vorige beeld wordt rechtstreeks gekopieerd P-macroblokken Voor de voorspelling van P-macroblokken is er één lijst (list0 ) met referentiebeelden beschikbaar. De beste match 6 voor een bepaald blok kan gezocht worden in beelden uit deze lijst. Wanneer de lijst meer dan één beeld bevat, kan in al deze beelden gezocht worden. Blokken van hetzelfde beeld kunnen voorspeld worden op basis van blokken uit verschillende referentiebeelden, maar er is telkens maar één bewegingsvector per blok. Dit vereist natuurlijk meer rekenkracht, maar de kans is groter dat een goede match wordt gevonden B-macroblokken De JVT/AVC-standaard ondersteunt de mogelijkheid om een lineaire combinatie van twee bewegingsvectoren te nemen ongeacht de locatie van de referentiebeelden. Zo is het mogelijk dat een linaire combinatie wordt genomen van een voorwaarts en een achterwaarts signaal, maar ook van twee voorwaartse en van twee achterwaartse signalen. Wanneer twee signalen uit dezelfde richting 7 worden gecombineerd, wordt dit de multihypothese-voorspellingsmodus genoemd. Om dit te realiseren, zijn er twee lijsten (list0 en list1 ) waaruit de twee signalen worden gehaald. Het is niet noodzakelijk dat list0 alle (temporeel) eerdere beelden bevat en list1 alle volgende. Beide lijsten kunnen om het even welke beelden bevatten. Macroblokmodi Er zijn vier groepen met voorspellingsmodi voor blokken uit een B-macroblok: 6 Het algoritme voor het zoeken naar de beste match wordt in de standaard niet vermeld. Dit is implementatie-afhankelijk. Het zoeken naar deze match is een vrij rekenintensief proces. Eventueel kan de implementatie worden aangepast aan de beschikbare hardware. Ook de manier waarop de partitionering van een macroblok of submacroblok gebeurt en de keuze van de voorspellingsmodus bij intravoorspelling, zijn niet normatief. 7 Dit wil zeggen dat de gebruikte beelden uit dezelfde lijst (list0 of list1) moeten komen. 50

66 Voorwaarts of achterwaarts: er is één voorspellingssignaal dat afkomstig is uit list0 of list1. Deze modi zijn gelijkaardig aan de intervoorspelling bij P- macroblokken. Gewogen voorspelling: combinatie van twee signalen afkomstig uit om het even welke buffer. Het kan dus gaan om zowel bidirectionele voorspelling als multihypothese voorspelling. Direct: hier wordt ook een combinatie van twee signalen genomen, maar de bewegingsvectoren en indices van de referentiebeelden worden niet doorgestuurd. Bij deze modus (enkel voor 16x16- en 8x8-blokken) worden de parameters afgeleid van het corresponderende macroblok met index nul in de buffer. Intra: gebruik van spatiale voorspelling. Bidirectionele versus multihypothese-voorspelling Bij bidirectionele voorspelling is enkel de combinatie mogelijk van een voorwaarts en een achterwaarts voorspellingspaar. Dit wordt geïllustreerd in figuur P B P B P Figuur 4.12: Bidirectionele voorspelling In figuur 4.13 wordt een voorbeeld gegeven van multihypothese-voorspelling waarbij een combinatie wordt gemaakt van twee voorwaartse signalen Subpixelbewegingsvectoren Bij intercodering hebben de bewegingsvectoren van de luminantiecomponent een precisie van 1/4 van de pixelafstand. De luminantiesamples van het referentiebeeld 51

67 P B P B P Figuur 4.13: Multihypothese-voorspelling op deze subpixelposities bestaan niet, maar worden op basis van naburige samples berekend. De samples op 1/2-pixelafstand worden door middel van interpolatie van zes naburige samples berekend. De samples op 1/4-pixelafstand worden berekend op basis van de samples op 1/2-pixelafstand en samples op pixelpositie. Voor de bewegingsvectoren van de chrominantiecomponenten is er een nauwkeurigheid van 1/8 nodig omwille van het onderbemonsteringsformaat. Subpixelbewegingsvectoren met een nauwkeurigheid van 1/4 van de pixelafstand geven een goede compressie-efficiëntie, maar verhogen wel de complexiteit Codering van de bewegingsvectoren De codering van een bewegingsvector voor elke partitie zou veel extra bits kunnen vereisen, zeker wanneer kleine partities worden gekozen. Bewegingsvectoren van naburige blokken zijn vaak sterk gecorreleerd. De JVT/AVC-standaard maakt van deze eigenschap gebruik door de bewegingsvectoren van naburige partities te gebruiken voor de voorspelling van de huidige bewegingsvector. Er wordt dus een voorspelling opgesteld en het verschil tussen de voorspelling en de eigenlijke bewegingsvector wordt gecodeerd en verstuurd. De berekening van de voorspelling hangt af van de beschikbaarheid (liggen in hetzelfde beeld en zijn niet intragecodeerd) van de naburige blokken. De bewegingsvectoren die kunnen gebruikt worden, zijn deze van de blokken A, B, C en D (zie figuur 4.14). De berekening van de bewegingsvector gaat als volgt. Eerst wordt de positie van het sample in de linker bovenhoek van blok E berekend, relatief ten opzichte 52

68 van het sample in de linker bovenhoek van het macroblok waartoe blok E behoort. Stel dat deze positie de coördinaten (x,y) heeft. Daarna wordt de coördinaat (x-1,y) berekend. Het sample met deze coördinaat ligt in blok A en van dit blok wordt dus de bewegingsvector genomen. Om de bewegingsvector van blok D te bekomen, wordt gekeken naar het blok waar het sample met coördinaat (x-1,y-1) in ligt. De bewegingsvector van blok B, is deze van het blok waar het sample met coördinaat (x,y-1) in ligt. En ten slotte de bewegingsvector van blok E is deze van het blok waar het sample met coördinaat (x+breedte van E, y-1) in ligt. De vector van blok D wordt (enkel) gebruikt als blok C niet beschikbaar is. In dit geval wordt in de berekening de bewegingsvector van D gebruikt in plaats van C. Wanneer voor de blokken A, B en C een bewegingsvector aanwezig is, is de voorspelling gelijk aan de mediaan van de drie vectoren 8. D A B E C Figuur 4.14: Naburige blokken die gebruikt worden voor de voorspelling van de bewegingsvector Voor 8x16- of 16x8-partities wordt de voorspelling van de bewegingsvector anders berekend. De bewegingsvector wordt overgenomen van één van de naburige blokken. Dit wordt aangegeven in figuur Als deze blokken niet beschikbaar zijn, wordt de voorspelling opgesteld volgens het principe van figuur Transformatie en quantisatie In eerdere standaarden wordt gebruikgemaakt van de 8x8-DCT-transformatie. Deze transformatie is niet verliesloos omwille van afrondingsfouten. De JVT/AVC-standaard maakt gebruik van drie geheelwaardige transformaties 9 voor het omvormen 8 mediaan(x,y,z) = x + y + z - min(x, min (y,z)) - max(x, max (y,z)) of met andere woorden het middelste getal. 9 zie [12]

69 D A 8 x 16 B C D 16 x 8 B A C Figuur 4.15: Voorspelling van de bewegingsvector voor 8x16- en 16x8-partities van de macroblokdata: [23] [24] 1. Transformatie voor de 4x4-matrix van DC-coëfficiënten van de luminantiecomponent in intragecodeerde macroblokken (zie paragraaf 4.3.2). 2. Transformatie voor de 2x2-matrix van DC-coëfficiënten van beide chrominantiecomponenten (zie paragraaf 4.3.3). 3. Transformatie voor de 4x4-blokken met residudata van de luminantie- en de chrominantiecomponenten (zie paragraaf 4.3.1). De data in een macroblok worden verstuurd in de volgorde zoals aangegeven is in figuur Als het macroblok in intra-16x16-modus is gecodeerd, wordt eerst de 4x4-matrix van DC-coëfficiënten van de luminantiecomponent doorgestuurd (blok -1). Alle DC-coëfficiënten in de blokken 0 tot 15 worden op nul gezet. Voor een macroblok gecodeerd in intra-4x4-modus, wordt blok -1 niet verstuurd. Voor elk type macroblok worden vervolgens de residublokken van de luminantiecomponent verstuurd (blokken 0 tot 15). Daarna volgen de twee 2x2-matrices met DC-coëfficiënten van de twee chrominantiecomponenten (blokken 16 en 17). Als laatste volgen de residublokken van de chrominantiecomponenten (blokken 18-25). 54

70 Figuur 4.16: Volgorde transformatie Transformatie en quantisatie voor de 4x4-blokken met residudata (blokken 0-15 en 18-25) Transformatie De orthogonale 10 transformatie is een benadering van de 4x4-DCT en wordt gegeven door 11 : C f = (4.3) Een 4x4-matrix X transformeren naar de matrix Y gaat als volgt: Y = (C f XCf T ) = X E (4.4) 10 Dit wil zeggen: T 1 = T T. De omvorming van de 4x4-DCT-matrix tot C f kan gevonden worden in appendix B. De naamgeving voor de matrices die hier verder gebruikt wordt, komt overeen met deze uit de appendix. 55

71 Hierbij is de scalaire vermenigvuldiging. Dit wil zeggen dat elk element C f XCf T wordt vermenigvuldigd met de schaalfactor op dezelfde positie in matrix E. Omdat het een geheelwaardige transformatie is, treden er geen afrondingsfouten op en kan de identieke reconstructie gebeuren door toepassing van de inverse transformatie. De transformatie is eenvoudig zodat een implementatie mogelijk is met enkel optel- en bitshiftoperaties. De matrix E is een schalingsmatrix, gegeven door: E = Waarin a, b en c worden gegeven door: a 2 ab/2 a 2 ab/2 ab/2 b 2 /4 ab/2 b 2 /4 a 2 ab/2 a 2 ab/2 ab/2 b 2 /4 ab/2 b 2 /4 (4.5) a = 1 2 b = 2 5 d = 1 2 (4.6) De matrix E wordt geïntegreerd in het quantisatieproces. Hierdoor wordt het totaal aantal nodige vermenigvuldigingen verminderd. Het volledige transformatie- en quantisatieproces kan uitgevoerd worden met berekeningen op 16-bits gehele waarden en er is slechts één vermenigvuldiging per coëfficiënt nodig, zonder verlies aan nauwkeurigheid. De inverse transformatie wordt gegeven door: X = (Ci T (Y E i)c i ) = /2 a 2 ab a 2 ab 1 1/2 1 1 Y 1 1/2 1 1 ab b 2 ab b 2 a 2 ab a 2 ab /2 ab b 2 ab b /2 1/ / /2 (4.7) Voor deze transformatie wordt Y herschaald door elke coëfficiënt te vermenigvuldigen met de overeenkomstige factor uit matrix E i. Merk op dat er in de matrices C i en C T i niet-gehele waarden voorkomen namelijk ±1/2. De implementatie van een vermenigvuldiging kan gebeuren door middel van de bitshiftoperatie naar links zonder significant verlies aan nauwkeurigheid aangezien de coëfficiënten van Y op voorhand werden geschaald (door matrix E i ). 56

72 Quantisatie In de standaard wordt gebruikgemaakt van een scalaire quantisatie. De definitie en implementatie zijn vrij ingewikkeld door de vereiste dat delingen of floatingpointbewerkingen moesten worden vermeden. Bovendien worden de schalingsmatrices E f en E i ook in het quantisatieproces verwerkt. De basis voorwaartse quantisatie voor elk element (i,j) uit Y, gaat als volgt: (Z) i,j = round( (Y ) i,j Qstep ) (4.8) waarbij (Y ) i,j een getransformeerde coëfficiënt is, Qstep de quantisatiestap en (Z) i,j de gequantiseerde coëfficiënt. In het totaal zijn er 52 verschillende waarden voor Qstep en deze worden geïndexeerd door de Quantisatie Parameter (QP). De waarden van Qstep overeenkomstig met elke QP zijn te vinden in tabel 4.3. De quantisatiestap verdubbelt bij het incrementeren van QP met 6. QP Qstep 0,625 0,6875 0,8125 0, ,125 1,25 1,1375 1,625 1, QP Qstep Tabel 4.3: Waarden voor Qstep geïndexeerd volgens QP De grote mogelijkheid aan quantisatiestappen laat de encoder toe een nauwkeurige trade-off te kunnen maken tussen bitsnelheid en kwaliteit. De QP voor de chrominantiecomponenten (QP C ) wordt afgeleid van de QP van de luminantiecomponent (QP Y ). Bij een sterke compressie, dus wanneer QP Y groot is, zijn de QP C relatief ten opzichte van QP Y minder groot (maximum 39), dit om geen zichtbaar kleurverlies te veroorzaken. De schaalfactoren a 2, ab/2 en b 2 /4 uit matrix E (zie vergelijking 4.5) worden verwerkt in de voorwaartse quantisatie. In de eerste stap wordt het inputblok X getransformeerd tot een matrix van ongeschaalde coëfficiënten namelijk, W = C f XC T f (zie vergelijking 4.4). Vervolgens wordt elk van de coëfficiënten (W ) i,j geschaald en gequantiseerd in één enkele operatie: P F (Z) i,j = round((w ) i,j Qstep ) (4.9) 57

73 Hierbij is PF (post-schalingsfactor) gelijk aan a 2, ab/2 en b 2 /4 afhankelijk van de positie (i,j) (zie tabel 4.4). Positie PF (0,0),(2,0),(0,2),(2,2) a 2 (1,1),(1,3),(3,1),(3,3) b 2 /4 andere posities ab/2 Tabel 4.4: Positie van de schaalfactoren De factor P F kan geïmplementeerd worden als een vermenigvuldiging met MF Qstep (multiplicatiefactor) en een rechtse bitshift om de deling te verwijderen. Volgende vergelijking wordt dus verkregen: met MF 2 qbits = P F Qstep MF (Z) i,j = round((w ) i,j ) (4.10) 2qbits en qbits = 15 + floor( QP 6 ) Als er moet gewerkt worden met enkel geheelwaardige bewerkingen, kan de bovenstaande vergelijking als volgt worden geïmplementeerd: (Z) i,j = ((W ) i,j MF + f) >> qbits (4.11) (met >> de rechtse binaire shiftoperatie). Hier is f = 2qbits 3 voor intragecodeerde blokken of f = 2qbits 6 voor intergecodeerde blokken. De eerste zes waarden van MF worden gegeven in tabel 4.5, afhankelijk van de QP en de positie van de coëfficiënt. Voor QP > 5, blijven de factoren MF onveranderd, maar de factor 2 qbits wordt telkens vermenigvuldigd met een factor 2 wanneer QP met 6 verhoogt. In de praktijk komt het verhogen van de QP met 6 overeen met een halvering van de bitsnelheid. 58

74 QP Posities (0,0),(2,0),(2,2),(0,2) Posities (1,1),(1,3),(3,1),(3,3) Andere posities Tabel 4.5: MF-waarden Inverse quantisatie De inverse quantisatie wordt gegeven door: (Y ) i,j = (Z) i,j Qstep (4.12) De schalingsfactor voor de inverse transformatie (matrix E i ) wordt verwerkt in deze operatie samen met de constante schaalfactor 64 om afrondingsfouten te vermijden: (W ) i,j = (Z) i,j Qstep P F 64 (4.13) (W ) i,j is een geschaalde coëfficiënt waarop de inverse transformatie (Ci T W C i ) wordt toegepast. De outputwaarden van de inverse transformatie worden gedeeld door 64 om de schalingsfactor te verwijderen (geïmplementeerd door middel van optellingen en rechtse shiftoperaties). Qstep of PF worden in de standaard niet direct gespecificeerd. In plaats daarvan wordt de parameter V = (Qstep P F 64) gedefinieerd voor 0 QP 5 voor elke positie van de coëfficiënt en de herschalingsoperatie is gelijk aan: (W ) i,j = (Z) i,j (V ) i,j 2 floor(qp/6) (4.14) De waarden van de herschalingsfactor V worden gegeven in tabel 4.6. De factor 2 qbits wordt telkens vermenigvuldigd met een factor 2 wanneer QP met 6 verhoogt. 59

75 QP Posities (0,0),(2,0),(2,2),(0,2) Posities (1,1),(1,3),(3,1),(3,3) Andere posities Tabel 4.6: Waarden van de herschalingsfactor V Transformatie en quantisatie voor de 4x4-DC-matrix van de luminantiecomponent (blok -1) Deze transformatie wordt enkel toegepast als het macroblok wordt voorspeld in intra-16x16-modus. Eerst wordt elk 4x4-residublok getransformeerd door middel van de transformatie in paragraaf Vervolgens wordt de DC-coëfficiënt van elk 4x4- blok opnieuw getransformeerd door middel van een 4x4-Hadamard-transformatie: Y D = W D (4.15) Hierbij is W D het blok met de 16 DC-coëfficiënten en is Y D het blok na transformatie. De coëfficiënten (Y D ) i,j worden nadien gedeeld door 2 (zonder afronding). De Hadamard-transformatie is zeer eenvoudig te berekenen en werd hier toegepast omdat de prestatie in vergelijking met de andere transformatie (uit paragraaf 4.3.1) even goed is. Vervolgens worden de coëfficiënten gequantiseerd: (Z D ) i,j = ((Y D ) i,j MF + 2f) >> (qbits + 1) (4.16) met MF, f en qbits zoals voorheen en MF afhankelijk van de positie (i,j) in het 4x4-DC-blok. In de decoder wordt eerst de inverse Hadamard-transformatie toegepast, gevolgd door de inverse quantisatie. De volgorde wordt dus niet omgekeerd zoals misschien 60

76 te verwachten is. W QD = Z D (4.17) Als QP groter is dan 12, wordt de herschaling uitgevoerd door: (W D) i,j = (W QD ) i,j (V ) 0,0 2 floor(qp/6) 2 (4.18) En als QP kleiner is dan 12, wordt volgende herschaling toegepast: (W D) i,j = [ (W QD ) i,j (V ) 0, floor(qp/6)] >> (2 floor(qp/6)) (4.19) V is hetzelfde als voorheen. De herschaalde DC-coëfficiënten W D worden vervolgens in hun respectievelijke 4x4-blokken ingevoegd en op deze blokken wordt de inverse transformatie toegepast. In een intragecodeerd macroblok is veel van de energie geconcentreerd in de DC-coëfficiënten. Deze extra transformatie helpt de decorrelatie van de 4x4-DCcoëfficiënten van de luminantiecomponent Transformatie en quantisatie van de 2x2-DC-matrices van de chrominantiecomponenten (blokken 16 en 17) Elke chrominantiecomponent uit een macroblok bestaat uit vier 4x4-blokken. Elk 4x4-residublok wordt getransformeerd op de wijze zoals aangegeven in paragraaf De DC-coëfficiënten van elk 4x4-blok worden gegroepeerd in een 2x2-blok (W D ) en worden verder getransformeerd door toepassing van de 2x2-Hadamardtransformatie: Y D = [ ] [ W D ] [ ] (4.20) 61

77 Y D wordt vervolgens gequantiseerd: Z D(i,j) = ( Y D(i,j) MF + 2f ) >> (qbits + 1)) (4.21) met MF, f en qbits als voorheen. Bij het decoderen wordt eerst de inverse transformatie toegepast en daarna de inverse quantisatie: W QD = [ Z D ] Als QP groter is dan 6, dan is de inverse quantisatie gelijk aan: (4.22) Anders, als QP kleiner is dan 6: (W D) i,j = (W QD) i,j (V ) 0,0 2 floor(qp/6) 2 (4.23) (W D) i,j = [ ] (W QD) i,j (V ) 0,0 >> 1 (4.24) Deze coëfficiënten worden geplaatst in hun respectievelijke 4x4-blokken van chrominantiecoëfficiënten waarop dan de inverse transformatie uit paragraaf wordt toegepast. Net zoals bij de DC-coëfficiënten van de luminantiecomponent van intragecodeerde macroblokken zorgt deze transformatie voor de decorrelatie van de DC-coëfficiënten en verbetert ze zo de prestatie van de entropiecodering Het volledige transformatie-, quantisatie- en herschalingsproces Het volledige proces voor een inputblok X naar een blok X wordt hieronder beschreven en geïllustreerd in figuur Encoderen 1. Inputblok: X 2. Voorwaartse transformatie: W = C f XCf T. Deze transformatie wordt gevolgd door de 2x2-transformatie voor de DCcoëfficiënten van de chrominantiecomponenten en eventueel ook voor de 62

78 4x4-transformatie voor de DC-coëfficiënten van de luminantiecomponent (indien het macroblok intragecodeerd is). 3. Schaling en quantisatie: Z = W MF 2 qbits. Deze schaling en quantisatie wordt aangepast voor de 2x2-transformatie Decoderen van de DC-coëfficiënten van de chrominantiecomponenten en eventueel de 4x4-transformatie van de DC-coëfficiënten van de luminantiecomponent (indien het macroblok intragecodeerd is). 1. Inverse quantisatie en herschaling: W = Z Qstep P F Inverse transformatie: X = C T i W C i. Voor de DC-coëfficiënten van de chrominantiecomponenten en eventueel de DC-coëfficiënten van de luminantiecomponent (indien het macroblok intragecodeerd is) wordt de inverse transformatie, quantisatie en herschaling aangepast. 3. Outputblok: X (een benadering van het originele blok X) Inputblok X Voorwaartse transformatie Schaling en quantisatie Inverse quantisatie en herschaling Inverse transformatie Outputblok X' 2x2- of 4x4-DCtransformatie Inverse 2x2- of 4x4-DCtransformatie Figuur 4.17: Overzicht van het transformatie- en quantisatieproces 4.4 VLC-gebaseerde entropiecodering Afhankelijk van de entropiecoderingsmodus worden de syntaxelementen in de slicelaag 12 en lager gecodeerd door middel van ofwel variabele lengte codering (VLC) of 12 Hiermee wordt de slicedata bedoeld zonder de sliceheader. 63

79 CABAC (zie paragraaf 4.5). Als entropy coding mode flag gelijk is aan nul worden de residublokken gecodeerd gebruikmakend van Context-based Adaptive Variable Length Coding (CAVLC) 13 en de andere symbolen worden gecodeerd met Universal Variable Length Coding (UVLC) 14. [23] [22] UVLC De UVLC-tabel 15 is opgebouwd door middel van omkeerbare exponentiële Golombcodering 16. Deze codering behoort tot de familie van de prefixcodes. Het gebruik van een omkeerbare codering verhoogt de foutbestendigheid[32]. Het is voor de decoder namelijk zeer moeilijk om na de detectie van een fout, het begin van het volgende codewoord te vinden omdat alle codewoorden een variabele lengte hebben. omkeerbare codes kan de decoder op het moment dat een fout wordt gedetecteerd, de decodering starten aan het einde van de bitstroom. De constructie van de codewoorden gebeurt op een regelmatige manier. Eerst worden de symbolen die moeten gecodeerd worden geordend volgens dalende waarschijnlijkheid. Met elk symbool wordt vervolgens een natuurlijk getal geassocieerd (code num) beginnend bij nul voor het meest waarschijnlijke symbool. Voor elke waarde van code num wordt vervolgens het codewoord geconstrueerd. De constructie van de codewoorden wordt getoond in tabel 4.7. Een codewoord bestaat uit een prefix- en suffixgedeelte. In het suffixgedeelte kan x i de waarde 0 of 1 aannemen. De eerste acht codewoorden worden getoond in tabel 4.8. De codewoorden vertonen een regelmatige opbouw: [M nullen][1][in F O] waarbij INFO een veld van M bits is met bepaalde informatie. Het eerste codewoord begint niet met nullen en heeft ook geen INFO deel. De codewoorden 1 en 2 hebben een INFO-veld met een lengte van één bit; codewoorden 3-6 hebben een 2-bits INFO-veld; en zo verder. De lengte van elk codewoord is gelijk aan (2M + 1) bits. [22] 13 zie [12] zie [12] Deze vorm van entropiecodering wordt ook toegepast op een aantal syntaxelementen die voorkomen in de SPS en de PPS (zie paragraaf 6.2.3). 16 Dit is een variant van de Golomb-codering zoals aangegeven in paragraaf 2.3.2, Golomb- en Rice-codes. Bij 64

80 vorm van het codewoord bereik van code num x x 1 x x 2 x 1 x x 3 x 2 x 1 x x 4 x 3 x 2 x 1 x Tabel 4.7: Opbouw codewoorden voor de exponentiële Golomb-codering code num codewoord Tabel 4.8: Codewoorden voor de exponentiële Golomb-codering Coderen en decoderen Elk codewoord wordt in de encoder geconstrueerd op basis van code num. berekening van M en INFO gaat als volgt: M = log 2 (code num) + 1 INF O = code num M De Aan de decoderzijde kunnen codewoorden op volgende wijze opnieuw worden omgezet naar code num: 1. lees de M nullen gevolgd door een 1 2. lees het INFO-veld (M bits) 3. code num = 2 M + INF O 1 65

81 Wanneer onmiddellijk de waarde 1 wordt ingelezen, wordt dit vertaald in code num = 0. Afbeelding van symbolen op code num waarden Een symbool v kan op vier manieren worden afgebeeld op de index code num: 1. ue(v): unsigned direct exponential golomb Directe afbeelding: de syntaxelementen worden direct afgebeeld op de code num waarde. Deze afbeelding wordt gebruikt voor het macrobloktype, de index van het referentiebeeld, se(v): signed exponential golomb Hierbij wordt de absolute waarde van syntaxelementen berekend. Deze worden in stijgende volgorde geordend en als volgt afgebeeld: code num = 2 v (v 0) code num = 2 v 1 (v > 0) Zie ook tabel 4.9. Deze afbeelding wordt bijvoorbeeld gebruikt om bewegingsvectorverschillen te coderen. 3. me(v): mapped symbol exponential golomb Het symbool v wordt afgebeeld op code num op basis van een tabel in de standaard 17. Deze afbeelding wordt gebruikt voor de parameter coded block - pattern 18. Deze geeft aan welk van de zes 8x8-blokken van een macroblok (vier van de luminantiecomponent en één van elke chrominantiecomponent) niet-nul coëfficiënten bezitten. 4. te(v): truncated exponential golomb In dit geval wordt eerst het bereik van het syntaxelement bepaald. Dit bereik is tussen 0 en x (met x 1). Wanneer x groter is dan 1, gebeurt de afbeelding volgens één van de drie vorige mogelijke mappings. Als x gelijk is aan 1, dan is code num voor het symbool v gelijk aan!v (met! de binaire NOT-operator). 17 zie [12] zie [12]

82 v code num Tabel 4.9: Signed mapping CAVLC Deze methode wordt gebruikt voor het coderen van de zigzag-geordende 4x4- (en 2x2-) blokken na transformatie en quantisatie 19. Een context is algemeen gezien het resultaat van één of andere bewerking op de reeds gekende - en reeds gecodeerde - symbolen. Hier leveren contexten symboolwaarschijnlijkheden aan de entropiecoder. CAVLC is ontworpen om de karakteristieken van de gequantiseerde transformatiecoëfficiënten optimaal te kunnen uitbuiten, namelijk: 1. Na voorspelling, transformatie en quantisatie zijn de blokken ijl, ze bevatten met andere woorden vooral nullen. CAVLC maakt gebruik van (run,level)- codering om de opeenvolgende nullen op een compacte manier voor te stellen. 2. De laatste niet-nulcoëfficiënten na zigzag-scan zijn meestal sequenties met de waarde ±1. De ±1-coëfficienten op het einde (trailing 1 s of T1 s) worden op een compacte manier voorgesteld. 3. Het aantal niet-nulcoëfficiënten in naburige blokken is meestal sterk gecorreleerd. Dit aantal wordt gecodeerd door middel van een opzoektabel. Afhankelijk van het aantal niet-nulcoëfficiënten in de naburige blokken wordt gekozen voor een andere opzoektabel (Context Adaptive). 4. De waarde van de niet-nulcoëfficiënten (level) is normaal gezien hoger dicht bij de DC-coëfficiënt dan verder van deze coëfficiënt. CAVLC exploiteert deze eigenschap door de codering van de levels te laten afhangen van recent gecodeerde levels. 19 In [12] zijn dit de syntaxelementen aangeduid met ce(v). 67

83 Een voorbeeld van de toepassing van CAVLC kan gevonden worden in hoofdstuk 7 paragraaf 7.1. Het is aan te raden de volgende uitleg samen met het voorbeeld door te nemen. De codering van een blok gequantiseerde transformatiecoëfficiënten met CAVLC gaat als volgt: 1. Codering van het aantal coëffiënten en T1 s. Het eerste syntaxelement, coeff token, codeert het totaal aantal niet-nulcoëfficiënten (verder TotaalC genoemd) en het aantal T1 s. TotaalC kan een waarde van 1 tot 16 bevatten en T1 kan een waarde van 0 tot 3 bevatten. Als er meer dan drie T1 s zijn, worden enkel de laatste drie als speciaal geval behandeld, de andere worden als normale coëfficiënten gecodeerd. Voor de codering van coeff token is er een keuze tussen vier VLC-tabellen en één FLC-tabel (Fixed Length Code). De keuze van de tabel is afhankelijk van het aantal niet-nul coëfficiënten van het blok juist boven (B) en het blok links van (A) het huidige blok (zie figuur 4.6). Als de blokken A en B beschikbaar zijn, is nc = (na+nb+1)/2. Als enkel A beschikbaar is, wordt nc = na en als enkel B beschikbaar is, wordt nc = na. Als beide blokken niet beschikbaar zijn, is nc = 0. Merk op dat het aantal niet-nulcoëfficiënten voor blokken gecodeerd in intra-16x16-modus gelijk is aan het aantal niet-nul-ac-coëfficiënten. De DC-coëfficiënten zitten immers in een apart blok. Voor de 2x2-matrix met DC-coëfficiënten van de chrominantiecomponenten is nc = 1. In tabel wordt de keuze van de opzoektabel getoond in functie van de waarde van nc. Op deze manier wordt de keuze van VLC-tabel (of FLCtabel) aangepast aan het aantal gecodeerde coëfficiënten in naburige blokken (contextafhankelijk ). VLC0 zorgt voor een efficiënte compressie bij een klein aantal coëfficiënten. Lage waarden van coeff token krijgen een korte code en hoge waarden, die minder waarschijnlijk zijn, krijgen een langere code. VLC1 is aangepast aan een middelmatige grootte van coeff token (2 of 3). VLC2 is aangepast aan een vrij grote waarde van coeff token en de FLC assigneert een vast 6-bits codewoord voor elke waarde van coeff token. Dit 6-bits codewoord is als volgt opgebouwd: xxxxyy. Het eerste deel xxxx bevat TotaalC-1 en yy is gelijk aan T1. 20 De gebruikte naamgeving komt niet in de standaard voor, maar vergemakkelijkt deze uitleg. 68

84 N Tabel voor coeff token 0 nc < 2 VLC0 2 nc < 4 VLC1 4 nc < 8 VLC2 8 nc FLC nc = 1 VLC3 Tabel 4.10: Keuze tabel voor coeff token. 2. Codering van het teken van elke T1. Voor elk van de T1 s in coeff token, wordt het teken in 1 bit gecodeerd. Een nul-bit staat voor een positieve T1 en een 1-bit voor een negatieve T1. Deze bits worden in omgekeerde volgorde gecodeerd, beginnend bij de T1 met de hoogste frequentie (laatste T1). 3. Codering van de levels van de resterende niet-nul coëfficiënten. Het level (teken en grootte) van elk van de resterende coëfficiënten in een blok wordt ook in omgekeerde volgorde gecodeerd, beginnend bij de coëfficiënt met de hoogste frequentie tot aan de DC-coëfficiënt. De codering van een coëfficiënt is afhankelijk van de grootte van de coëfficiënten die in zigzag-scan volgen op de huidige coëfficiënt. Deze zijn reeds gecodeerd aangezien de coëfficiënten in omgekeerde volgorde worden doorlopen. In het totaal is er een keuze tussen zeven VLC-tabellen, genaamd Level VLC0 tot Level VLC6 21. Level VLC0 zorgt voor een goede compressie bij lagere (absolute) waarden van de coëfficiënten. Level VLC6 is aangepast voor blokken met hoge waarden voor de coëfficiënten. De keuze van de tabel wordt als volgt bepaald: Initialiseer de keuze van de tabel op Level VLC0 tenzij er meer dan 10 niet-nulcoëfficiënten en minder dan drie T1 s zijn. In dat geval wordt de keuze van de tabel op Level VLC1 geïnitialiseerd. Codeer de eerste niet-nulcoëfficiënt. Dit is de coëfficiënt met de hoogste frequentie aangezien de coëfficiënten in omgekeerde volgorde worden doorlopen. Als de grootte van deze coëfficiënt groter is dan een zekere grenswaarde, 21 Naamgeving niet in de standaard gebruikt. 69

85 wordt de volgende VLC-tabel gekozen voor de codering van deze coëfficiënt. De grenswaarden zijn te vinden in tabel huidige VLC-tabel grenswaarde Level VLC0 0 Level VLC1 3 Level VLC2 6 Level VLC3 12 Level VLC4 24 Level VLC5 48 Level VLC6 - Tabel 4.11: Grenswaarden die bepalen of het level tabelnummer wordt verhoogd. Level VLC6 heeft geen overeenkomstige grenswaarde aangezien dit de laatste VLC-tabel is. 4. Codering van het totaal aantal nullen vóór de laatste coëfficiënt. De parameter TotalZeros is het totaal aantal nullen vóór de hoogste nietnulcoëfficiënt in de herordende matrix. Deze parameter wordt gecodeerd door middel van VLC. 5. Codering van elke run van nullen. Het aantal nullen voorafgaand aan elke niet-nulcoëfficiënt (run before) wordt gecodeerd in omgekeerde volgorde. Voor elke niet-nulcoëfficiënt wordt een run before gecodeerd, startend bij de hoogste frequentie behalve in volgende twee gevallen: Als er geen nullen meer te coderen zijn (het nog te overlopen stuk van het blok bevat enkel niet-nulcoëfficiënten), is het niet meer nodig om nog run before-parameters te coderen. In dit geval is Σ[run before] = total zeros. Het is niet nodig om een run before-parameter te encoderen voor de laatste niet-nulcoëfficiënt. Dit aantal is immers gelijk aan total zeros Σ[run before]. Het VLC-codewoord voor elke rij opeenvolgende nullen is afhankelijk van het aantal nullen dat nog niet is gecodeerd (ZerosLeft) en run before. Bijvoorbeeld, als er maar 2 nullen meer te coderen zijn 70

86 dan kan run before enkel de waarden 0, 1 of 2 aannemen. Het VLCcodewoord hiervoor moet dus slechts 2 bits lang zijn. Stel dat er nog 6 nullen moeten worden gecodeerd, dan kan run before 7 waarden aannemen en zijn er slechts 3 bits nodig voor het VLC-codewoord. Voor de 2x2-matrices met DC-coëfficiënten worden afzonderlijke VLC-tabellen gebruikt. 4.5 CABAC-gebaseerde entropiecodering Wanneer entropy coding mode flag gelijk is aan 1, worden alle syntaxelementen van de slicelaag en de macrobloklaag gecodeerd door middel van Context-based Adaptive Binary Arithmetic Coding (CABAC) 22. Deze codering behoort tot de familie van de aritmetische coderingen die globaal gezien efficiënter zijn dan prefixcodes. Het optimum aantal bits is gelijk aan de informatieve inhoud, namelijk log 2 (1/P ) met P gelijk aan de probabiliteit van het symbool. Deze probabiliteit wordt bij elke stap aangepast, waardoor CABAC bijzonder geschikt is voor symbolen waarvan de probabiliteiten veranderen. CABAC codeert enkel binaire symbolen, sommige symbolen zullen dus eerst moeten worden omgezet in een binaire representatie. Verder maakt CABAC ook gebruik van contextinformatie. Dit wil zeggen dat voor een bepaald symbool een contextmodel wordt gekozen, rekening houdend met eerder gecodeerde symbolen van hetzelfde type. Dit model bepaalt voor elk van de bits van de binaire codewoorden een probabiliteitsdistributie. Hierdoor wordt de eigenschap dat bepaalde symbolen voor naburige blokken vaak gecorreleerd zijn, (zoals bijvoorbeeld bewegingsvectoren) uitgebuit. [23] [19] Omzetting van symbolen in een binaire representatie Afhankelijk van het symbool (dit wordt in een tabel opgegeven in de standaard 23 ), kan de binairisatie op verschillende manieren gebeuren. 22 zie [12] tabel 9.24 in [12]

87 Unaire binairisatie In tabel 4.12 wordt getoond hoe de omzetting gebeurt. De waarde van het syntaxelement bepaalt de lengte van de binaire string (resultaat van het binairisatieproces). Een element v met waarde C wordt omgezet in een binaire string met C eentjes gevolgd door één nul. De variabele binidx is een index die de positie bijhoudt van een bepaald bin (binairy decision). Bin 0 is gelijk aan de meest significante bit van een codewoord, enzoverder. Hier is bin = 1 als binidx < C. Unaire binairisatie wordt onder andere gebruikt voor de indices van referentiebeelden bij intervoorspelling. Waarde van het syntaxelement Binaire string binidx Tabel 4.12: Unaire binairisatie Truncated unaire binairisatie Deze binairisatie is geschikt voor symbolen waarvan de waarden komen uit een eindig alfabet, namelijk {0,..., cmax}. Een symbool met waarde C < cmax wordt via unaire binairisatie omgezet naar een binaire string. Wanneer C = cmax is het resultaat een binaire string bestaande uit cmax eentjes. Combinatie van truncated unaire binairisatie met exponentiële Golombcodering van k-de orde Een codewoord wordt omgezet in een binaire string bestaande uit twee delen, het prefix- en het suffixgedeelte. Het prefixgedeelte wordt geconstrueerd door middel van truncated unaire binairisatie. 72

88 Het suffixgedeelte wordt opgebouwd door middel van exponentiële Golomb-codering van k-de orde (EGk) (zie paragraaf Golomb- en Ricecodes). De parameter k is afhankelijk van het symbool en wordt in een tabel in de standaard gespecificeerd. Deze tabel geeft ook aan of de symbolen signed of unsigned waarden kunnen aannemen (signedvalflag) en voorziet een cut off parameter (ucoff). Het prefixgedeelte is gelijk aan het resultaat van de truncated unaire binairisatie van M in(ucoff, S ), met S de waarde van het syntaxelement. Symbolen waarvan de waarde enkel positief kan zijn, hebben enkel een prefixgedeelte wanneer S < ucoff. Voor bepaalde symbolen zijn kleine waarden meer waarschijlijk en deze worden zo naar een kortere binaire string omgezet dan grotere waarden. Symbolen die ook unsigned waarden kunnen aannemen, hebben enkel een prefixgedeelte wanneer S = 0. De cut-off-parameter geeft dus aan dat ofwel de volledige waarde in het prefixgedeelte omvat zit, ofwel een deel. Het suffixgedeelte zet de rest (sufs) van de waarde van S om in een binaire representatie door middel van EGk. Deze rest is gelijk aan ( S ucoff). Voorbeeld: Een symbool S moet gebinairiseerd worden door middel van UEG3, signedvalflag= 1 en ucoff = 9: Stel dat de waarde van S gelijk is aan 18. Het prefixgedeelte is gelijk aan en suf S = 9. Voor deze waarde wordt het EG3-codewoord berekend. Eerst het unair deel: 9/8 = 1, er wordt bijgevolg één 1 gezet. Het unair deel wordt afgesloten met één 0. Daarna het binair gedeelte: 9 mod 8 = 1 wordt voorgesteld met log 2 8 = 3 bits. Het uiteindelijke resultaat is Fixed Length binairisatie Fixed Length binairisatie zet de waarde van een syntaxelement om in een binair getal met L bits waarbij L = log 2 (cmax + 1). De bins worden genummerd beginnend bij de minst significante bit (binidx = 0). 73

89 Andere Voor bepaalde symbolen is er een specifiek binairisatieproces gedefinieerd in de standaard 24. Dit is het geval voor het macroblok en submacroblok type, coded block - pattern en mb qp delta Codeerproces De symbolen worden slice per slice gecodeerd. Bij het begin van elke slice worden de contextmodellen geïnitialiseerd op basis van de globale quantisatieparameter van het slice. Deze parameter wordt voor elke macroblok gebruikt, tenzij er voor het macroblok zelf een afzonderlijke QP wordt opgegeven. Voor elk bin van een gebinairiseerd symbool worden volgende stappen doorlopen: 1. Selectie van het contextmodel Bij de eerste bin wordt het contextmodel gekozen. er verschillende contextmodellen mogelijk. af van reeds gecodeerde (naburige) symbolen. Voor elk symbool zijn De keuze bij initialisatie hangt Het contextmodel houdt de probabiliteit bij van de waarde 1 en 0 (de mogelijke waarde die een bin kan aannemen). Voor volgende bins wordt het contextmodel eventueel aangepast (dit is afhankelijk van het symbool en wordt gespecificeerd in de standaard). 2. Aritmetische codering De aritmetische codering van de bin gebeurt op basis van het geselecteerd probablititeitsmodel. Dit zorgt voor de verdeling van het interval [0, 1[ in twee subintervallen, één voor de waarde 1 en de ander voor de waarde Aanpassing van het probabiliteitsmodel De mogelijke contextmodellen worden aangepast op basis van de uiteindelijke waarde van het bin. Als de bin bijvoorbeeld gelijk is aan 0, wordt de probabiliteit van 0 verhoogd, en van 1 verlaagd. De combinatie van contextmodellering en artimetische codering vergt meer geheugenruimte en rekenkracht dan bijvoorbeeld prefixcodes, maar geeft wel een betere compressie. 24 zie [12] tot Deze parameter kan de QP (opgegeven in de sliceheader) veranderen op macroblokbasis. 74

90 4.6 De antiblokfilter De laatste stap van het decoderingsproces is de toepassing van een in-loop antiblokfilter 26 (reconstructiefilter) op de blokranden. Omdat de randen van de blokken worden gereconstrueerd met een kleinere nauwkeurigheid dan pixels binnenin een blok, geeft dit aanleiding tot een duidelijk zichtbare blokstructuur. Het gebruik van de filter verbetert zowel de subjectieve visuele kwaliteit als de objectieve kwaliteit van een gedecodeerd beeld. Het voordeel van een in-loop filter is dat de gefilterde versie van het beeld als referentie wordt gebruikt in encoder en decoder. Hierdoor kan het opstellen van de intervoorspelling nauwkeuriger gebeuren, wat uiteindelijk minder gecodeerde data zal vereisen. De filter werkt in op de randen van de 4x4-subblokken van een macroblok (zelfs als een blok in intra-16x16-modus werd gecodeerd). De randen van het beeld zelf worden niet gefilterd. De filter kan worden geconditioneerd door een vlag in de slice header. Deze vlag kan de filter afzetten voor het huidige slice, kan aangeven dat enkel slicegrenzen niet gefilterd moeten worden of dat alle grenzen moeten worden gefilterd. [23] [21] De volgorde van filtering is: (zie ook figuur 4.18): de 4 verticale randen van de 4x4-blokken van de luminantiecomponent de 4 horizontale randen van de 4x4-blokken van de luminantiecomponent de 2 verticale randen van elke chrominantiecomponent de 2 horizontale randen van elke chrominantiecomponent Voor de luminantiecomponent worden tot drie samples langs elke kant van de grens tussen twee blokken (blok p en blok q, zie figuur 4.19) aangepast bij een filteroperatie en voor de chrominantiecomponenten tot twee samples. De sterkte van de filter is afhankelijk van verschillende syntaxelementen, namelijk de huidige QP van de twee blokken, de codeermodi van de blokken en de gradiënt (verandering van de helderheid of van de kleur) van de samples over de grens heen. Door met deze elementen rekening te houden is er geen vervagingseffect (scherpe grenzen blijven). De samplewaarden die worden gebruikt bij het filteren voor de luminantiecomponent en chrominantiecomponenten worden getoond in figuur zie [12]

91 16x16-luminantieblok 8x8-chrominantieblok verticale randen horizontale randen verticale randen horizontale randen Figuur 4.18: Volgorde van filtering in een macroblok p q Figuur 4.19: Twee aangrenzende blokken (p en q) p3 p2 p1 p0 q0 q1 q2 q3 luminantie p1 p0 q0 q1 chrominantie Figuur 4.20: Samples gebruikt bij toepassing antiblokfilter Grenssterkte De grenssterkte (Bs 27 ) die bepaald wordt door de coderingsmodus van de twee blokken, is de eerste karakteristiek die gebruikt wordt voor het bepalen van de sterkte van de filter. Bs wordt gekozen op basis van de volgende regels: Bs = 4: (sterkste filter) p of q is intragecodeerd en de grens is een macroblok- 27 Border strength 76

92 grens (p en q behoren tot verschillende macroblokken). Bs = 3: p of q is intragecodeerd en de grens is geen macroblokgrens. Bs = 2: geen van de blokken is intragecodeerd en minstens één van de blokken bevat gecodeerde coëfficiënten. Bs = 1: geen van de blokken is intragecodeerd, ze bevatten ook geen gecodeerde coëfficiënten 28, maar p en q hebben verschillende referentiebeelden of een verschillend aantal referentiebeelden of verschillende waarden voor de bewegingsvectoren. Bs = 0: skipmodus of met andere woorden, er wordt geen filtering toegepast als aan alle volgende voorwaarden wordt voldaan: noch p noch q is intragecodeerd; p en q bevatten geen gecodeerde coëfficiënten; p en q hebben hetzelfde referentiebeeld en identieke bewegingsvectoren. De filter is sterker bij grenzen waar er meer kans is op blokartefacten zoals de grens met een intragecodeerd macroblok of een grens met een blok dat gecodeerde coëfficiënten bevat. Bepaling van de sterkte van de filter De antiblokfilter wordt toegepast wanneer onderstaande voorwaarden beide voldaan zijn: 1. Bs > 0 (grenssterkte) 2. p0 q0 < α en p1 p0 < βen q1 q0 < β (gradiënt) De waarden van α en β worden bepaald door de gemiddelde waarde van de QP s van de blokken p en q. In de sliceheader kunnen optioneel twee filteroffsetwaarden worden meegegeven die ook een invloed kunnen hebben op de waarde van α en β en dus de sterkte van de filter. De tweede voorwaarde zorgt ervoor dat de filter wordt uitgeschakeld wanneer er een significante verandering (gradiënt) is in helderheid of kleur over de grens 28 Dit wil zeggen dat coded block pattern gelijk is aan nul. 77

93 heen. Op deze manier worden scherpe, dus duidelijk zichtbare grenzen niet gefilterd, zodat het beeld niet vervaagt. De waarden voor α en β worden groter naarmate de gemiddelde QP waarde groter wordt. Bij een grote QP is de blokvorming immers meestal groter. Voorbeeld In figuur 4.21 worden twee identieke beelden uit de sequentie foreman getoond, waar de filter al of niet werd toegepast. Figuur 4.22 is een uitvergroot deel van het beeld uit figuur 4.21 waar de werking van de antiblokfilter duidelijker is op te zien. (a) met antiblokfilter (b) zonder antiblokfilter Figuur 4.21: Beeld uit foreman met de antiblokfilter (a) en zonder de antiblokfilter (b) Filterimplementatie 1. Voor 0 < Bs < 4 In de luminantiecomponent worden minimum één, maximum twee waarden langs de grens gefilterd waarbij gebruikgemaakt wordt van p2, p1, p0, q0, q1 en q2. Voor de chrominantiecomponenten wordt er één waarde langs beide kanten van de grens gefilterd, gebruikmakend van p1, p0, q0 en q1. De waarden p0 en q0 worden vervangen door P0 en Q0. Hierbij is P 0 = p0+ en Q0 = q0 + waarbij de berekende waarde tussen 0 en 255 ligt. De grootte van wordt onder andere bepaald door de grenssterkte (Bs). 78

94 (a) met antiblokfilter (b) zonder antiblokfilter Figuur 4.22: Detail van een beeld met de antiblokfilter (a) en zonder de antiblokfilter (b) Wanneer p2 p0 < β voldaan is, dan wordt p1 gefilterd op basis van p0, p1, q0 en q1 tot de nieuwe waarde P1. En als q2 q0 < β voldaan is wordt q1 gefilterd op basis van p0, p1, q0 en q1 tot Q1. 2. Voor Bs = 4 Er worden in de luminantiecomponent één of drie samplewaarden gefilterd op basis van p3, p2, p1, p0, q0, q1, q2 en q3. In de chrominantiecomponenten wordt telkens maar één waarde gefilterd. Wanneer p2 p0 < β en p0 q0 < (α/4 + 2) voldaan zijn, dan worden p0, p1, p2 vervangen door de gefilterde waarden P0, P1 en P2. Anders wordt enkel p0 vervangen door P0. Wanneer q2 q0 < β en p0 q0 < (α/4 + 2) voldaan zijn, dan worden q0, q1, q2 vervangen door de gefilterde waarden Q0, Q1 en Q2. Anders wordt enkel q0 vervangen door Q0. 79

95 Hoofdstuk 5 Schaalbaarheid in de JVT/AVC-standaard In dit hoofdstuk wordt de mogelijkheid tot schaalbare videocodering in de JVT/AVCstandaard besproken. Eerst wordt een overzicht gegeven van schaalbaarheid in het algemeen en vervolgens wordt besproken hoe schaalbaarheid zou kunnen toegepast worden in de JVT/AVC-standaard. Momenteel wordt schaalbaarheid nog niet ondersteund in de JVT/AVC-standaard, alhoewel het één van de doelstellingen was [11]. Er werd wel een nieuw beeldtype geïntrodu ceerd dat het efficiënt overschakelen tussen bitstromen mogelijk maakt. De functionaliteit en toepassingen van dit nieuwe beeldtype worden in het laatste deel van dit hoofdstuk besproken. 5.1 Schaalbare videocodering Schaalbaarheid Traditioneel was het objectief van videocodering het optimaliseren van de kwaliteit van de video voor één bepaalde bitsnelheid (bijvoorbeeld, het coderen van een videosequentie aan 1500 kbps door middel van MPEG-1). De opkomst van videotoepassingen zoals het stromen van video over het Internet hebben dit objectief veranderd. In figuur 5.1 wordt de configuratie getoond voor toepassingen gericht op het stromen van data over een netwerk. De gecodeerde videosequenties worden opgeslagen op de (video-)server en deze verstuurt de sequenties naar de clients waar ze 80

96 gedecodeerd worden. Encoder Server Kanaal Client / Decoder Figuur 5.1: Systeemconfiguratie voor toepassing gericht op het stromen van data over het Internet De verandering van het oorspronkelijke objectief is vereist omdat de kanaalcapaciteit van het netwerk sterk kan variëren afhankelijk van het type van de connectie. In traditionele communicatiesystemen comprimeert de encoder het originele videosignaal zodat de bitsnelheid kleiner is dan de capaciteit van het netwerk of deze benadert. Hierbij worden twee veronderstellingen gemaakt. Ten eerste moet de encoder de capaciteit van het netwerk kennen en ten tweede moet de decoder in staat zijn het ontvangen signaal snel genoeg te decoderen om de video te reconstrueren. Deze twee veronderstellingen kunnen bij toepassingen gericht op het stromen van data, niet zonder meer worden aangenomen. Een eerste reden hiervoor is dat de encoder niet weet aan welke bitsnelheid de video moet worden geoptimaliseerd door de reeds vermelde variërende netwerkcapaciteit. Ten tweede wordt in de client steeds meer gebruikgemaakt van een softwaredecoder die zijn middelen (resources) moet delen met andere toepassingen. Hierdoor is het mogelijk dat de client niet alle ontvangen bits snel genoeg kan decoderen voor de reconstructie van de video. Het optimaliseren van de videokwaliteit, gegeven een bepaald bereik voor de bitsnelheid, kan beschouwd worden als het huidige objectief van videocodering. Het ontvangen videosignaal moet gedeeltelijk gedecodeerd kunnen worden binnen dit bereik. In figuur 5.2 wordt dit geïllustreerd. [31] De x-as geeft de bitsnelheid van het kanaal aan en de y-as de kwaliteit van de video ontvangen door de gebruiker. De bovenste RD-curve 1 geeft een bovengrens 1 Rate-Distortion-curve 81

97 Ontvangen kwaliteit Goed Gemiddeld Niet-schaalbare videocodering Gelaagde schaalbare videocodering Optimale RD-curve Gewenst objectief van FGS Slecht Laag Bitsnelheid van het kanaal Hoog Figuur 5.2: Prestatie van verschillende soorten videocodering aan voor de kwaliteit voor om het even welke coderingstechniek aan alle mogelijke bitsnelheden. Er worden drie curven afgebeeld die de kwaliteit aangeven die bereikt kan worden door een optimale niet-schaalbare codeertechniek te gebruiken, zoals bijvoorbeeld MPEG-1. Deze techniek probeert, gegeven een bepaalde bitsnelheid, de optimale kwaliteit te bereiken (optimaal punt benadert de RD-curve). Een probleem doet zich voor wanneer de capaciteit van het kanaal minder groot is dan de bitsnelheid waaraan de video werd gecodeerd. In dat geval gaan bepaalde stukken van de video verloren. Het verlies van beelden zal normaalgezien ook een invloed hebben op de decodering van de andere beelden omwille van het gebruik van intervoorspelling. Het resultaat is dat de kwaliteit van de ontvangen video zeer slecht is. Wanneer de capaciteit van het kanaal hoger is dan de bitsnelheid waaraan de video werd gecodeerd, dan kan de kwaliteit van de ontvangen video niet meer verbeteren omdat de hier veronderstelde codec de kwaliteit maar optimaliseert voor één bepaalde bitsnelheid. Schaalbare videocodering is interessant omdat verschillende lagen kunnen gedecodeerd worden, die elk een verschillende kwaliteit geven. In MPEG-2 en MPEG-4 worden verschillende technieken voor schaalbaarheid ondersteund, namelijk SNR- 82

98 schaalbaarheid, temporele schaalbaarheid en spatiale schaalbaarheid. Dit zijn schaalbare videocoderingstechnieken waarbij de videosequentie in twee lagen wordt gecodeerd namelijk, de basislaag en de verbeteringslaag. Enkel wanneer de bitstroom van de verbeteringslaag volledig wordt ontvangen, kan deze de kwaliteit van de video verbeteren. In figuur 5.2 zijn twee curves afgebeeld afkomstig van schaalbare videocoderingstechnieken. De curves hebben twee trappen. De eerste trap wordt bepaald door de bitsnelheid van de basislaag en de tweede trap door de bitsnelheid van de verbeteringslaag. In figuur 5.2 wordt ook een curve afgebeeld die het eerder genoemde gewenste objectief voorstelt. Deze curve loopt parallel met de optimale rate-distortion-curve. Dit is het objectief van Fine Granularity Scalability (FGS) uit MPEG-4 [31] Overzicht van de technieken voor schaalbare videocodering SNR-schaalbaarheid SNR-schaalbaarheid (Signal to Noise Ratio) codeert de video in twee lagen. Beide lagen hebben dezelfde beeldsnelheid en spatiale resolutie, maar een verschillende quantisatienauwkeurigheid. De verbeteringslaag bevat extra, meer nauwkeurige informatie van de gequantiseerde transformatiecoëfficiënten. Wanneer de verbeteringslaag wordt gedecodeerd, zal deze informatie opgeteld worden bij de coëfficiënten uit de basislaag en op die manier bekom je een betere kwaliteit. Temporele schaalbaarheid Bij temporele schaalbaarheid worden de twee lagen aan dezelfde spatiale resolutie gecodeerd, maar aan een verschillende beeldsnelheid. De basislaag wordt aan een lagere beeldsnelheid gecodeerd dan de verbeteringslaag. De verbeteringslaag bevat beelden die tussen de beelden van de basislaag kunnen gevoegd worden. Zo bekomt men video aan een hogere beeldsnelheid. Dit wordt geïllustreerd in figuur 5.3. De basislaag bevat enkel P-, en I-beelden. De verbeteringslaag kan P- en eventueel B-beelden bevatten. 83

99 P P P P Optimaliseringslaag 1' 2' 3' 4' P P P P P Basislaag Figuur 5.3: Structuur van een videosequentie bij temporele schaalbaarheid Spatiale schaalbaarheid Bij spatiale schaalbaarheid worden de twee lagen aan dezelfde beeldsnelheid, maar aan een verschillende spatiale resolutie gecodeerd. De basislaag wordt aan een lagere resolutie gecodeerd. De informatie uit de verbeteringslaag kan gebruikt worden om een beeld met een hogere resolutie te verkrijgen. FGS Temporele, spatiale en SNR-schaalbaarheid zijn technieken voor gelaagde schaalbare videocodering. FGS of fijnkorrelige schaalbaarheid, codeert de video ook in twee lagen, maar de bitstroom van de verbeteringslaag kan gedeeltelijk gedecodeerd worden in een willekeurig aantal bits binnen 2 elk beeld. Deze extra informatie zorgt voor een partiele verbetering van de beelden in de basislaag. Daarom geeft FGS de continue curve uit figuur 5.2. Hoe FGS precies werkt valt buiten het kader van deze scriptie. Voor meer informatie kan [31] geraadpleegd worden. 2 Het residu is een ingebedde (progressieve) bitstroom. De decodering kan op eender welk punt worden stopgezet. 84

100 5.2 Schaalbaarheid in de JVT/AVC-standaard FGS met JVT/AVC-codering in de basislaag Momenteel wordt MPEG-4 Advanced Simple Profile gebruikt voor de codering van de basislaag. De JVT/AVC-standaard ondersteunt momenteel nog geen fijnkorrelige schaalbaarheid. In onder meer [28] en [6] werd voorgesteld de JVT/AVC-standaard in de basislaag te gebruiken, omwille van de betere compressie-efficiëntie in vergelijking met MPEG-4 ASP. Het is echter niet efficiënt om FGS zonder aanpassingen te gebruiken in combinatie met de JVT/AVC-standaard. [28] Er zijn namelijk twee nadelen verbonden aan deze aanpak. Ten eerste zal een nieuwe functionele eenheid (rekenblok) moeten worden toegevoegd omdat FGS gebruikmaakt van de Discrete Cosinus Transformatie en de JVT/AVC-standaard van een geheelwaardige 4x4-transformatie (zie paragraaf 4.3). Dit verhoogt de complexiteit van zowel encoder als decoder. Ten tweede is het niet mogelijk om in de verbeteringslaag gebruik te maken van de nieuwe (efficiënte) onderdelen van de JVT/AVC-standaard die de complexiteit doen dalen en de foutbestendigheid verhogen. Het voorstel in [28] beschrijft onder andere twee wijzigingen die zouden moeten gebeuren wanneer FGS gecombineerd wordt met de JVT/AVC-standaard. De eerste wijziging bestaat erin het gebruik van UVLC als entropiecodering in de verbeteringslaag. Door deze aanpassing wordt dezelfde VLC-tabel in zowel de basislaag als de verbeteringslaag gebruikt. Dit doet de complexiteit dalen en zorgt voor een betere foutbestendigheid (zie paragraaf 4.4.1). Het gebruik van de UVLCentropiecodering zorgt wel voor een lichte daling van de compressie-efficiëntie in vergelijking met de aanwezige VLC-entropiecodering in FGS.[28] De tweede wijziging is de 4x4-geheelwaardige transformatie ook in de verbeteringslaag te gebruiken. De DCT-transformatie is niet aanwezig in de JVT/AVCstandaard en het toevoegen ervan zou de rekencomplexiteit verhogen. Bovendien heeft de 4x4-geheelwaardige transformatie de voordelen dat er geen mismatch optreedt door toepassing van de inverse transformatie en dat de implementatie zeer eenvoudig is (zie paragraaf 4.3). 85

101 5.2.2 Temporele schaalbaarheid in de JVT/AVC-standaard Wanneer de JVT/AVC-codec wordt gebruikt met temporele schaalbaarheid, kunnen alle B-beelden van een sequentie in de verbeteringslaag worden gestopt. In de basislaag worden dan enkel de I- en P-beelden overgehouden. Door het weglaten van de B-beelden vermindert de totale hoeveelheid gecodeerde data in de basislaag met als gevolg dat minder bandbreedte nodig is voor het versturen ervan. In grafiek 5.4 en grafiek 5.5 wordt voor de testsequentie stefan en foreman de daling in aantal kilobyte weergegeven wanneer alle B-beelden worden verwijderd. Om deze resultaten te bekomen, werd een testsequentie van 295 beelden gebruikt en een GOP-structuur gelijk aan IBBPBBP tegen een beeldsnelheid van 30 Hz. Bij bijvoorbeeld de testsequentie foreman is er een besparing tussen de 20% en 50% in aantal kb. De bandbreedte die vereist is om enkel de I- en P-beelden te versturen kan dus duidelijk een stuk lager zijn. Vermindering van aantal kb bij verwijderen van alle B-beelden (stefan) ,10% 52,35% ,25% 51,51% aantal kb ,46% 48,43% 46,85% Sequentie (I, P, B) Sequentie (I,P) ,92% 39,20% ,19% 21,24% 22,85% Bitsnelheid (kbps) Figuur 5.4: Vermindering van het aantal kb bij het weglaten van alle B-beelden (stefan) 86

102 Vermindering van aantal kb bij verwijderen van alle B-beelden (foreman) ,22% 52,93% ,34% 51,05% aantal kb ,80% 47,54% 45,48% Sequentie (I, P, B) Sequentie (I,P) ,01% 36,20% ,31% 31,57% 21,48% Bitsnelheid (kbps) Figuur 5.5: Vermindering van het aantal kb bij het weglaten van alle B-beelden (foreman) 5.3 Wisselbeelden Schaalbaarheid kan bij conversatiegerichte toepassingen, gekarakteriseerd door encodering in ware tijd en punt-naar-punt-verbindingen, bereikt worden door het dynamisch aanpassen van bepaalde parameters van het encoderingsproces, zoals de quantisatieparameter en de beeldsnelheid afhankelijk van gegeven netwerkfeedback. In typische toepassingen gericht op het stromen van data waarbij de videosequentie reeds geëncodeerd is, kan de voorgaande oplossing niet worden gebruikt. De eenvoudigste manier om schaalbaarheid te realiseren in het geval van vooraf gecodeerde videosequenties is het produceren van verschillende onafhankelijke bitstromen van dezelfde videosequentie maar aan een verschillende bitsnelheid en met een verschillende kwaliteit. Dit is de werkwijze die tegenwoordig zeer vaak wordt toegepast, maar het nadeel is dat de video meerdere malen moet gecodeerd en opgeslagen worden. De server kan dynamisch tussen de verschillende bitstromen wisselen afhankelijk van de bitsnelheid die de client kan ontvangen. Dit wordt simulstore genoemd. Het overschakelen tussen de bitstromen wordt bemoeilijkt door het groot aantal intergecodeerde beelden met bijbehorende afhankelijkheden. 87

103 Stel dat de decoder een stroom A aan het decoderen is en er op een gegeven moment moet worden overgeschakeld naar een bitstroom B (zie figuur 5.6). Voor de eenvoud wordt verondersteld dat elk beeld gecodeerd is in één enkele slice en dat er slechts één referentiebeeld wordt gebruikt bij intervoorspelling. Na het decoderen van de P-beelden A 0 en A 1, wil de decoder overschakelen op bitstroom B en verdergaan met de beelden B 2, B 3 enzoverder. Wanneer alle beelden in de B stroom als P-beelden gecodeerd werden, zal de decoder het beeld B 2 niet correct kunnen reconstrueren omdat het referentiebeeld B 1 niet aanwezig is in bitstroom A. Alle P-beelden doorsturen die voor B 2 in bitstroom B voorkomen, is ook geen optie. Bij het overschakelen naar een andere stroom ter hoogte van een P-beeld, zal het gereconstrueerd beeld vervormd zijn omdat het referentiebeeld niet correct is. Deze vervormingen in het beeld zullen bovendien nog verder gepropageerd worden en ook zichtbaar zijn in volgende beelden (tot aan het volgende I-beeld). P-beelden A 0 A 1 A 2 A 3 A 4 Stroom A Overschakelen naar stroom B B 0 B 1 B 2 B 3 B 4 Stroom B P-beelden Figuur 5.6: Moeilijkheden bij het overschakelen tussen 2 bitstromen 88

104 5.3.1 SP-beelden In huidige videostandaarden is het wisselen tussen bitstromen enkel mogelijk op plaatsen waar het beeld waarnaar wordt overgeschakeld onafhankelijk van eerder beelden kan worden gereconstrueerd, namelijk bij I-beelden. Deze punten worden wisselpunten genoemd. Deze werkwijze wordt geïllustreerd in figuur 5.7. Het overschakelen naar bitstroom B kan nu wel zonder problemen omdat beeld B 2 onafhankelijk van andere beelden kan gedecodeerd worden. Door op geregelde tijdstippen I-beelden toe te voegen aan de bitstroom kunnen ook videofunctionaliteiten zoals random access, fast forward,... bekomen worden. De gebruiker kan een deel van de video overslaan en de video herstarten op elke locatie waar een I-beeld aanwezig is. Deze aanpak is echter niet zo efficiënt omdat een I-beeld veel meer gecodeerde data bevat dan een P-beeld wat aanleiding geeft tot een piek in de bitsnelheid van de gecodeerde data bij elk wisselpunt. De nieuwe beeldtypes, SP- en SI-beelden, bieden hiervoor een oplossing. [13] P-beelden A 0 A 1 A 2 A 3 A 4 Stroom A wisselpunt B 0 B 1 B 2 B 3 B 4 Stroom B P-beelden I-beeld P-beelden Figuur 5.7: Overschakelen tussen 2 bitstromen met behulp van een I-beeld De werking van een SP-beeld wordt geïllustreerd in figuur 5.8. Veronderstel dat de twee bitstromen afkomstig zijn van het coderen van dezelfde videosequentie maar 89

105 aan verschillende bitsnelheden. In elke sequentie wordt ter hoogte van het tweede beeld een SP-beeld ingevoegd. Deze worden gecodeerd in intermodus, met andere woorden gebruikmakend van ME/MC. SP-beeld A 2 kan gedecodeerd worden gebruikmakend van referentie beeld A 1 ; SP-beeld B 2 kan gedecodeerd worden met B 1. Het SP-wisselbeeld AB 2 (tussen stroom A en B) maakt het efficiënt overschakelen tussen de twee stromen mogelijk. Dit beeld is zo geconstrueerd dat het kan gedecodeerd worden door middel van referentiebeeld A 1 om het gedecodeerde beeld B 2 te verkrijgen. Dit gedecodeerde beeld B 2 is nodig, omdat beeld B 3 op basis van dit beeld is voorspeld. Bij elke wisselpunt is er een extra SP-beeld nodig (om terug te schakelen van stroom B naar stroom A is er nog één extra nodig), maar dit is toch nog veel efficiënter dan het coderen van A 2 en B 2 als I-beelden. P-beelden SP-beelden P-beelden Stroom A A 0 A 1 A 2 A 3 A 4 AB 2 wisselbeeld reconstructie Stroom B B 0 B 1 B 2 B 3 B 4 Figuur 5.8: Overschakelen tussen 2 bitstromen met behulp van SP-beelden Een overzichtje van de volgorde van de beelden bij het overschakelen van bitstroom A naar bitstroom B wordt gegeven in tabel

106 Input van de decoder Referentie Output van de decoder P-beeld A 0 eerder beeld gedecodeerd beeld A 0 P-beeld A 1 gedecodeerd beeld A 0 gedecodeerd beeld A 1 SP-beeld AB 2 gedecodeerd beeld A 1 gedecodeerd beeld B 2 P-beeld B 3 gedecodeerd beeld B 2 gedecodeerd beeld B Tabel 5.1: Overschakelen van stroom A naar stroom B door middel van SP-beelden Random Access SP-beelden maken ook random access in een videostroom mogelijk. Dit wordt geïllustreerd in figuur 5.9. Op vaste intervallen in bitstroom A worden SP-beelden ingevoegd (bijvoorbeeld beeld SP 1 ). Per SP-beeld in bitstroom A zijn er twee beelden gegenereerd en opgeslagen in een andere bitstroom (bitstroom B). Het eerste extra beeld is een I-beeld op de temporele locatie juist voor het SP-beeld in bitstroom A. Het tweede beeld ter hoogte van het SP-beeld in bitstroom A is een SP-wisselbeeld (SP 2 ). De bitstroom A kan worden gestart ter hoogte van elk I-beeld in bitstroom B. Bijvoorbeeld om bitsroom A te beginnen bij beeld I 2, worden eerst I 2 en SP 2 uit bitstroom B verstuurd en vervolgens de volgende P-beelden uit bitstroom A. Fast forward Het invoegen van SP-beelden in de bitstroom maakt ook fast forward en fast backward mogelijk. In figuur 5.10 wordt getoond hoe dit wordt gerealiseerd. Bitstroom B bestaat enkel uit SP-beelden voorspeld op basis van eerdere SP-beelden maar op grotere temporele intervallen (bijvoorbeeld om de seconde). Via het SP-wisselbeeld SP 21 gebeurt de overschakeling van stroom B naar stroom A. De wisselbeelden worden in stroom B verstuurd. Na de decodering van SP 21 wordt het beeld SP 1 getoond. Alle SP-beelden in stroom B worden op basis van elkaar voorspeld Codering en decodering van SP-beelden De uitleg in volgende paragraaf is op basis van figuur Het encoderingsproces voor een SP-beeld B 2 wordt getoond in figuur Eerst wordt een voorspelling 3 De uitleg die hier wordt gegeven is een vereenvoudigde versie van het coderings- en decoderingsproces. 91

107 P-beelden SP-beeld P-beelden Stroom A P P SP 1 P P reconstructie Stroom B I 2 SP 21 I-beeld SP-beeld Figuur 5.9: Random access met behulp van SP-beelden P SP 1 P P SP 1 P Stroom A SP 21 SP 21 Stroom B SP 2 SP 2 Figuur 5.10: Fast forward met behulp van SP-beelden 92

108 van B 2 opgesteld op basis van B 1, het gedecodeerde beeld B 1, door toepassing van MC. Deze voorspelling wordt afgetrokken van beeld B 2 en daarvan wordt het residu gecodeerd. Anders dan bij een gewoon P-beeld, gebeurt deze aftrekking in het transformatiedomein, dus na de bloktransformatie. origineel beeld B 2 T + Q VLE SP B 2 - B 1 ' (gedecodeerde versie van B 1 ) MC T Figuur 5.11: Encoderen van een SP-beeld Het decoderen van SP-beeld B 2 door een decoder die juist beeld B 1 heeft gedecodeerd, wordt getoond in figuur SP B 2 VLD Q T -1 SP B 2 ' (gedecodeerde versie) B 1 ' (gedecodeerde versie van B 1 ) MC T Figuur 5.12: Decoderen van een SP-beeld Het encoderen van het SP-wisselbeeld AB 2 wordt getoond in figuur 5.13 en het decoderen in figuur Een voorspelling wordt opgesteld door het uitvoeren van ME op basis van beeld A 1. Deze voorspelling wordt getransformeerd en gequantiseerd vóór de aftrekking van het beeld B 2 (ook getransformeerd en gequantiseerd) gebeurt. Het resultaat is het wisselbeeld AB 2. Het is de bedoeling dat na het decoderen van beeld AB 2 het gereconstrueerde beeld gelijk is aan het gereconstrueerde beeld bekomen na het decoderen van beeld B 2 (zie figuur 5.12). De reconstructie is in beide gevallen gelijk aan B 2. Dit beeld kan dan als referentiebeeld gebruikt worden voor volgende beelden in bitstroom B. 93

109 origineel beeld B 2 T Q + VLE SP AB 2 - A 1 ' (gereconstrueerde versie van A 1 ) ME T Q Figuur 5.13: Encoderen van SP-wisselbeeld SP AB 2 VLD + + Q -1 T -1 gereconstrueerd beeld B 2 ' A 1 ' (gereconstrueerde versie van A 1 ) ME T Q Figuur 5.14: Decoderen van een SP-wisselbeeld SI-beelden Een tweede type van wisselbeeld is het SI-beeld. Dit beeld wordt op een gelijkaardige manier gebruikt als een SP-wisselbeeld, behalve dat de voorspelling gebeurt met behulp van 4x4-intravoorspelling van eerder gedecodeerde samples van het gereconstrueerde beeld. Een SI-beeld kan bijvoorbeeld gebruikt worden om over te schakelen tussen twee totaal verschillende videosequenties (vb. videosequenties afkomstig van een verschillende camerahoek of videosequenties afkomstig van beveiligingscamera s rond een gebouw). Dit wordt ook wel splicing genoemd. Intervoorspelling van beelden van een bepaalde sequentie op basis van referentiebeelden van een andere (verschillende) sequentie is niet zeer efficiënt. Overschakelen door op regelmatige plaatsen I-beelden in de bitstroom toe te voegen zou in dit geval efficiënter zijn, maar het toevoegen van veel I-beelden doet de bitsnelheid stijgen. Efficiënt overschakelen tussen twee bitstromen van verschillende sequenties kan wel met behulp van SI-beelden. Dit wordt geïllustreerd in figuur In bitstroom A en B zijn er op vaste intervallen SP-beelden ingevoegd. Bijkomend is er bij een wisselpunt een SI-wisselbeeld om het overschakelen tussen de twee stromen mogelijk te maken. Op het moment dat beslist wordt om over te schakelen naar stroom B wordt in plaats van beeld A 2 het SI-wisselbeeld AB 2 doorgestuurd. 94

110 Dit beeld wordt gereconstrueerd in het SP-beeld B 2. P slices SP slice P slices Stroom A A 0 A 1 A 2 A 3 A 4 Switch punt SI slice AB 2 Stroom B B 0 B 1 B 2 B 3 B 4 SP slice Figuur 5.15: Splicing met behulp van SP- en SI-beelden Foutbestendigheid Het gebruik van SP-beelden is voordelig omdat het de foutbestendigheid verhoogt en eventueel herstel bij het verlies van bijvoorbeeld een slice, mogelijk maakt. De foutbestendigheid kan worden verhoogd door meerdere representaties van één beeld in de vorm van SP-beelden te construeren. Verschillende referentiebeelden kunnen gebruikt worden voor deze SP-beelden. Als referentiebeeld kan bijvoorbeeld het juist voorafgaande beeld en een beeld dat veel eerder werd gecodeerd (eventueel het voorgaande I-beeld), gebruikt worden. Stel bijvoorbeeld dat een op voorhand gecodeerde sequentie wordt gestroomd en er treedt pakketverlies op, waardoor slices of volledige beelden verloren gaan. 95

111 De client laat aan de server weten welke beelden verloren zijn en de server reageert hierop door het volgende SP-beeld in de representatie te versturen dat gebruikmaakt van een referentiebeeld dat reeds door de client werd ontvangen. Dit referentiebeeld moet wel nog in de buffer van de decoder in de client zitten. In figuur 5.16 wordt dit principe getoond. SP-beeld P-beelden SP-beeld P-beelden SP 1 P P SP 2 P P reconstructie SP-wisselbeeld SP 12 SI-wisselbeeld SI 2 Figuur 5.16: Foutbestendigheid door gebruik van SP-beelden 96

112 Hoofdstuk 6 De netwerkabstractielaag 6.1 Inleiding Figuur 6.1 toont nog eens de scheiding tussen de twee conceptuele lagen, namelijk de videocoderingslaag (VCL) en de netwerkabstractielaag (NAL). De JVT/AVCstandaard voorziet een afbeelding (interface) naar de verschillende mogelijke transportsystemen. De exacte wijze waarop de JVT/AVC-data worden opgenomen in pakketten en de manier waarop de pakketten worden getransporteerd zijn specifiek voor de verschillende transportsystemen zoals H.320 en MPEG-2. Het zijn daarom geen onderdelen van de JVT/AVC-standaard. 6.2 Concept van de netwerkabstractielaag De netwerkabstractielaag definieert een generieke en netwerkonafhankelijke representatie voor de data uit de VCL-laag en de controledata. De basiseenheid in de NAL is de NAL-eenheid. Deze NAL-eenheden zijn geschikt voor transmissie over pakketgebaseerde netwerken. De NAL-decoder veronderstelt dat de NAL-eenheden in transmissievolgorde worden geleverd. Een NAL-eenheid kan ofwel correct ontvangen worden, verloren gaan of fouten bevatten. Dit laatste wordt aangegeven door een foutvlag in de NAL-eenheidheader. Een NAL-eenheid bestaat uit twee delen: de NAL-eenheidheader van één byte en een bitstring. Deze bitstring bevat over het algemeen bits die de macroblokken 97

113 JVT/AVC-standaard VCL-encoder VCL-decoder NAL-encoder NAL-decoder H.263 MPEG-2 RTP Transportlaag Figuur 6.1: JVT/AVC-standaard en de transportlaag uit een bepaalde slice representeren. De headerbyte bestaat uit drie delen: 1. forbidden zero bit (foutvlag): moet gelijk zijn aan nul. Kan bij detectie van fouten op één gezet worden. 2. nal ref idc: deze vlag wordt gebruikt om aan te geven of de NAL-eenheid in de referentiebuffer moet komen. Indien dit niet het geval is (nal ref idc = 0) kan beslist worden de NAL-eenheid weg te gooien zonder gevaar voor foutpropagatie. 3. nal unit type: geeft een indicatie van het type van de data in de NALeenheid. Dit kunnen gegevens zijn uit de VCL-laag of data van een hoger niveau zoals bijvoorbeeld Supplemental Enhancement Information (zie paragraaf 6.2.4). Voor elk syntaxelement (uit de VCL-laag of controledata) wordt in de JVT/AVCstandaard een categorie gespecificeerd. De verschillende mogelijke NAL-eenheden kunnen syntaxelementen van één of meerdere categorieën bevatten. Een overzicht van de verschillende NAL-eenheidtypes met de categorie van syntaxelementen die ze kunnen bevatten, wordt gegeven in tabel 6.1 [12]. De types 1, 2, 3, 4, 5 en 12 zijn VCL-NAL-eenheden, de andere types worden non-vcl-nal-eenheden genoemd. 98

114 NAL-eenheidtype Inhoud van de NAL-eenheid Categorie 0 Niet gespecificeerd - 1 Gecodeerde slice 2,3,4 2 Gecodeerde slice datapartitie A 2 3 Gecodeerde slice datapartitie B 3 4 Gecodeerde slice datapartitie C 4 5 Gecodeerde slice van een IDR-beeld 2,3 6 Supplemental Enhancement Information (SEI) 5 7 Sequence Parameter Set (SPS) 0 8 Picture Parameter Set (SPS) 1 9 Beeldbegrenzer (Picture delimiter) 6 10 Einde van de sequentie (End of Sequence) 7 11 Einde van de stroom (End of Stream) 8 12 Opvuldata (Filler data) Gereserveerd Niet gespecificeerd - Tabel 6.1: NAL-eenheidtypes In volgende paragrafen wordt dieper ingegaan op de verschillende NAL-eenheidtypes Gecodeerde slice (NAL-eenheidtype 1) Alle VCL-data van één slice wordt in een NAL-eenheid van het type 1 gestopt. Er wordt dus geen onderscheid gemaakt tussen de verschillende categorieën van de slicedata Datapartitionering (NAL-eenheidtypes 2,3 en 4) Bij datapartitionering worden de syntaxelementen op basis van hun categorie in verschillende NAL-eenheden gestoken. Er zijn maximaal drie datapartities namelijk, datapartitie A, B en C. Datapartitie A bevat alle syntaxelementen van de sliceheader en de slicedata verschillend van de residudata. Datapartitie B bevat de residudata voor macrobloktypes I en SI en datapartitie C bevat de residudata voor macrobloktypes P en B. Over het algemeen kan gezegd worden dat de belangrijkste gegevens in datapartitie A zitten en de minst belangrijke in datapartitie C. Datapartitionering is efficiënt in systemen waar het mogelijk is bepaalde slices 99

115 op een meer betrouwbare manier te versturen dan andere. foutbestendigheid verkregen.[33] Zo wordt een betere Parameter sets Een groot probleem bij transmissie van video over systemen waar pakketverlies mogelijk is, heeft te maken met de gelaagde constructie van de informatie in huidige standaarden. Informatie in de slice-, beeld-, GOP-, of sequentieheaders is nodig voor de reconstructie van het volledige slice, beeld, GOP, of sequentie. Als een pakket met headerinformatie wordt verloren, zorgt dit voor problemen bij het decoderen van alle pakketten die op deze headerinformatie steunen. [26] [25] Er zijn drie mogelijke oplossingen voor dit probleem: 1. Het verlies van een pakket wordt genegeerd: alle data afhankelijk van het verloren pakket kunnen verkeerd geïnterpreteerd worden. 2. Als de ontvanger het verlies kan detecteren, kan de decoder proberen de fouten die werden veroorzaakt door de afwezigheid van de headerinformatie te verbergen. Hierbij kan gebruikgemaakt worden van informatie uit eerdere headers. Problemen doen zich natuurlijk voor wanneer de verloren headerinformatie sterk verschilt van de vorige headerinformatie. 3. Als de zender kan detecteren dat headerinformatie ontbreekt, kunnen extra pakketten verstuurd worden om dit te compenseren. Het nadeel van deze techniek is dat de bitsnelheid verhoogd. Een groot nadeel van al deze oplossingen is dat het onvoorspelbaar is te weten of de headerinformatie in de decoder toegankelijk is of niet. Het is niet mogelijk de headerinformatie in elk pakket te herhalen, want dit zou resulteren in een stijging van de bitsnelheid. In de JVT/AVC-standaard werd daarom voor een nieuwe oplossing gekozen. Alle verstuurde pakketten zijn volledig autonoom, met andere woorden, de reconstructie kan onafhankelijk van informatie uit andere pakketten worden uitgevoerd. Het slice is de kleinst mogelijke autonome eenheid (tenzij datapartitionering wordt gebruikt). 100

116 De grootte van de slices kan aangepast worden aan de MTU (Maximum Transfer Unit) 1 van de meeste systemen. Alle parameters die frequent veranderen, worden opgenomen in de sliceheader. Alle andere parameters die algemeen gelden voor verschillende slices worden opgenomen in parameter sets. In de sliceheader wordt gespecificeerd welke parameter set moet worden gebruikt bij het decoderen. Er zijn twee mogelijke parameter sets namelijk, de Sequence Parameter Set (SPS) en de Picture Parameter Set (PPS). SPS Een SPS bevat syntaxelementen waarnaar kan gerefereerd worden door verschillende PPS s. Het bevat parameters die globaal zijn voor een volledige sequentie 2. De actieve SPS is deze die wordt toegepast tussen twee IDR-beelden. De SPS komt in de bitstroom vóór alle NAL-eenheden die ernaar verwijzen (duplicaten kunnen wel voorkomen tussen andere NAL-eenheden). Deze set bevat onder andere een identificatienummer van de SPS, het gebruikte profiel en level, het aantal mogelijke referentiebeelden, de aanwezigheid van redundante beelden,... PPS Een PPS bevat syntaxelementen waarnaar kan gerefereerd worden door NAL-eenheden van het type 1 tot en met 6. De PPS is minstens voor een volledig beeld geldig, maar kan ook door meerdere beelden worden gebruikt. De actieve PPS is geldig voor alle slices van een bepaald beeld. De PPS komt in de bitstroom vóór alle NAL-eenheden die ernaar kunnen refereren (eventueel kunnen duplicaten voorkomen tussen andere NAL-eenheden). De PPS bevat onder andere een identificatienummer van de PPS, de entropiecoderingsmodus, het aantal slicegroepen, initiële waarden voor de quantisatieparameters, parameters voor de antiblokfilter,... Het grote voordeel van het gebruik van parameter sets is dat deze afzonderlijk kunnen worden verstuurd over een betrouwbare connectie. De SPS kan bijvoorbeeld op een betrouwbare manier verstuurd worden bij het opstarten van de sessie of eventueel over een ander, betrouwbaar kanaal. 1 De MTU is het grootste pakket dat over een bepaald netwerk kan worden verzonden. 2 Met een sequentie wordt in de standaard alle beelden tussen twee IDR-beelden bedoeld 101

117 6.2.4 Supplemental Enhancement Information (NAL-eenheidtype 6) Het concept van SEI-eenheden is afkomstig uit de H.263-standaard (Annex L en annex W). De syntax en semantiek is te vinden in Annex D van de JVT/AVCstandaard [12]. Een SEI-eenheden bevat informatie die niet nodig is voor het decoderen van VCL-NAL-eenheden, maar wel praktisch bruikbaar is tijdens het decoderen of voor presentatiedoeleinden. Een SEI-eenheden wordt geassocieerd met de volgende slice of datapartitionering in decodeervolgorde. De decoder beslist of de informatie wordt gedecodeerd of niet. Voorbeelden 1. Bevriezen van een beeld: een SEI-eenheden (Full-frame freeze SEI ) kan opgeven dat een bepaald beeld moet worden bevroren tot een ander SEI-eenheid (Full-frame release SEI ) wordt tegengekomen en het beeld niet langer wordt getoond. 2. Gebruikersdata zoals bijvoorbeeld copyright-informatie. 3. Informatie over de verschillende scènes in een sequentie en de overgang tussen scènes: op deze manier is de identificatie van verschillende scènes mogelijk en kan er bijvoorbeeld opgegeven worden dat er dient overgeschakeld te worden door middel van een dissolve-effect Andere NAL-eenheden Beeldbegrenzer (NAL-eenheidtype 9) Beeldbegrenzers moeten niet opgenomen worden in de bitstroom, maar vergemakkelijken wel het bepalen van de grens tussen twee beelden. Indien geen beeldbegrenzer aanwezig is, kan gekeken worden naar frame num uit de sliceheader om beeldgrenzen te bepalen. Alle slices met hetzelfde frame num behoren tot hetzelfde beeld. 3 Dissolve-effect = overvloeiing tussen scènes. De ene scène vervaagt, terwijl de andere langzaam zichtbaar wordt. Enkele beelden bevatten dus informatie van beide scènes. 102

118 Einde van de sequentie (NAL-eenheidtype 10) Deze NAL-eenheid vergemakkelijkt de detectie van het einde van een sequentie. Nadien kunnen eventueel nog andere sequenties volgen (beginnend met een IDRbeeld). Einde van de stroom (NAL-eenheidtype 11) Deze NAL-eenheid geeft aan dat de volledige videostroom teneinde is. Er komen geen andere NAL-eenheden meer achter. Opvuldata (NAL-eenheidtype 12) Dit is een NAL-eenheid met data zonder betekenis dat op een willekeurige plaats tussen andere NAL-eenheden kan gevoegd worden. 6.3 Bytestroomformaat Naast het NAL-eenheidformaat geschikt voor pakketgebaseerde transmissie, wordt in de JVT/AVC-standaard ook een bytestroomformaat gedefinieerd. Het bytestroomformaat is gelijk aan het NAL-eenheid-stroomformaat in decodeervolgorde waarbij elke NAL-aanheid wordt voorafgegaan door een startcode-prefix (en 0 of meerdere nulbytes). Het startcode-prefix is een unieke sequentie van drie bytes gelijk aan 0x De locatie van het startcode-prefix kan door de decoder gebruikt worden om het begin van een nieuwe NAL-eenheid en het einde van de vorige NAL-eenheid te identificeren. Er wordt verzekerd dat binnen de NAL-eenheid zelf geen sequentie van byte-gealigneerde bytes voorkomen die het startcode-prefix bevatten door het toevoegen van emulation prevention bytes 5 waar nodig. 4 Hexadecimale notatie. 5 Een emulation prevention byte is gelijk aan 0x

119 Hoofdstuk 7 Praktisch deel In dit hoofdstuk wordt eerst een bespreking gegeven van een tracebestand dat werd bekomen bij het encoderen van een videosequentie met de referentiesoftware van de JVT/AVC-standaard. Vervolgens wordt een overzicht gegeven van enkele experimenten die werden uitgevoerd met de referentiesoftware. 7.1 Bespreking van een tracebestand In tabel 7.1 zijn de gegevens te vinden die werden gebruikt voor het genereren van het tracebestand uit appendix C. In deze appendix zit niet het volledige tracebestand omdat dit veel te groot is. Het kan wel teruggevonden worden op de bijgevoegde CD-ROM. De verdere bespreking bevat veel verwijzingen naar de standaard [12]. Om alles goed te begrijpen, wordt dus best dit document ter zijde genomen. De lijnen van het deel van het tracebestand uit appendix C zijn genummerd. In de volgende paragrafen zal regelmatig naar een lijn uit het tracebestand verwezen worden aan de hand van het lijnnummer. Tabel 7.2 verduidelijkt de opbouw van een lijn uit het tracebestand. De manier waarop de entropiecodering van syntaxelementen gebeurt, is te vinden in de standaard [12] paragraaf

120 versie referentiesoftware AHM 2.0 (JM Rate Control) testsequentie foreman formaat QCIF aantal beelden 5 GOP-structuur IBPBP entropiecoderingsmodus UVLC/CAVLC bitsnelheid 100 kbps gebruik rate control ja aantal slices per beeld 1 aantal partities 1 Tabel 7.1: Gegevens voor het genereren van het tracebestand uit appendix C lijnnummer teller (aantal bits) syntaxelement codewoord decimale waarde SPS: profile idc ( 0) NAL-eenheden Tabel 7.2: Lijn 1 uit het tracebestand In het totaal bevat de gegenereerde bitstroom bij het coderen van vijf beelden zeven NAL-eenheden. In het tracebestand wordt eerst de data uit de NAL-eenheid gegeven, gevolgd door de beschrijving van het NAL-eenheidtype. De NAL-eenheden zijn: 1. Sequentie Parameter Set (SPS) 2. Picture Parameter Set (PPS) 3. Gecodeerde slice van een IDR-beeld (beeld 0) 4. Gecodeerde slice van het eerste P-beeld (beeld 2) 5. Gecodeerde slice van het eerste B-beeld (beeld 1) 6. Gecodeerde slice van het tweede P-beeld (beeld 4) 7. Gecodeerde slice van het tweede B-beeld (beeld 3) Merk op dat de P-beelden gecodeerd worden vóór de B-beelden die ernaar refereren. Het tracebestand geeft de gegevens van de beelden in codeervolgorde. Hierna volgt de bespreking van de SPS, PPS, beeld 0, beeld 2 en beeld

121 7.1.2 SPS Lijn 17 geeft de parameters (zonder de NAL-eenheiddata) van deze NAL-eenheid. De belangrijkste zijn: De grootte van de NAL-eenheid: len = 8 1. De parameter nal reference idc met waarde 3. Wanneer deze parameter een waarde heeft die verschillend is van nul, wijst dit op een NAL-eenheid dat gelijk is aan een SPS, PPS of een slice (of partitie) uit een beeld dat als referentiebeeld kan gebruikt worden 2. De parameter nal unit type met waarde 7. In tabel 7.1 van de standaard [12] wordt gespecificeerd wat de betekenis is van deze waarde. Een waarde 7 wijst op een sequentie parameter set. Lijn 1 tot en met lijn 17 geven de data van de NAL-eenheid namelijk, de parameters die de SPS bevat. Al deze parameters zijn geldig voor een volledige GOP (dus tot aan het volgende IDR-beeld). De betekenis van al deze parameters kan teruggevonden worden in de standaard [12] De belangrijkste zijn: seq parameter set id geeft het nummer van de SPS (hier gelijk aan nul). De entropiecodering die hier werd gebruikt is de unsigned exponential golombcodering (zie paragraaf 4.4.1). Eerst wordt het syntaxelement gebinairiseerd tot code num = 0. Het codewoord voor code num = 0 door toepassing van golomb-codering is gelijk aan 1. num ref frames = 1: er mag slechts één referentiebeeld gebruikt worden bij intervoorspelling. Ook dit syntaxelement wordt gecodeerd door middel van unsigned exponential golomb-codering. Na binairisatie krijgen we code num = 1. Het codewoord door toepassing van golomb-codering is gelijk aan De grootte van de NAL-eenheid wordt niet expliciet in de bitstroom gecodeerd, maar moet worden berekend. 2 De standaard specificeert niet de precieze betekenis van de waarde van de parameter nal reference idc indien deze verschillend is van nul. 106

122 7.1.3 PPS Op lijn 34 staan de parameters van de tweede NAL-eenheid. Hier is nal unit type gelijk aan 8, wat wijst op een PPS. Lijn 18 tot en met lijn 33 geven de parameters uit de PPS. De betekenis van alle opgegeven parameters kan gevonden worden in de standaard [12] De belangrijkste parameters zijn: pic parameter set id = 0: de PPS krijgt het identificatienummer 1. De beelden die deze PPS gebruiken verwijzen ernaar door middel van dit nummer. De PPS is geldig voor één of meerdere beelden in een sequentie. Voor deze sequentie is de PPS geldig voor alle volgende beelden. seq parameter set id = 0: verwijzing naar de actieve SPS (lijn 19). pic init qp minus26 = 0: dit is de quantisatieparameter die wordt gebruikt voor alle macroblokken indien ze in de sliceheader of voor een macroblok zelf niet gewijzigd wordt. De standaardquantisatieparameter is hier dus gelijk aan = Gecodeerde slice van het IDR-beeld (lijn ) In I-slices kunnen macroblokken op twee manieren gecodeerd zijn: in intra-4x4- modus of in intra-16x16-modus (zie paragraaf 4.1). De volgorde bij het versturen van de macroblokdata wordt gegeven in figuur 7.1. Hierna volgt eerst wat uitleg over de sliceheader en vervolgens de bespreking van een macroblok gecodeerd in intra-4x4-modus en een macroblok gecodeerd in intra-16x16-modus. Sliceheader (lijn 35-44) De betekenis van alle parameters uit de sliceheader kan gevonden worden in de standaard [12] paragraaf De belangrijkste zijn: slice type = 7: dit geeft aan dat het over een I-slice gaat. 107

123 Figuur 7.1: Volgorde transformatie pic parameter set id = 0: verwijzing naar de actieve PPS. frame num = 0: nummer dat wordt toegewezen aan beelden die als referentiebeeld kunnen worden gebruikt. idr pic id = 1: speciaal nummer dat een IDR-beeld identificeert 3. slice qp delta = 4: parameter die aangeeft dat voor dit slice de QP die werd opgegeven in de PPS wordt gewijzigd naar QP = = 30. Macroblok 0: gecodeerd in intra-4x4-modus (lijn ) Het eerste syntaxelement dat voor een macroblok wordt verstuurd is de macroblokmodus (lijn 46). In tabel 7.8 uit de standaard [12] kunnen de verschillende macroblokmodi gevonden worden. Voor macroblok 0 is de macroblokmodus gelijk aan 0. Dit wil zeggen dat het macroblok in intra-4x4-modus werd gecodeerd waarbij niet gebruikgemaakt wordt van samples van reeds gecodeerde blokken. Dit is logisch aangezien dit het eerste macroblok is en nog geen andere blokken werden gecodeerd. Wanneer de macroblokmodus gelijk is aan nul, wordt blok -1 (zie figuur 7.1) niet 3 Telkens wanneer een IDR-beeld in de bitstroom wordt toegevoegd, begint de parameter frame num opnieuw vanaf nul. Wanneer twee IDR-beelden na elkaar voorkomen hebben ze dus beide frame num gelijk aan nul. Daarom hebben IDR-beelden ook een afzonderlijk identificatienummer. 108

124 verstuurd. Dit is het blok met de DC-coëfficiënten afkomstig van de 4x4-blokken van de luminantiecomponent 4. Lijn specificeren enkele parameters voor het macroblok: De voorspellingsmodus voor elk 4x4-blok van de luminantiecomponent (lijn 47-62). De voorspellingsmodus van de chrominantiecomponenten (lijn 63). Het coded block pattern 5 (lijn 64). Hier is coded block patterngelijk aan 47. Om te berekenen welke 4x4-blokken van de luminantiecomponent nietnulcoëfficiënten bevatten, wordt 47%16 = 15 uitgerekend. Dit getal is in binaire notatie gelijk aan Dit wil zeggen dat alle vier de 4x4-blokken nietnulcoëfficiënten bevatten (vier eentjes). Voor de chrominantiecomponenten wordt 47/16 = 2 (naar beneden afgerond) berekend. De betekenis hiervan is dat nul of meer DC-coëfficiënten verschillend van nul zijn en ook nul of meer AC-coëfficiënten verschillend van nul zijn (zie [12] 7.4.5, tabel 7-12). Delta QP (lijn 65): kan de QP voor de luminantiecomponent (opgegeven in de sliceheader) wijzigen. Hier is Delta QP gelijk aan nul, dus de QP blijft gelijk aan 30. De gecodeerde coëfficiënten van het macroblok in de volgorde zoals aangegeven in figuur 7.1 worden beschreven van lijn 66 tot en met lijn 248. Het eerste 4x4-blok van de luminantiecomponent (blok 0), wordt afgebeeld in figuur 7.2. De codewoorden voor dit blok zijn terug te vinden op lijn 66 tot en met lijn 78. De toepassing van CAVLC op dit blok gaat als volgt: 4 De correlatie tussen de DC-coëfficiënten van de 4x4-blokken afkomstig uit een macroblok, gecodeerd in intra-16x16-modus, is vrij groot omdat blokken voorspeld in intra-16x16-modus normaalgezien vrij egaal zijn. Dit wil zeggen dat de samplewaarden geen echt grote verschillen zullen vertonen binnen het macroblok. Als dit wel zo is (het blok bevat vrij veel detail), dan zal er waarschijnlijk voor intra-4x4-modus worden gekozen. In dit laatste geval zal de correlatie tussen de DC-coëfficiënten waarschijnlijk minder groot zijn en is het dus niet zo voordelig om ze in een afzonderlijk blok te coderen. 5 geeft aan welk van de zes 8x8-blokken niet-nulcoëfficiënten bevatten. Er zijn vier 8x8-blokken in de luminantiecomponent en één 8x8-blok per chrominantiecomponent. 109

125 Figuur 7.2: Blok 0 van macroblok 0 van het IDR-beeld Het blok wordt omgezet in een sequentiële rij coëfficiënten door toepassing van zigzag-scan (alle coëfficiënten in de figuur zijn genummerd volgens zigzagscan). Volgende rij coëfficiënten wordt verkregen: Op deze rij wordt vervolgens (run,level)-codering toegepast met als resultaat de volgende (run,level)-paren: (0,7), (0,-9), (0,2), (0,2), (0,-2), (0,-8), (0,-4), (0,1), (0,-1), (2,-1), (1,1) Daarna volgt de entropiecodering van de (run,level)-paren 6 : 1. Codering van het aantal niet-nulcoëfficiënten en T1 s. total coeff= 11 (lijn 66: #c=11). Dit zijn dus alle niet-nulcoëfficiënten van het blok uit figuur 7.2. T1 s = 3 (lijn 66: #t1=3) 7. De T1 s staan in de figuur in een grijs vierkantje. Deze twee parameters worden in één codewoord, coeff token omgezet 8. 6 Voor de verduidelijking van de betekenis van de verschillende syntaxelementen kan paragraaf geraadpleegd worden. 7 Eigenlijk zijn het er vier, maar T1 is maximaal 3. 8 Dus total coeffen T1 s zijn niet in de bitstroom gecodeerd. 110

126 De VLC-tabel die wordt gekozen is tabel 0 (vlc=0) en is te vinden in [12], tabel 9.5, Het codewoord voor coeff token is gelijk aan Codering van het teken van elke T1. Het teken van elke T1 wordt met 1 bit gecodeerd (0 = positief en 1 = negatief). De T1 s worden in omgekeerde volgorde overlopen, dus beginnend bij de laagste T1. Er zijn drie T1 s dus hebben we drie tekenbits namelijk, 011 (lijn 67). 3. Codering van de levels van de resterende niet-nulcoëfficiënten. Voor de acht resterende niet-nulcoëfficiënten (total coeff - T1 s) moeten de levels gecodeerd worden. Deze worden ook in omgekeerde volgorde gecodeerd (lijn 68-75). 4. Codering van het aantal nullen voor de laatste niet-nulcoëfficiënt. TotalZeros = 3 (lijn 76). Deze staan in figuur 7.2 in een zwart vierkantje. 5. Codering van elke run nullen. Het coderen van de runs (run before) gebeurt ook in omgekeerde volgorde. run beforebevat het aantal nullen vóór een niet-nulcoëfficiënt. Er wordt begonnen bij de laatste T1 (nummer 13). Vóór deze coëfficiënt is er een run bestaande uit één nul (coëfficiënt met nummer 12). De volgende run die moet gecodeerd worden is deze vóór de voorlaatste T1 (coëfficiënt met nummer 11). Deze run bestaat uit twee nullen (coëfficiënten 10 en 9). Op dit moment is het totaal aantal nullen van de twee runs gelijk aan TotalZeros, wat wil zeggen dat er geen nullen meer voorkomen in het blok. Het volgende blok van de luminantiecomponent (blok 1) wordt afgebeeld in figuur 7.3. Lijn 79 tot en met lijn 92 geven de codewoorden voor dit blok die op dezelfde manier moeten geïnterpreteerd worden als voor blok 0. Na alle blokken van de luminantiecomponent volgen de twee 2x2-blokken met DC-coëfficiënten van de chrominantiecomponenten (lijn ). Deze worden afgebeeld in figuur 7.4. Als laatste volgen de acht 4x4-blokken met AC-coëfficiënten van de chrominantiecomponenten (lijn ). 111

127 Figuur 7.3: Blok 1 van macroblok 0 van het IDR-beeld Figuur 7.4: Twee blokken met de DC-coëfficiënten van de chrominantiecomponenten Macroblok 28: gecodeerd in intra-16x16-modus (lijn ) De macroblokmodus is gelijk aan 22 (lijn 249), dit komt overeen met de intra-16x16- modus waarbij de intravoorspellingsmodus gelijk is aan 1, of met andere woorden horizontale voorspelling (zie tabel 7.8 in [12]). Door toepassing van de unsigned exponential golomb-codering wordt voor de macroblokmodus het codewoord verkregen. Voor een macroblok gecodeerd in intra-16x16-modus wordt ook een 4x4-blok met de DC-coëfficiënten van de 4x4-blokken van de luminantiecomponent verstuurd (zie figuur 7.1). De macroblokinformatie die wordt verstuurd, is dus: 112

128 data van het 4x4-DC-blok van de luminantiecomponent (lijn ) data van de 16 4x4-blokken met AC-coëfficiënten 9 van de luminantiecomponent (lijn ) data van de twee 2x2-DC-blokken van de chrominantiecomponenten (lijn ) data van de acht 4x4-blokken met AC-coëfficiënten van de chrominantiecomponenten (lijn ) Gecodeerde slice van het eerste P-beeld De gegevens van het eerste P-beeld (beeld 2) beginnen op lijn 323 en eindigen op lijn 349. Lijn 349 bevat de beschrijving van de NAL-eenheid. Het nal unit type heeft waarde de 1 wat overeenkomt met een gecodeerde slice. Omdat nal reference idc verschillend is van nul, kan dit beeld als referentiebeeld worden gebruikt. Sliceheader (lijn ) slice type = 5: dit geeft aan dat het over een P-slice gaat. frame num = 1: nummer dat wordt toegewezen aan beelden die als referentiebeeld kunnen worden gebruikt. slice qp delta = 6: wijziging van de QP die werd opgegeven in de PPS naar QP = = 32. Macroblokdata (lijn ) Bij intervoorspelling wordt een macroblok gepartitioneerd in kleinere blokken (zie figuur 4.11) Voor elk blok wordt een voorspelling opgesteld. Het residu dat bekomen wordt na aftrekking van de voorspelling van het originele blok, wordt vervolgens entropiegecodeerd. 9 Er is dus bij de codering in intra-16x16-modus ook een opdeling in 4x4-blokken omdat de transformatie inwerkt op 4x4-blokken. 113

129 In het tracebestand werden de gegevens van zes macroblokken opgenomen. Macroblok 2 tot en met macroblok 5 werden geskipt. Dit wil zeggen dat het overeenkomstige blok uit het referentiebeeld moet worden gekopieerd en dat er dus geen macroblokdata of bewegingsvectoren worden gecodeerd. Macroblok 0 (lijn ) MB runlength = 0: houdt het aantal geskipte macroblokken bij van de huidige lijn. MB mode = 4: het macroblok wordt gepartitioneerd in vier 8x8-blokken (zie tabel 7.10 uit de standaard [12]). Dit zijn dus submacroblokken. Lijn 323 tot en met lijn 326 specificeren hoe de submacroblokken verder onderverdeeld worden (subpartities). De eerste twee en het vierde 8x8-blok worden niet verder onderverdeeld; het derde 8x8-blok wordt verder onderverdeeld in twee 4x8-blokken (lijn 325). Lijn 327 tot en met lijn 336 geven de x- en de y-component van de bewegingsvectoren van de vijf blokken (drie 8x8-blokken en twee 4x8-blokken) coded block pattern = 0: dit wil zeggen dat er geen macroblokdata meer moet worden verstuurd. De voorspelling voor de verschillende blokken was blijkbaar nauwkeurig genoeg zodat na quantisatie geen niet-nulcoëfficiënten meer aanwezig waren. Macroblok 1 (lijn ) MB runlength = 0: nog geen geskipte macroblokken. MB mode = 2: het macroblok wordt gepartitioneerd in twee 16x8-blokken (zie tabel 7.10 uit de standaard [12]). Lijn 341 tot en met lijn 345 geven de x- en de y-component van de bewegingsvectoren van de twee blokken. coded block pattern = 0: geen macroblokdata meer. 114

130 7.1.6 Gecodeerde slice van het eerste B-beeld (lijn ) Lijn 380 bevat de beschrijving van de NAL-eenheid. Het nal unit type heeft waarde 1 wat overeenkomt met een gecodeerde slice. Omdat nal reference idc gelijk is aan nul, kan dit beeld niet als referentiebeeld worden gebruikt. Sliceheader (lijn ) slice type = 6: dit geeft aan dat het over een B-slice gaat. frame num = 2: nummer dat wordt toegewezen aan beelden die als referentiebeeld kunnen worden gebruikt. slice qp delta = 6: wijziging van de QP die werd opgegeven in de PPS naar QP = = 32. Macroblokdata (lijn ) De eerste drie macroblokken worden geskipt (lijn ). Macroblok 27 (lijn ) MB runlength = 7: er werden reeds 7 macroblokken geskipt op de huidige lijn. B MB mode = 3: het macroblok wordt wordt niet verder gepartitioneerd (zie tabel 7.11 uit de standaard [12]). Lijn 369 en lijn 370: x- en de y-component van de bewegingsvector. coded block pattern = 0: geen gecodeerde macroblokdata. Macroblok 40 (lijn ) MB runlength = 1: reeds 1 geskipt macroblok op de huidige lijn. B MB mode = 3: het macroblok wordt niet verder gepartitioneerd en de voorspelling is bidirectioneel (zie figuur 4.12). 115

131 Lijn 375 en lijn 376 geven de x- en de y-component van de voorwaartse bewegingsvector. Lijn 377 en lijn 378 geven de x- en de y-component van de achterwaartse bewegingsvector. coded block pattern= 0: geen gecodeerde macroblokdata. 7.2 Experimenten met de referentiesoftware Bij elk experiment wordt een beknopt overzicht gegeven van de gebruikte software, de testsequenties,... Extra informatie over de gebruikte opties van de referentiesoftware kunnen in appendix E (CD-ROM) 10 gevonden worden. Wanneer naar een bestand op de CD-ROM verwezen wordt, staat het pad naar het bestand er tussen haakjes bij. De grafieken in dit onderdeel zijn in het zwart/wit. Enkele grafieken zijn voor de duidelijkheid ook in kleur in de appendix D opgenomen Wisselwerking tussen de quantisatieparameter en de bitsnelheid In tabel 7.3 kunnen de belangrijkste gegevens gevonden worden die bij deze test horen. In appendix E kunnen alle testresultaten teruggevonden worden. Het configuratiebestand van de encoder is opgenomen in onder andere het bestand f01.txt (\Resultaten\Wisselwerking QP - bitsnelheid\foreman.zip). Voor de meeste opties die niet in tabel 7.3 zijn opgenomen, werden de standaardwaarden gebruikt. Bij het coderen met behulp van de referentiesoftware wordt telkens een uitvoerbestand gegenereerd met gegevens over de gebruikte encoderingsopties en enkele statistische gegevens zoals onder andere PSNR-waarden, bitsnelheid,... De resultaten die in de volgende paragrafen besproken worden, werden uit deze uitvoerbestanden gehaald. De berekening van de PSNR door de referentiesoftware is gelijk aan deze die in paragraaf werd vermeld. 10 Op de CD-ROM staat een bestand overzicht.doc waarin een overzicht wordt gegeven van alle bestanden die op de CD-ROM staan. 116

132 Versie referentiesoftware JM Testsequenties foreman, silent, container Beeldformaat QCIF Lengte testsequentie 13 beelden GOP-structuur IBBPBBP... Gebruik Hadamard ja Aantal referentiebeelden 1 Entropiecodering CABAC Datapartitionering neen Tabel 7.3: Gegevens test 1 In grafiek 7.5 wordt de wisselwerking getoond tussen de quantisatieparameter en de bitsnelheid. Voor de B-beelden werd de QP telkens één hoger genomen dan de QP van de I- en P-beelden Wisselwerking quantisatieparameter - bitsnelheid Bitsnelheid (kbps) QP = 20 -> bitsnelheid = 397,85 kbps QP = 26 -> bitsnelheid = 217,85 kbps foreman container silent QP Figuur 7.5: Wisselwerking QP - bitsnelheid In hoofdstuk 4 (paragraaf 4.3) werd beschreven dat wanneer de QP met 6 verlaagt, de quantisatiestap verdubbelt. Of omgekeerd, telkens wanneer de QP met 6 wordt verhoogd, wordt de bitsnelheid (kbps) gehalveerd. Een voorbeeld is opgeno- 117

133 men in de grafiek. De sterkste compressie kan bereikt worden door de QP gelijk te stellen aan 51. De minimale bitsnelheden die kunnen worden bekomen, zijn opgenomen in tabel 7.4, samen met de Y-PSNR-waarde 12 voor die sequentie. In paragraaf kan de prestatie van de JVT/AVC-standaard gevonden worden voor lage bitsnelheden. De minimale bitsnelheid die daar wordt bekomen voor de testsequentie stefan (300 beelden en beeldsnelheid gelijk aan 30 Hz) is gelijk aan 8,71 kbps met een overeenkomstige Y-PSNR-waarde van 18,71 db. Voor een sequentie van 13 beelden van stefan wordt een bitsnelheid van 12,96 kbps en een Y-PSNRwaarde van 19,05 db bekomen. De Y-PSNR-waarde heeft dus ongeveer dezelfde grootte voor de lange en voor de korte sequentie. De bitsnelheid wordt wel beïnvloed door de lengte van de sequentie. Resultaten zijn meer betrouwbaar voor langere testsequenties, daar dit meer overeenkomt met echte toepassingen van videocodering. De resultaten die hier werden bekomen, worden dus best niet veralgemeend voor langere testsequenties. Testsequentie Bitsnelheid (kbps) Y-PSNR (db) foreman 9,20 22,01 silent 6,39 23,30 container 7,37 22,00 Tabel 7.4: Bitsnelheid en Y-PSNR-waarde bij maximale compressie Het is dus mogelijk om zeer lage bitsnelheden te bekomen, maar dat heeft natuurlijk gevolgen voor de kwaliteit van het beeld. In figuur 7.6 worden twee beelden uit de sequentie foreman getoond die werden gecodeerd met een QP gelijk aan 51. Het linkse beeld werd niet gefilterd, het rechtse wel. De gefilterde versie is weliswaar iets beter van kwaliteit, maar er kan toch geen enkel detail worden onderscheiden. In grafiek 7.7 wordt getoond wat het aandeel is van de verschillende beeldtypes tot de totale grootte van de gecodeerde sequentie in functie van de quantisatieparameter. De gegevens zijn afkomstig van het encoderen van de sequentie foreman. De gelijkaardige grafieken voor de sequenties silent en container kunnen in appendix E (\Resultaten\Wisselwerking QP - bitsnelheid\wisselwerking QP - bitsnelheid - aantal bits.xls) gevonden worden. 12 Dit is de PSNR-waarde voor de luminantiecomponent. 118

134 Figuur 7.6: Beeld gecodeerd met QP=51 (ongefilterd en gefilterd) De testsequentie bestond uit 13 beelden waarvan één I-beeld, vier P-beelden en acht B-beelden. Bij een sterke quantisatie (hoge QP) is het aantal bits van de B- beelden in vergelijking met het I-beeld en de P-beelden zeer klein. Dit komt omdat na bidirectionele intervoorspelling, de niet-nulcoëfficiënten in het residu klein zijn. Wanneer dit blok vervolgens wordt gequantiseerd, zullen alle niet-nulcoëfficiënten met een kleine waarde verloren zijn Vergelijking efficiëntie CABAC ten opzichte van UVLC/CAVLC In tabel 7.5 kunnen de belangrijkste gegevens gevonden worden die bij deze vergelijkende test horen. Alle testresultaten kunnen in appendix E (\Resultaten\Vergelijking CABAC UVLC,CAVLC) teruggevonden worden. De QP van de B-beelden is opnieuw één hoger dan de QP van de P-beelden. In grafiek 7.8 en grafiek 7.9 wordt een vergelijking gegeven tussen de twee entropiecoderingen voor de sequentie news en container. Op de x-as wordt de QP afgebeeld en op de y-as de winst in procent bij het gebruik van CABAC ten opzichte van het gebruik van UVLC/CAVLC. In paragraaf 4.5 van hoofdstuk 4 is vermeld dat CABAC efficiënter is dan UVLC/CAVLC omdat de lengte van de codewoorden niet-gehele waarden kunnen aannemen. De vergelijkende testen die werden uitgevoerd bevestigen over het al- 119

135 Wisselwerking QP en aantal bits (foreman) 100% 80% Aantal bits (%) 60% 40% Aantal bits B-beelden Aantal bits P-beelden Aantal bits I-beelden 20% % QP Figuur 7.7: Wisselwerking QP - aantal bits per beeldtype (Foreman) Versie referentiesoftware JM 6.1 Testsequenties silent, container Beeldformaat QCIF Lengte testsequentie 30 beelden (31 bij inter (B)) GOP-structuur intra: IIIIIII... inter (P): IPPPPPP... inter (P en B): IBBPBBP... Gebruik Hadamard ja Aantal referentiebeelden 1 Datapartitionering neen Tabel 7.5: Gegevens test 2 gemeen dat CABAC inderdaad efficiënter is. Enkel bij de sequentie news werd een negatief resultaat bekomen. Dit resultaat werd bekomen bij het coderen van een sequentie met enkel I-beelden met QP gelijk aan 12. Dit resultaat is niet zo relevant aangezien een sequentie van enkel I-beelden maar zelden zal voorkomen. Vooral de curve afkomstig van een sequentie met zowel P- als B-beelden is relevant, omdat CABAC enkel mogelijk is in het Extended Profile en dit ook B-beelden 120

136 Vergelijking UVLC/CAVLC en CABAC (news) 12% 10% Winst bitsnelheid (%) 8% 6% 4% 2% Intra Inter (P-beelden) Inter (P- en B-beelden) 0% -2% QP Figuur 7.8: Winst bij gebruik van CABAC in vergelijking met UVLC/CAVLC (news) ondersteunt. In beide grafieken vertonen de curves van de sequenties met P- en eventueel B-beelden een redelijk schommelend verloop. CABAC codeert syntaxelementen op basis van een contextmodel dat probabiliteiten bevat. De prestatie is sterk afhankelijk van deze probabiliteiten. In sommige gevallen kunnen de syntaxelementen zeer efficiënt gecodeerd worden op basis van het gekozen contextmodel, maar het kan ook zijn dat het gekozen contextmodel niet zo efficiënt is voor de codering van een bepaald syntaxelement. Het belangrijkste wat uit de grafieken kan besloten worden, zelfs met de schommelingen, is dat CABAC inderdaad een betere entropiecodering is dan de combinatie UVLC en CAVLC. Bij QP gelijk aan 40 wordt voor de sequentie met P- en B-beelden een winst van ongeveer 7,5% bekomen. Dit is zeker significant, maar CABAC verhoogt wel de complexiteit van het encoderingsproces. Wanneer de encoderingstijd vergeleken wordt voor het coderen van 30 beelden van de sequentie container (P- en B-beelden), is er echter maar een klein verschil. Dit wordt getoond in grafiek De sequentie 121

137 Vergelijking UVLC/CAVLC en CABAC (container) 12% 10% Winst bitsnelheid (%) 8% 6% 4% Intra Inter (P-beelden) Inter (P- en B-beelden) 2% 0% QP Figuur 7.9: Winst bij gebruik van CABAC in vergelijking met UVLC/CAVLC (container) is natuurlijk wel nogal kort om een betekenisvolle vergelijking te maken Vergelijking van de codeerefficiëntie van P- en SPbeelden ten opzichte van I-beelden In tabel 7.6 kunnen de belangrijkste gegevens gevonden worden die bij deze test horen. De bedoeling van deze test was de codeerefficiëntie na te gaan van de referentiesoftware van de JVT/AVC-standaard bij een sequentie met enkel P-beelden en een sequentie met enkel SP-beelden ten opzichte van een sequentie bestaande uit enkel I-beelden. Het probleem hierbij was dat versie JM 6.1 van de referentiesoftware bij het gebruik van SP-beelden enkel een GOP-structuur I P P SP P P SP ondersteunt. Er moeten minimaal twee P-beelden tussen twee SP-beelden aanwezig zijn 13. Bovendien wordt geen extra SP-wisselbeeld verstuurd (het overschakelen tussen bitstromen is niet mogelijk met de referentiesoftware). In grafiek 7.11 en grafiek 7.12 worden de resultaten van de vergelijking getoond. 13 Er kunnen wel meer dan twee P-beelden tussen elke twee SP-beelden toegevoegd worden. 122

138 Vergelijking encoderingstijd bij gebruik van CABAC en UVLC/CAVLC (container) Tijd (s.) QP CABAC CAVLC/UVLC Figuur 7.10: Encoderingstijd bij gebruik van CABAC en UVLC/CAVLC voor een sequentie met P- en B-beelden (container) Versie referentiesoftware JM 6.1 Testsequenties foreman, container Beeldformaat QCIF Lengte testsequentie 30 beelden GOP-structuur intra: IIIIIII... inter (P): IPPPPPP... inter (P en SP): I P P SP P P SP... Gebruik Hadamard ja Entropiecodering UVLC/CAVLC Aantal referentiebeelden 1 Datapartitionering neen Tabel 7.6: Gegevens test 3 De grafieken stellen de winst in bitsnelheid (in procent) voor van de P-sequentie en de SP-sequentie ten opzichte van de sequentie met enkel I-beelden. De winst is voor beide sequenties ongeveer gelijk, wat te verwachten is aangezien het coderen van SP-beelden maar weinig verschilt van het coderen van P-beelden (zie paragraaf 5). 123

139 Winst in bitsnelheid van P-en SP-beelden ten opzichte van I-beelden (foreman) 100% 96% 92% Winst bitsnelheid (%) 88% 84% 80% 76% 72% P-beelden SP-beelden 68% 64% 60% QP Figuur 7.11: Vergelijking van de codeerefficiëntie van P- en SP-beelden ten opzichte van I-beelden (foreman) Efficiëntie van het gebruik van meerdere referentiebeelden In tabel 7.7 kunnen de belangrijkste gegevens gevonden worden die bij deze test horen. De bedoeling van deze test was na te gaan wat het effect is van het gebruik van meerdere referentiebeelden op de PSNR-waarde, de beeldsnelheid en de encoderingstijd. De resultaten die werden bekomen zijn terug te vinden in appendix E (\Resultaten\Buffer met 1 en 5 beelden). De resultaten bij het coderen van 30 beelden van de testsequentie foreman zijn in tabel 7.8 opgenomen in functie van de QP. Zoals uit de resultaten blijkt, is het gebruik van vijf referentiebeelden niet significant voordelig wanneer de bitsnelheid of PSNR-waarde wordt bekeken. De encoderingstijd verhoogt wel bij het gebruik van meerdere referentiebeelden. Omdat dit effect voor een korte sequentie van 30 beelden niet zo duidelijk te zien is, werden ook eens 120 beelden van foreman gecodeerd met één en vijf referentiebeelden. De resultaten zijn opgenomen in tabel 7.9. Voor een QP gelijk aan 40 duurt het 124

140 Winst in bitsnelheid van P-en SP-beelden ten opzichte van I-beelden (container) 100% 96% 92% Winst bitsnelheid (%) 88% 84% 80% 76% 72% P-beelden SP-beelden 68% 64% 60% QP Figuur 7.12: Vergelijking van de codeerefficiëntie van P- en SP-beelden ten opzichte van I-beelden (container) Versie referentiesoftware JM 6.1 Testsequentie foreman Beeldformaat QCIF Lengte testsequentie 30 en 120 beelden GOP-structuur IPPPPPP... Gebruik Hadamard ja Entropiecodering CABAC Datapartitionering neen Tabel 7.7: Gegevens test 4 encoderen met vijf referentiebeelden ongeveer drie keer langer dan bij het gebruik van één referentiebeeld. De kwaliteit verbetert met slechts 0,27 db en de bitsnelheid daalt met maar 0,1 kbps. Het gebruik van meerdere referentiebeelden lijkt dus niet echt zinvol. Het is echter belangrijk om rekening te houden met de testsequentie die werd gebruikt. Foreman is een vrij complexe testsequentie. Daarmee wordt bedoeld dat er veel beweging aanwezig is van de persoon zelf in de scène en ook van de 125

141 camera 14. Het gebruik van meerdere referentiebeelden zal waarschijnlijk efficiënter zijn bij sequenties waar bijvoorbeeld een bepaalde regelmaat in voorkomt. vijf referentiebeelden één referentiebeeld QP Bitsnelheid Y-PSNR Codeertijd Bitsnelheid Y-PSNR Codeertijd (kbps) (db) (s.) (kbps) (db) (s.) 50 13,68 21,87 33,782 13,87 21,79 18, ,812 27,32 32,52 31,42 27,34 19, ,04 32,28 37,032 73,08 32,24 21, ,34 37,44 41, ,67 37,32 26, ,75 43,29 51,89 625,01 43,21 35,923 Tabel 7.8: Vergelijking gebruik van één ten opzichte van vijf referentiebeelden (30 beelden) vijf referentiebeelden één referentiebeeld QP Bitsnelheid Y-PSNR Codeertijd Bitsnelheid Y-PSNR Codeertijd (kbps) (db) (s.) (kbps) (db) (s.) 40 31,49 28,55 978, ,23 28,32 393, ,01 33,94 970,270 78,91 33,67 409,9055 Tabel 7.9: Vergelijking gebruik van één ten opzichte van vijf referentiebeelden (120 beelden) Codering aan lage bitsnelheid Deze test werd uitgevoerd om de prestatie na te gaan van drie codecs bij het coderen tegen lage bitsnelheden. De codecs die werden gebruikt zijn de JVT/AVC-standaard, DivX 5.04 en VSS H.264. Hierna volgt een korte uitleg voor elk van de gebruikte codecs. JVT/AVC-standaard: referentiesoftware versie AHM 2.0 De referentiesoftware van de JVT/AVC-standaard versie AHM is een uitbreiding van versie JM 6.1, er werd namelijk een rate-control-mechanisme toegevoegd Dit wordt ook wel panning genoemd. 15 Deze software is ook op de CD-ROM te vinden (\Software\ahm20.zip). 16 Er werd nog een tweede optie aan toegevoegd namelijk, Adaptive Search Range, waarbij het zoekbereik bij intervoorspelling kan worden aangepast. Deze optie werd voor deze en volgende testen echter niet gebruikt. 126

142 Het rate-control-algoritme dat wordt toegepast, gaat samengevat als volgt 17 : Het gebruikte algoritme kiest voor elk macroblok een bepaalde quantisatieparameter om de vooropgestelde bitsnelheid te bereiken. Het algoritme werkt in vier stappen: 1. Bitallocatie: Aan elk beeld van een GOP wordt een bepaald aantal bits toegekend. Dit aantal is verschillend voor I-, P- en B-beelden. 2. Selectie van de eerste codeermodus: Gebruikmakend van een voorspelling van de QP (normaalgezien wordt de QP van het vorige macroblok als voorspelling genomen) wordt Rate-Distortion Optimization (RDO) uitgevoerd om de codeermodus voor het opstellen van de voorspelling, te vinden. 3. Bepaling van de QP Na de toepassing van MC of intravoorspelling, wordt de activiteit van het macroblok berekend. De berekening van de activiteit steunt op de berekening van de SAE tussen het originele en het voorspelde macroblok. Afhankelijk van onder andere deze activiteit en het aantal bits dat nog beschikbaar is voor het huidige beeld, wordt een nieuwe waarde van de QP berekend. 4. Selectie van de tweede modus: Als het verschil tussen de voorspelde QP en de uiteindelijke QP (uit stap 3) klein is, wordt de voorspelde QP gebruikt voor de compressie van het macroblok. Anders, wanneer het verschil groot is, wordt opnieuw RDO toegepast voor het vinden van de nieuwe optimale codeermodus. De gevonden modus en de uiteindelijke QP worden dan gebruikt voor de codering van het huidige macroblok. DivX 5.04 De DivX Pro codec voldoet aan het MPEG-4 Advanced Simple Profile 18. De werkwijze die werd gevolgd bij het coderen met de DivX-codec is: 17 Voor meer informatie over het gebruikte rate-control-mechanisme kan [14] geraadpleegd worden. 18 Dit is een uitbreiding van het Simple Profile en ondersteunt B-beelden, GMC (Global Motion Estimation), quarter pel ME en twee quantisatiemogelijkheden (scalaire en matrixquantisatie.) 127

143 1. Het coderen van video door middel van DivX werd met behulp van Virtual- Dub versie uitgevoerd. Deze software kan avi-bestanden 19 comprimeren waarbij de gebruikte codec kan worden gekozen. Meer informatie over VirtualDub kan gevonden worden op de website ervan [34]. 2. De testsequenties in YUV-formaat moeten eerst omgezet worden in avi-bestanden 20. De omzetting werd gemaakt door middel van de software yuvtoavi, een tool ontwikkeld door Microsoft. 3. Na de omzetting werd de videosequentie in avi-formaat gecomprimeerd door middel van DivX Het gecomprimeerde avi-bestand werd vervolgens terug omgezet naar een yuvbestand door middel van de software avitoyuv, ook een product van Microsoft. 5. De berekening van de PSNR-waarden werd uitgevoerd met de software AtomicPlayer 21. Deze software werd in het Multimedia Lab van de Universiteit Gent ontwikkeld. Voor het coderen van een videosequentie met de DivX-codec was het nodig om de optie multipass encoding te gebruiken. Bij het gebruik van deze optie wordt de sequentie twee of meer keren doorlopen. Het rate-control-mechanisme werkt niet goed wanneer een sequentie in één keer wordt gecodeerd. Bij de eerste doorloop wordt informatie over de sequentie opgeslagen in een logbestand. De gegevens uit dit bestand worden gebruikt bij de tweede doorloop om de bitsnelheid zo te laten variëren dat de kwaliteit voor alle beelden wordt geoptimaliseerd. Tijdens de eerste doorloop wordt informatie bijgehouden over de beweging in de beelden van de sequentie. De bitsnelheid wordt ongeveer constant gehouden bij de eerste doorloop. Dit heeft echter tot gevolg dat de beelden die veel verandering bevatten van slechte kwaliteit zullen zijn. Er worden onvoldoende bits besteed aan de beelden met veel beweging. De tweede doorloop kan de kwaliteit van alle beelden optimaliseren door gebruik te maken van de bewegingsinformatie die tijdens de eerste doorloop werd opgeslagen in het logbestand. Voor meer informatie kan [7] worden geraadpleegd. 19 Audio Video Interleaved 20 Dit is een omzetting van de YUV- naar de RGB-kleurenruimte 21 Atomicplayer, yuvtoavi, en avitoyuv zijn te vinden op de CD-ROM in de map \Software\. 128

144 De opties die werden gebruikt bij het coderen met de DivX-codec zijn 22 : Tabblad Bitrate Control Bitrate modes: multipass, 1st pass / multipass, nth pass Tabblad General Parameters Light Psychovisual enhancements Max. Keyframe interval: 100 frames Scene change threshold: 50% Performance quality: slowest Encode as progressive Tabblad Profiles Home Theatre Profile: B frames allowed, Interlace allowed Resolutie: 176 lines x 144 pixels Frame Rate: 30 fps VSS H.264 De VSS H.264-codec is een product van Vanguard Software Solutions, Inc. (zie [35]). De versie die werd gebruikt is de Beta2-versie, die gebaseerd is op de referentiesoftware van de JVT/AVC-standaard versie JM 4.2. De codec voldoet aan het Baseline Profile en ondersteunt dus geen B-beelden. Volgens [35] is de VSS H.264-codec geoptimaliseerd zodat de encodeersnelheid 2 tot 7 keer beter zou zijn (afhankelijk van de codeermodus) dan bij de referentiesoftware. Ook deze codec werd gebruikt in combinatie van VirtualDub. De omzetting van de bestanden in YUV-formaat naar de avi-bestanden werd op dezelfde manier uitgevoerd als in de vorige paragraaf. Het was echter niet nodig om de gecomprimeerde 22 De opties zijn per tabblad geordend. Als een parameter niet wordt vermeld, is de standaardwaarde gebruikt. De opties worden in het Engels weergegeven om geen onduidelijkheden te veroorzaken. 129

145 avi-bestanden opnieuw om te zetten naar YUV-bestanden. Vanguard Software Solutions voorziet zelf software, avipsnr die voor de avi-bestanden de PSNR-waarden 23 kan berekenen. Deze software kan teruggevonden worden op de webpagina van Vanguard Software Solutions. [35] De opties die werden gebruikt bij het coderen met de VSS H.264-codec zijn: Tabblad Encoder Use Rate control Speed : Normal Max. Keyframe interval: 255 frames Rate Control Auto Rate Control Configuration Vergelijking van de drie codecs bij het coderen aan lage bitsnelheden In tabel 7.10 kunnen de belangrijkste gegevens gevonden worden die bij deze test horen. Andere belangrijke opties werden in vorige paragrafen reeds vermeld. De resultaten die werden bekomen zijn terug te vinden in appendix E (\Resultaten\Prestatie lage bitsnelheid). Codec JVT/AVC-referentiesoftware DivX VSS H.264 Versie AHM Beta2 Testsequenties stefan Beeldformaat QCIF Lengte testsequentie 295 beelden 300 beelden 300 beelden GOP-structuur IBBPBBP... gebruik B-beelden IPPPPP... Tabel 7.10: Gegevens test 1 De bekomen resultaten worden afgebeeld in grafiek Uit de grafiek blijkt dat de DivX- en de VSS H.264-codec geen goede resultaten geven. De bekomen PSNR-waarden zijn niet betrouwbaar als vergeleken wordt met de resultaten van de 23 Er moet toch wel omzichtig omgesprongen worden met de resultaten die deze tool bekomt. Wanneer vergeleken wordt met de PSNR-waarden berekend door AtomicPlayer, liggen de waarden bekomen door avipsnr hoger dan de waarden bekomen door AtomicPlayer.[30] 130

146 JVT/AVC-standaard. Het coderen aan dergelijke lage bitsnelheden wordt niet goed ondersteund door de VSS H.264- en de DivX-codec. Prestatie lage bitsnelheden (stefan) Y-PSNR (db) JVT/AVC DivX 5.04 VSS H Bitsnelheid (kbps) Figuur 7.13: Vergelijking prestatie bij coderen aan lage beeldsnelheden (stefan) De testsequentie stefan is ook wel vrij complex. Sequenties die aan lage bitsnelheden moeten worden gecodeerd, zijn over het algemeen eenvoudiger. Een voorbeeld hiervan is de toepassing videotelefonie. Meestal zal enkel het gezicht van de persoon in beeld zijn en zal de achtergrond vrij gelijk blijven. De JVT/AVC-standaard presteert hier duidelijk beter, want zelfs voor deze complexe testsequentie gebeurt de codering zoals te verwachten was (namelijk, een stijgende curve en dus geen constante zoals bij DivX en VSS H.264). In tabel 7.11 wordt in de eerste kolom de opgegeven bitsnelheid gegeven en in de volgende kolommen de benaderde bitsnelheid bij het coderen met de JVT/AVCcodec, de DivX-codec en de VSS H.264-codec De bitsnelheden bij DivX-codec werden bekomen door de bestandsgrootte in kbit (gemeten op een Windows-machine) te delen door de lengte van de sequentie in seconden (10 s.). 131

147 Opgegeven bitsnelheid Benaderde bitsnelheid (kbps) (kbps) JVT/AVC Divx 5.04 VSS , , , , , , , , , Tabel 7.11: Opgegeven bitsnelheid en benaderde bitsnelheid bij gebruik van rate-control Vergelijkende test: deel 1 Deze paragraaf bevat de resultaten bekomen bij het uitvoeren van een vergelijkende test om de prestatie van verschillende codecs na te gaan. Daarvoor werd telkens een sequentie van 300 beelden gecodeerd. In het eerste deel werden volgende codecs vergeleken: JVT/AVC-standaard (gegevens zie tabel 7.12) DivX 5.04 (beschrijving zie paragraaf 7.2.5) VSS H.264 (beschrijving zie paragraaf 7.2.5) XviD (zie verder) Microsoft Windows Media Video 9 (2003) (zie verder) XviD MPEG-4 codec XviD is een open source-codec die codering volgens het MPEG-4 Simple Profile en het MPEG-4 Advanced Simple Profile mogelijk maakt. Voor deze test werden de instellingen zo aangepast dat werd voldaan aan het MPEG-4 Simple Profile. De belangrijkste beperking is dat geen B-beelden zijn toegestaan in het MPEG-4 Simple 132

148 Versie referentiesoftware AHM 2.0 Testsequentie foreman, stefan Beeldformaat QCIF Lengte testsequentie 295 GOP-structuur IBBPBBP... Gebruik Hadamard ja Entropiecodering CABAC Datapartitionering neen Tabel 7.12: Gegevens test 6 Profile. Meer informatie over de XviD-codec kan gevonden worden op de webpagina??. Volgende instellingen werden gebruikt: Tabblad Encoding mode 1 pass CBR Advanced Options Global settings Motion search precision: 6 - Ultra High Quantization type: H.263 FourCC used: XVID VHQ mode: 0 - Off Maximum I-frame interval: 300 Minimum I-frame interval: 1 Geen van de opties aangeklikt (enable lumi masking, enable interlacing, Quarterpel, enable greyscale, use chroma motion, global motion compensation) B-frame control: Maximum B-frames: -1 (dus geen B-beelden gebruikt) B-frame quantizer ratio (%): 150 B-frame quantizer offset (%): 100 B-frame threshold: 0 133

149 DX50 B-VOP aangeklikt, de rest (print debug info on each frame, packed bitstream) niet. Quantization Min I-frame quantizer: 1 Max I-frame quantizer: 31 Min P-frame quantizer: 2 Max P-frame quantizer: 31 Niet van toepassing voor B-frames Two pass Niet van toepassing want 1 pass CBR gebruikt Alt. Curve Alle standaardinstellingen gebruikt Decoder options: geen filter gebruikt Microsoft Windows Media Video 9-codec (2003) Informatie over deze codec van Microsoft is te vinden op hun webpagina [8]. De gebruikte instellingen zijn: Tabblad Compression Compression control: One-pass CBR Keyframe interval: 8000 ms Decoder complexity: Main Smooth-sharp: 80 Buffer size: 5000ms Performance - quality: 2e beste kwaliteit Andere: standaardinstellingen gebruikt In grafiek 7.14 en grafiek 7.15 worden de bekomen resultaten afgebeeld voor de testsequentie foreman en stefan. De grafieken tonen de Y-PSNR-waarde in functie 134

150 van de bitsnelheid. Deze grafieken zijn ook in appendix D (grafieken D.1 en D.2) opgenomen. Uit beide grafieken blijkt dat de prestatie van de JVT/AVC-codec deze van de andere codecs overtreft. Bij de hoogste bitsnelheid die werd getest (2100 kbps), is er bij de sequentie stefan een verschil van minstens 6 db en bij de sequentie foreman een verschil van minstens 10 db in vergelijking met alle andere codecs. De prestatie van de VSS H.264-codec is ook vrij goed als rekening gehouden wordt met het feit dat geen B-beelden zijn toegelaten bij deze codec 25. PSNR-vergelijking foreman Y-PSNR (db) Bitsnelheid (kbps) XviD VSS H.264 JVT/AVC DivX 5.04 WMV9 Figuur 7.14: Vergelijking prestatie codecs (foreman) De PSNR-waarden die in de grafieken 7.14 en 7.15 worden voorgesteld zijn gemiddelde waarden. Het is ook belangrijk om de fluctuatie van de PSNR-waarden over de hele sequentie te bekijken. In het meest ideale geval zou de kwaliteit over de volledige sequentie ongeveer constant moeten blijven. In grafiek 7.16 wordt de fluctuatie van de PSNR-waarden afgebeeld voor de sequentie foreman bij het coderen tegen een bitsnelheid van 100 kbps. Deze grafiek 25 Maar of de berekening van de psnr-waarde correct gebeurt, is een andere vraag (zoals reeds vermeld). 135

151 PSNR-vergelijking stefan Y-PSNR (db) Bitsnelheid (kbps) XviD VSS H.264 JVT/AVC DivX 5.04 WMV9 Figuur 7.15: Vergelijking prestatie codecs (stefan) is ook in appendix D (grafiek D.4) opgenomen. Voor alle codecs fluctueert de PSNR-waarde nogal, maar de grootste verschillen in PSNR-waarde zijn te zien bij de JVT/AVC-codec. De iets grotere vierkantjes in de grafiek geven aan waar de I-beelden zich in de sequentie bevinden. De QP s die door het rate-control-mechanisme werden gekozen variëren tussen de 15 en de 38 wat de sterke fluctuatie van de PSNR-waarden verklaart. In grafiek 7.17 wordt de fluctuatie van de PSNR-waarden bij het coderen van de sequentie foreman tegen 2100 kbps uitgezet(zie ook appendix D voor een versie in kleur (grafiek D.5)). Bij de JVT/AVC-codec is er duidelijk een piek te zien wanneer een I-beeld in de sequentie voorkomt (aangeduid met een groter vierkantje). De curve van de JVT/AVC-codec fluctueert ook weer het meest. De P-beelden hebben over het algemeen een betere PSNR-waarde dan de B-beelden. In grafieken 7.18 en 7.19 wordt de fluctuatie van de PSNR-waarden bij het coderen van de sequentie stefan tegen 100 en 2100 kbps afgebeeld. De twee grafieken zijn ook in kleur in appendix D (grafiek D.6 en grafiek D.7) opgenomen. Bij het coderen tegen 2100 kbps zijn er in de curve van de DivX-codec zeer sterke 136

152 Fluctuatie Y-PSNR foreman Y-PSNR (db) VSS H.264 JVT/AVC DivX 5.04 XviD WMV Beeldnummer Figuur 7.16: Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (foreman) dalingen in PSNR-waarde te zien. De PSNR-waarde daalt naar het einde van de sequentie in bepaalde punten tot slechts 16 db. Verondersteld wordt dat de DivX-codec beslist om, vooral in stukken van de sequentie waar er veel beweging is, bepaalde beelden twee keer na elkaar te tonen. Er wordt één beeld niet getoond, maar vervangen door het volgende beeld. De kwaliteit van dit beeld zelf is goed, maar bij de berekening van de PSNR-waarde is er een groot verschil tussen dit beeld en het overeenkomstig beeld van de originele sequentie. In tabel 7.13 wordt voor de beelden 181 tot en met 185 de PSNR-waarde gegeven. De PSNR-waarde voor beeld 182 en 184 zijn in vergelijking met de andere beelden zeer laag. Dit komt omdat beeld 182 een kopie is van beeld 183 en beeld 184 een kopie is van beeld 185. Dit wordt verduidelijkt in figuur Deze figuur toont aan de ene kant de beelden van de originele sequentie (beeld 180 tot en met 185) en aan de andere kant de beelden van de gecodeerde sequentie. Deze figuur is in kleur te vinden in appendix D, figuur D.3. In figuur 7.21 wordt een stukje van het logbestand getoond dat werd bekomen bij de encodering van stefan aan 2100 kbps door middel van de DivX-codec. 137

153 Fluctuatie Y-PSNR foreman 2100 kbps Y-PSNR (db) VSS H.264 JVT/AVC DivX 5.04 XviD WMV beeldnummer Figuur 7.17: Fluctuatie Y-PSNR-waarden 2100 kbps voor verschillende codecs (foreman) Beeldnummer Y-PSNR (db) , , , , ,82 Tabel 7.13: Beeldnummer en PSNR-waarde bij coderen van de sequentie stefan aan 2100 kbps Normaalgezien is het aantal bits voor B-beelden in vergelijking met P-beelden kleiner (bv. B-beeld 179: bits en P-beeld 180: ). Voor beeld 181 (Bbeeld) is het aantal bits gelijk aan (wat veel is voor een B-beeld). Voor beeld 183 (B-beeld) is het aantal bits gelijk aan De keuze om een beeld te skippen (vervangen door het volgende) hangt duidelijk af van de parameter motion complexity. Wanneer deze een waarde verhoogt (boven ±1), is het mogelijk dat het volgende B-beeld wordt geskipt. Waarschijnlijk wordt een gemiddelde waarde bijgehouden van de motion complexityen wanneer 138

154 Fluctuatie Y-PSNR stefan 100 kbps Y-PSNR (db) VSS H.264 JVT/AVC DivX 5.04 XviD WMV Beeldnummer Figuur 7.18: Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) die boven een bepaalde grenswaarde komt, wordt het volgende B-beeld geskipt. Bijvoorbeeld: Beeld 181 heeft een motion complexity van en beeld 183 een motion complexity met als gevolg dat beeld 182 (B-beeld tussen deze twee P-beelden) wordt geskipt. Beeld 183 heeft een motion complexity van en beeld 185 een motion complexity met als gevolg dat beeld 184 (B-beeld) wordt geskipt. De PSNR-kwaliteitsmaat faalt hier dus. De kwaliteit wordt berekend voor elk beeld uit de gecodeerde sequentie op basis van het overeenkomstige beeld uit de originele sequentie. Bij twee verschillende beelden is de PSNR-waarde uiteraard laag. De zeer lage PSNR-waarden beïnvloeden natuurlijk de gemiddelde PSNRwaarde. Wanneer alle zeer lage waarden worden vervangen door de PSNR-waarde van het volgende beeld, wordt een gemiddelde van 36,38 db bekomen. De originele 139

155 gemiddelde PSNR-waarde is gelijk aan 35,29 db. Er is dus een verschil van iets meer dan 1 db. Winst in bitsnelheid van de JVT/AVC-standaard ten opzichte van DivX 5.04 In tabel 7.14 wordt een overzicht gegeven van de winst in bitsnelheid in functie van bepaalde PSNR-waarden voor foreman en stefan 26. benaderingen, maar de afwijking zal nooit groot zijn. Deze berekeningen zijn Uit deze gegevens kan besloten worden dat het objectief bereikt is, er is inderdaad een winst van ongeveer 50% in bitsnelheid. Het is niet aan te raden deze gegevens te veralgemenen. Er werden immers maar twee verschillende sequenties getest en de winst werd voor slechts enkele PSNR-waarden berekend. 26 Voor stefan werden lagere waarden voor de PSNR-waarde genomen dan bij foreman omdat de maximum PSNR-waarde die wordt bereikt bij DivX 5.04 ongeveer 36 db is. Fluctuatie Y-PSNR stefan 2100 kbps Y-PSNR (db) Beeldnummer VSS H.264 JVT/AVC DivX 5.04 XviD WMV9 Figuur 7.19: Fluctuatie Y-PSNR-waarden 100 kbps voor verschillende codecs (stefan) 140

156 originele sequentie sequentie DivX 2100 kbps Figuur 7.20: Beelden 180 tot en met 185 uit de originele sequentie en de gecodeerde sequentie met DivX 5.04 tegen 2100 kbps (stefan) 141

157 Beeldnummer Y-PSNR (db) , , , , ,82 Beeld 181 en 182 zijn identiek (met 181 een kopie van 182), net zoals beeld 184 en 185 (met 184 een kopie van 185). Als je kijkt in de log-file (stefan_qcif_divx_2100.log): deltat beeldnummer beeldtype totaal aantal bits motion complexity texture complexity P B P B P B P B P B P B Normaalgezien is het aantal bits voor B-beelden in vergelijking met P-beelden kleiner (bv. Beeld 179: bits en beeld 180: => dus aantal bits voor B-beeld is ongeveer de helf van het aantal bits van het P-beeld) Figuur 7.21: Deel van het logbestand bij het coderen van stefan (2100 kbps - DivX) Voor beeld 181 (B-beeld) is het aantal bits gelijk aan (wat veel is voor een B-beeld). Foreman Stefan Voor beeld 183 (B-beeld) is het aantal bits gelijk aan QP JVT/AVC Divx 5.04 Winst QP JVT/AVC Divx 5.04 Winst bitsnelheid De keuze om een bitsnelheid beeld te skippen (vervangen (%) door het volgende) bitsnelheid hangt duidelijk bitsnelheid af van de (%) parameter motion_complexity. Wanneer deze een waarde verhoogt (boven de 1), is het % % % % % % % % % % Tabel 7.14: Winst in bitsnelheid van de JVT/AVC-standaard ten opzichte van DixX Vergelijkende test: deel 2 In dit tweede deel werden de resultaten die werden besproken in paragraaf samengebracht met de resultaten bekomen door Hans Vanhimbeeck. [30] Door Hans werd een gelijkaardige vergelijking gemaakt voor de volgende codecs: 1. 3D-EZBC 27 : wavletgebaseerde codec met schaalbaarheid in drie richtingen (temporele, ruimtelijke en SNR-schaalbaarheid) 2. MPEG-2 3. VSS H.264: dezelfde codec (en versie) als deze uit paragraaf VSS Video Codec: codec van Vanguard Software Solutions, Inc. 27 3D Embedded Zero Block Coding, of ook wel de Woods-codec genoemd 142

158 5. VSS Wavelet: waveletgebaseerde codec van Vanguard Software Solutions, Inc. Voor meer informatie over deze codecs en de bekomen resultaten kan de scriptie van Hans Vanhimbeeck, Studie van Wavelet-gebaseerde videocompressie, geraadpleegd worden. In de grafieken 7.22 en 7.22 wordt de prestatie van de JVT/AVC-codec vergeleken met deze van de 3D-EZBC-codec. De PSNR-waarden bekomen bij de JVT/AVCcodec liggen gemiddeld 1,83 db hoger dan de PSNR-waarden bekomen bij de 3D- EZBC-codec. Vergelijking van de prestatie van JVT/AVC en 3D-EZBC (stefan) Y-PSNR (db) JVT/AVC 3D-EZBC bitsnelheid (kbps) Figuur 7.22: Vergelijking prestatie JVT/AVC en 3D-EZBC (stefan) In grafiek 7.24 en grafiek 7.25 wordt de vergelijking gemaakt tussen de JVT/AVCcodec (resultaten uit paragraaf 7.2.6), MPEG-2, 3D-EZBC, VSS Video Codec en de VSS Wavelet-codec. Deze twee grafieken zijn ook in kleur in appendix D te vinden (grafiek D.8 en grafiek D.9) De grafieken die de prestatie van alle codecs uit deze en vorige paragraaf vergelijken, zijn te vinden in appendix D (grafieken D.10 en D.11) omdat de zwart/witversie ervan niet duidelijk genoeg is. 143

159 Vergelijking van de prestatie van JVT/AVC en 3D-EZBC (foreman) Y-PSNR (db) JVT/AVC 3D-EZBC bitsnelheid (kbps) Figuur 7.23: Vergelijking prestatie JVT/AVC en 3D-EZBC (foreman) Vergelijking van de prestatie van verschillende codecs (stefan) Y-PSNR (db) JVT/AVC 3D-EZBC MPEG-2 VSS Video Codec VSS Wavelet bitsnelheid (kbps) Figuur 7.24: Vergelijking prestatie JVT/AVC en andere codecs (stefan) 144

160 Vergelijking van de prestatie van verschillende codecs (foreman) Y-PSNR (db) JVT/AVC 3D-EZBC MPEG-2 VSS Video Codec VSS Wavelet bitsnelheid (kbps) Figuur 7.25: Vergelijking prestatie JVT/AVC en andere codecs (foreman) 145

161 Besluit Het basisontwerp van de JVT/AVC-standaard is in grote lijnen hetzelfde als dat van eerdere standaarden. Er zijn echter enkele belangrijke verschillen: Verbeterde motion compensation (groot aantal blokgroottes) Geheelwaardige transformatie op kleinere blokken Verbeterde in-loop antiblokfilter Efficiëntere entropiecodering De JVT/AVC-standaard bereikt een hoge compressie-efficiëntie in vergelijking met andere standaarden en bedrijfseigen codecs. Het is wel belangrijk rekening te houden met het feit dat de JVT/AVC-standaard hogere vereisten heeft op vlak van reken- en geheugencomplexiteit. De nieuwe aspecten zoals het groot aantal intravoorspellingsmodi, het aantal mogelijke partitioneringen van een macroblok en het eventueel gebruik van de aritmetische entropiecodering, verhogen de benodigde reken- en geheugencapaciteit. Wanneer meerdere referentiebeelden mogen worden gebruikt, zullen de geheugenvereisten nog eens stijgen. Het is dus nodig om een afweging te maken tussen de efficiëntie en de complexiteit van de JVT/AVCstandaard. De verspreiding van de JVT/AVC-standaard zal enkele inspanningen vergen. Ten eerste zullen er aanpassingen nodig zijn aan MPEG-4 deel 1 (Systems). Een tweede punt is dat dit nieuwe deel binnen MPEG-4, dus MPEG-4 deel 10 niet compatibel is met MPEG-4 (deel 2), de huidige videocompressietechnologie binnen MPEG-4. Een derde punt dat belangrijk is voor de verspreiding, is het Basline Profiel gratis ter beschikking te stellen. Momenteel bestaat daar nog geen zekerheid over, maar 146

162 verwacht wordt dit het er wel zou doorkomen. Dit kan de overschakeling van het gebruik van een oudere standaard naar de JVT/AVC-standaard vergemakkelijken. In de toekomst zullen er aan de JVT/AVC-standaard zeer waarschijnlijk nog enkele uitbreidingen worden toegevoegd. Er is de vraag naar de ondersteuning van het 4:4:4- en 4:2:2-onderbemonsteringsformaat met 8, 10 of 12 bits per sample en ook de vraag naar de mogelijkheid tot schaalbare videocodering. Binnen MPEG-4 wordt momenteel gewerkt aan een bestandsformaat voor de JVT/AVC-standaard. Het vormt een nieuw deel, namelijk MPEG-4 deel 15. Verder is het nog afwachten of de JVT/AVC-standaard in de basislaag bij FGS zal worden gebruikt. 147

163 Bijlage A Afkortingen CIF CABAC CAVLC CODEC AVC DCT DSL DVD FCD FDIS FLC GOP HDTV IDCT IS ISO JND JVT ITU MC ME MPEG Common Intermediate Format Context-based Adaptive Binary Arithmetic Coding Context-based Adaptive Variable Length Coding encoder/decoder-paar Advanced Video Coding Discrete Cosine Transformation Digital Subscriber Line Digital Versatile Disk Final Committee Draft Final Draft International Standard Fixed Length Code Group Of Pictures High Definition TeleVision Inverse DCT International Standard International Organisation for Standardisation Just Noticeable Distortion Joint Video Team International Telecommunication Union Motion Compensation Motion Estimation Moving Picture Experts Group 148

164 NTSC PAL PSNR QCIF RGB RTP RVLC SDTV SECAM SQCIF VCEG VLC VLE VLD YCrCb National Television Systems Committee Phase Alteration Line Peak Signal to Noise Ratio Quarter Common Intermediate Format Rood - Groen - Blauw kleurenruimte Real Time Protocol Reversible Variable Length Coding Standard Definition Television Sequential Couleur Avec Memoire of Sequential Colour with Memory Sub Quarter Common Intermediate Format Video Coding Experts Group Variable Length Coding Variable Length Encoder Variable Length Decoder Luminance - Red Chrominance - Blue Chrominance kleurenruimte 149

165 Bijlage B Berekeningen B.1 Omvorming van de 4x4-DCT tot de 4x4-geheelwaardige transformatie Deze berekening komt uit [5]. De 4x4-DCT van een invoermatrix X wordt gegeven door: met a a a a Y = AXA T = b c c b a a a a c b b c a = 1 2 b = X a b a c a c a b a c a b a b a c (B.1) cos(π 8 ) c = 2 cos(3π 8 ) (B.2) Deze matrixvermenigvuldiging kan gefactoriseerd worden tot de volgende equivalente vorm. Y = (CXC T ) E = d d d 1 1 d X d a 2 ab a 2 ab 1 d d 1 1 ab b 2 ab b 2 a 2 ab a 2 ab d ab b 2 ab b 2 (B.3) CXC T wordt de kerntransformatie genoemd. E is een matrix met schaalfactoren 150

166 en het symbool geeft aan dat elk element van CXC T wordt vermenigvuldigd met de schaalfactor op dezelfde positie in matrix E (met andere woorden de scalaire vermenigvuldiging). De constante d is gelijk aan c/b (ongeveer gelijk aan 0,414). Om de implementatie van de transformatie te vereenvoudigen wordt d afgerond op 0.5. Om ervoor te zorgen dat de transformatie orthogonaal blijft wordt b ook aangepast. We krijgen dus: a = 1 2 b = 2 5 d = 1 2 (B.4) De tweede en de vierde rij van matrix C en de tweede en vierde kolom van de matrix C T worden geschaald met een factor 2. De matrix E wordt ook herschaald om dit te compenseren. Door deze schaling worden vermenigvuldigingen met 1/2 in CXC T vermeden, want dit zou leiden tot een verlies aan nauwkeurigheid bij het gebruik van enkel geheelwaardige berekeningen. De uiteindelijke transformatie is de volgende: Y = (C f XCf T ) E = X a 2 ab/2 a 2 ab/2 ab/2 b 2 /4 ab/2 b 2 /4 a 2 ab/2 a 2 ab/2 ab/2 b 2 /4 ab/2 b 2 /4 (B.5) Deze transformatie is een benadering van de 4x4-DCT. Omdat we de factoren b en d hebben aangepast, zal deze nieuwe transformatie niet identiek zijn aan de 4x4-DCT. De schalingsmatrix E wordt in het quantisatieproces verwerkt. De gebruikte 4x4-transformatiematrix is dus gelijk aan: C f = (B.6) 151

167 Bijlage C Tracebestand SPS: profile idc ( 0) SPS: level idc ( 0) SPS: more than one slice group allowed flag 0 ( 0) SPS: arbitrary slice order allowed flag 0 ( 0) SPS: redundant slices allowed flag 0 ( 0) SPS: seq parameter set id 1 ( 0) SPS: log2 max frame num minus ( 4) SPS: pic order cnt type 1 ( 0) SPS: log2 max pic order cnt lsb minus ( 4) SPS: num ref frames 010 ( 1) SPS: required frame num update behaviour flag 0 ( 0) SPS: frame width in mbs minus ( 10) SPS: frame height in mbs minus ( 8) SPS: frame mbs only flag 1 ( 1) SPS: direct 8x8 inference flag 0 ( 0) SPS: vui parameters present flag 0 ( 0) 17 Annex B NALU w/ long startcode, len 8, forbidden bit 0, nal reference idc 3, nal unit type PPS: pic parameter set id 1 ( 0) PPS: seq parameter set id 1 ( 0) PPS: entropy coding mode 0 ( 0) PPS: pic order present flag 0 ( 0) PPS: num slice groups minus1 1 ( 0) PPS: num ref idx l0 active minus1 1 ( 0) 152

168 PPS: num ref idx l1 active minus1 1 ( 0) PPS: weighted pred flag 0 ( 0) PPS: weighted bipred idc 00 ( 0) PPS: pic init qp minus26 1 ( 0) PPS: pic init qs minus26 1 ( 0) PPS: chroma qp index offset 1 ( 0) PPS: deblocking filter parameters present flag 0 ( 0) PPS: constrained intra pred flag 0 ( 0) PPS: redundant pic cnt present flag 0 ( 0) PPS: frame cropping flag 0 ( 0) 34 Annex B NALU w/ long startcode, len 4, forbidden bit 0, nal reference idc 3, nal unit type SH: first mb in slice 1 ( 0) SH: slice type ( 7) SH: pic parameter set id 1 ( 0) SH: frame num ( 0) SH: idr pic id 1 ( 0) SH: pic order cnt lsb ( 0) SH: num ref idx active override flag 1 ( 1) SH: no output of prior pics flag 0 ( 0) SH: long term reference flag 0 ( 0) SH: slice qp delta ( 4) 45 *********** Pic: 0 (I/P) MB: 0 Slice: 0 MB mode( 0, 0) = 9 1 ( Intra mode = ( Intra mode = ( Intra mode = ( -1) Intra mode = ( Intra mode = ( Intra mode = ( Intra mode = ( Intra mode = ( -1) Intra mode = ( Intra mode = ( Intra mode = ( Intra mode = ( 7) 153

169 @136 Intra mode = ( -1) Intra mode = ( Intra mode = ( Intra mode = ( Chroma intra pred mode 011 ( CBP ( 0, 0) = 47 1 ( 47) Delta QP ( 0, 0) = 0 1 ( Luma # c & tr.1s(0,0) vlc=0 #c=11 #t1= ( Luma trailing ones sign (0,0) 011 ( Luma lev (0,0) k=7 vlc=0 lev= 1 1 ( Luma lev (0,0) k=6 vlc=1 lev= ( -4) Luma lev (0,0) k=5 vlc=2 lev= ( Luma lev (0,0) k=4 vlc=3 lev= ( Luma lev (0,0) k=3 vlc=3 lev= ( Luma lev (0,0) k=2 vlc=3 lev= ( Luma lev (0,0) k=1 vlc=3 lev= ( -9) Luma lev (0,0) k=0 vlc=3 lev= ( Luma totalrun (0,0) vlc=10 totzeros= ( Luma run (0,0) k=10 vlc=2 run= 1 10 ( Luma run (0,0) k=9 vlc=1 run= 2 00 ( Luma # c & tr.1s(1,0) vlc=3 #c=8 #t1= ( 8) Luma trailing ones sign (1,0) 110 ( Luma lev (1,0) k=4 vlc=0 lev= 1 1 ( Luma lev (1,0) k=3 vlc=1 lev= ( Luma lev (1,0) k=2 vlc=1 lev= 1 10 ( Luma lev (1,0) k=1 vlc=1 lev= 1 10 ( 1) Luma lev (1,0) k=0 vlc=1 lev= ( Luma totalrun (1,0) vlc=7 totzeros= ( Luma run (1,0) k=7 vlc=5 run= ( Luma run (1,0) k=6 vlc=1 run= 0 1 ( Luma run (1,0) k=5 vlc=1 run= 0 1 ( 0) Luma run (1,0) k=4 vlc=1 run= 0 1 ( Luma run (1,0) k=3 vlc=1 run= 1 01 ( Luma run (1,0) k=2 vlc=0 run= 1 0 ( Luma # c & tr.1s(0,1) vlc=3 #c=10 #t1= ( Luma trailing ones sign (0,1) 110 ( 6) Luma lev (0,1) k=6 vlc=0 lev= ( Luma lev (0,1) k=5 vlc=1 lev= ( Luma lev (0,1) k=4 vlc=1 lev= ( Luma lev (0,1) k=3 vlc=2 lev= ( Luma lev (0,1) k=2 vlc=2 lev= ( 2) Luma lev (0,1) k=1 vlc=2 lev= (-12) 154

170 @277 Luma lev (0,1) k=0 vlc=3 lev= ( Luma totalrun (0,1) vlc=9 totzeros= 3 11 ( Luma run (0,1) k=9 vlc=2 run= 0 11 ( Luma run (0,1) k=8 vlc=2 run= 1 10 ( 1) Luma run (0,1) k=7 vlc=1 run= 1 01 ( Luma run (0,1) k=6 vlc=0 run= 0 1 ( Luma run (0,1) k=5 vlc=0 run= 0 1 ( Luma run (0,1) k=4 vlc=0 run= 0 1 ( Luma run (0,1) k=3 vlc=0 run= 0 1 ( 0) Luma run (0,1) k=2 vlc=0 run= 1 0 ( Luma # c & tr.1s(1,1) vlc=3 #c=7 #t1= ( Luma trailing ones sign (1,1) 110 ( Luma lev (1,1) k=3 vlc=0 lev= 1 1 ( Luma lev (1,1) k=2 vlc=1 lev= 1 10 ( 1) Luma lev (1,1) k=1 vlc=1 lev= 1 10 ( Luma lev (1,1) k=0 vlc=1 lev= 1 10 ( Luma totalrun (1,1) vlc=6 totzeros= ( Luma run (1,1) k=6 vlc=0 run= 1 0 ( Luma # c & tr.1s(2,0) vlc=3 #c=10 #t1= ( 10) Luma trailing ones sign (2,0) 010 ( Luma lev (2,0) k=6 vlc=0 lev= ( Luma lev (2,0) k=5 vlc=1 lev= 1 10 ( Luma lev (2,0) k=4 vlc=1 lev= ( Luma lev (2,0) k=3 vlc=1 lev= ( -2) Luma lev (2,0) k=2 vlc=1 lev= ( Luma lev (2,0) k=1 vlc=1 lev= 1 10 ( Luma lev (2,0) k=0 vlc=1 lev= ( Luma totalrun (2,0) vlc=9 totzeros= 4 10 ( Luma run (2,0) k=9 vlc=3 run= 1 10 ( 1) Luma run (2,0) k=8 vlc=2 run= 0 11 ( Luma run (2,0) k=7 vlc=2 run= 3 00 ( Luma # c & tr.1s(3,0) vlc=3 #c=5 #t1= ( Luma trailing ones sign (3,0) 0 ( Luma lev (3,0) k=3 vlc=0 lev= ( -1) Luma lev (3,0) k=2 vlc=1 lev= ( Luma lev (3,0) k=1 vlc=2 lev= ( Luma lev (3,0) k=0 vlc=2 lev= ( Luma totalrun (3,0) vlc=4 totzeros= ( Luma run (3,0) k=4 vlc=2 run= 1 10 ( 1) Luma run (3,0) k=3 vlc=1 run= 1 01 ( Luma run (3,0) k=2 vlc=0 run= 0 1 ( Luma run (3,0) k=1 vlc=0 run= 1 0 ( 1) 155

171 @382 Luma # c & tr.1s(2,1) vlc=3 #c=2 #t1= ( Luma lev (2,1) k=1 vlc=0 lev= 2 1 ( 1) Luma lev (2,1) k=0 vlc=1 lev= ( Luma totalrun (2,1) vlc=1 totzeros= ( Luma run (2,1) k=1 vlc=0 run= 1 0 ( Luma # c & tr.1s(3,1) vlc=1 #c=0 #t1=0 11 ( Luma # c & tr.1s(0,2) vlc=3 #c=1 #t1= ( 1) Luma trailing ones sign (0,2) 1 ( Luma totalrun (0,2) vlc=0 totzeros= ( Luma # c & tr.1s(1,2) vlc=2 #c=0 #t1= ( Luma # c & tr.1s(0,3) vlc=0 #c=7 #t1= ( Luma trailing ones sign (0,3) 01 ( 1) Luma lev (0,3) k=4 vlc=0 lev= ( Luma lev (0,3) k=3 vlc=1 lev= ( Luma lev (0,3) k=2 vlc=1 lev= ( Luma lev (0,3) k=1 vlc=1 lev= ( Luma lev (0,3) k=0 vlc=1 lev= ( -2) Luma totalrun (0,3) vlc=6 totzeros= ( Luma run (0,3) k=6 vlc=1 run= 2 00 ( Luma # c & tr.1s(1,3) vlc=1 #c=3 #t1= ( Luma trailing ones sign (1,3) 1 ( Luma lev (1,3) k=1 vlc=0 lev= ( -1) Luma lev (1,3) k=0 vlc=1 lev= ( Luma totalrun (1,3) vlc=2 totzeros= ( Luma run (1,3) k=2 vlc=6 run= ( Luma run (1,3) k=1 vlc=2 run= 1 10 ( Luma # c & tr.1s(2,2) vlc=0 #c=8 #t1= ( 8) Luma trailing ones sign (2,2) 100 ( Luma lev (2,2) k=4 vlc=0 lev= ( Luma lev (2,2) k=3 vlc=1 lev= ( Luma lev (2,2) k=2 vlc=1 lev= ( Luma lev (2,2) k=1 vlc=1 lev= 1 10 ( 1) Luma lev (2,2) k=0 vlc=1 lev= ( Luma totalrun (2,2) vlc=7 totzeros= ( Luma run (2,2) k=7 vlc=2 run= 0 11 ( Luma run (2,2) k=6 vlc=2 run= 0 11 ( Luma run (2,2) k=5 vlc=2 run= 3 00 ( 3) Luma # c & tr.1s(3,2) vlc=2 #c=7 #t1= ( Luma trailing ones sign (3,2) 001 ( Luma lev (3,2) k=3 vlc=0 lev= ( Luma lev (3,2) k=2 vlc=1 lev= 1 10 ( Luma lev (3,2) k=1 vlc=1 lev= 1 10 ( 1) 156

172 Luma lev (3,2) k=0 vlc=1 lev= ( Luma totalrun (3,2) vlc=6 totzeros= ( Luma run (3,2) k=6 vlc=1 run= 0 1 ( Luma run (3,2) k=5 vlc=1 run= 2 00 ( Luma # c & tr.1s(2,3) vlc=2 #c=7 #t1= ( 7) Luma trailing ones sign (2,3) 001 ( Luma lev (2,3) k=3 vlc=0 lev= ( Luma lev (2,3) k=2 vlc=1 lev= ( Luma lev (2,3) k=1 vlc=1 lev= ( Luma lev (2,3) k=0 vlc=1 lev= ( 2) Luma totalrun (2,3) vlc=6 totzeros= ( Luma run (2,3) k=6 vlc=5 run= ( Luma run (2,3) k=5 vlc=4 run= 0 11 ( Luma run (2,3) k=4 vlc=4 run= ( Luma run (2,3) k=3 vlc=0 run= 1 0 ( 1) Luma # c & tr.1s(3,3) vlc=2 #c=5 #t1= ( Luma trailing ones sign (3,3) 00 ( Luma lev (3,3) k=2 vlc=0 lev= 2 1 ( Luma lev (3,3) k=1 vlc=1 lev= ( Luma lev (3,3) k=0 vlc=1 lev= 1 10 ( 1) Luma totalrun (3,3) vlc=4 totzeros= ( Luma run (3,3) k=4 vlc=3 run= ( Luma run (3,3) k=3 vlc=0 run= 0 1 ( Luma run (3,3) k=2 vlc=0 run= 0 1 ( Luma run (3,3) k=1 vlc=0 run= 1 0 ( 1) ChrDC # c & tr.1s(0,0) vlc=0 #c=1 #t1= ( ChrDC lev (0,0) k=0 vlc=0 lev= ( ChrDC totalrun (0,0) vlc=0 totzeros= ( ChrDC # c & tr.1s(1,1) vlc=0 #c=3 #t1= ( ChrDC trailing ones sign (1,1) 0 ( 0) ChrDC lev (1,1) k=1 vlc=0 lev= ( ChrDC lev (1,1) k=0 vlc=2 lev= ( ChrDC totalrun (1,1) vlc=2 totzeros= 1 0 ( ChrDC run (1,1) k=2 vlc=0 run= 0 1 ( ChrDC run (1,1) k=1 vlc=0 run= 1 0 ( 1) ChrAC # c & tr.1s(0,4) vlc=0 #c=2 #t1=2 001 ( ChrAC trailing ones sign (0,4) 10 ( ChrAC totalrun (0,4) vlc=1 totzeros= ( ChrAC run (0,4) k=1 vlc=0 run= 0 1 ( ChrAC # c & tr.1s(1,4) vlc=1 #c=3 #t1= ( 3) ChrAC trailing ones sign (1,4) 11 ( ChrAC lev (1,4) k=0 vlc=0 lev= 2 1 ( 1) 157

173 @627 ChrAC totalrun (1,4) vlc=2 totzeros= ( ChrAC run (1,4) k=2 vlc=5 run= ( ChrAC run (1,4) k=1 vlc=0 run= 0 1 ( 0) ChrAC # c & tr.1s(0,5) vlc=1 #c=0 #t1=0 11 ( ChrAC # c & tr.1s(1,5) vlc=0 #c=0 #t1=0 1 ( ChrAC # c & tr.1s(2,4) vlc=0 #c=5 #t1= ( ChrAC trailing ones sign (2,4) 00 ( ChrAC lev (2,4) k=2 vlc=0 lev= 2 1 ( 1) ChrAC lev (2,4) k=1 vlc=1 lev= ( ChrAC lev (2,4) k=0 vlc=1 lev= 1 10 ( ChrAC totalrun (2,4) vlc=4 totzeros= ( ChrAC run (2,4) k=4 vlc=3 run= ( ChrAC run (2,4) k=3 vlc=0 run= 1 0 ( 1) ChrAC # c & tr.1s(3,4) vlc=2 #c=3 #t1= ( ChrAC lev (3,4) k=2 vlc=0 lev= 2 1 ( ChrAC lev (3,4) k=1 vlc=1 lev= ( ChrAC lev (3,4) k=0 vlc=1 lev= ( ChrAC totalrun (3,4) vlc=2 totzeros= ( 6) ChrAC run (3,4) k=2 vlc=5 run= ( ChrAC run (3,4) k=1 vlc=0 run= 0 1 ( ChrAC # c & tr.1s(2,5) vlc=2 #c=0 #t1= ( ChrAC # c & tr.1s(3,5) vlc=0 #c=0 #t1=0 1 ( 0) 249 *********** Pic: 0 (I/P) MB: 28 Slice: 0 ********** MB mode( 6, 2) = ( Chroma intra pred mode 010 ( Delta QP ( 6, 2) = 0 1 ( Lum16DC # c & tr.1s(0,0) vlc=0 #c=9 #t1= ( Lum16DC trailing ones sign (0,0) 100 ( 4) Lum16DC lev (0,0) k=5 vlc=0 lev= ( Lum16DC lev (0,0) k=4 vlc=1 lev= ( Lum16DC lev (0,0) k=3 vlc=1 lev= ( Lum16DC lev (0,0) k=2 vlc=1 lev= 1 10 ( Lum16DC lev (0,0) k=1 vlc=1 lev= 1 10 ( 1) Lum16DC lev (0,0) k=0 vlc=1 lev= ( Lum16DC totalrun (0,0) vlc=8 totzeros= 6 01 ( Lum16DC run (0,0) k=8 vlc=5 run= ( Lum16DC run (0,0) k=7 vlc=3 run= 0 11 ( Lum16DC run (0,0) k=6 vlc=3 run= 0 11 ( 0) Lum16DC run (0,0) k=5 vlc=3 run= 0 11 ( Lum16DC run (0,0) k=4 vlc=3 run= 0 11 ( 0) 158

174 @6548 Lum16DC run (0,0) k=3 vlc=3 run= 1 10 ( Lum16DC run (0,0) k=2 vlc=2 run= 1 10 ( Lum16DC run (0,0) k=1 vlc=1 run= 2 00 ( 2) Lum16AC # c & tr.1s(0,0) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(1,0) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(0,1) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(1,1) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(2,0) vlc=0 #c=0 #t1=0 1 ( 0) Lum16AC # c & tr.1s(3,0) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(2,1) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(3,1) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(0,2) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(1,2) vlc=0 #c=0 #t1=0 1 ( 0) Lum16AC # c & tr.1s(0,3) vlc=0 #c=1 #t1=1 01 ( Lum16AC trailing ones sign (0,3) 1 ( Lum16AC totalrun (0,3) vlc=0 totzeros= ( Lum16AC # c & tr.1s(1,3) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(2,2) vlc=0 #c=1 #t1=1 01 ( 1) Lum16AC trailing ones sign (2,2) 0 ( Lum16AC totalrun (2,2) vlc=0 totzeros= ( Lum16AC # c & tr.1s(3,2) vlc=0 #c=2 #t1=2 001 ( Lum16AC trailing ones sign (3,2) 10 ( Lum16AC totalrun (3,2) vlc=1 totzeros= ( 1) Lum16AC run (3,2) k=1 vlc=0 run= 0 1 ( Lum16AC # c & tr.1s(2,3) vlc=0 #c=0 #t1=0 1 ( Lum16AC # c & tr.1s(3,3) vlc=0 #c=2 #t1=2 001 ( Lum16AC trailing ones sign (3,3) 11 ( Lum16AC totalrun (3,3) vlc=1 totzeros= ( 1) Lum16AC run (3,3) k=1 vlc=0 run= 1 0 ( ChrDC # c & tr.1s(0,0) vlc=0 #c=0 #t1=0 01 ( ChrDC # c & tr.1s(1,1) vlc=0 #c=0 #t1=0 01 ( ChrAC # c & tr.1s(0,4) vlc=0 #c=0 #t1=0 1 ( ChrAC # c & tr.1s(1,4) vlc=0 #c=0 #t1=0 1 ( 0) ChrAC # c & tr.1s(0,5) vlc=0 #c=2 #t1=2 001 ( ChrAC trailing ones sign (0,5) 01 ( ChrAC totalrun (0,5) vlc=1 totzeros= ( ChrAC run (0,5) k=1 vlc=0 run= 0 1 ( ChrAC # c & tr.1s(1,5) vlc=0 #c=0 #t1=0 1 ( 0) ChrAC # c & tr.1s(2,4) vlc=0 #c=0 #t1=0 1 ( ChrAC # c & tr.1s(3,4) vlc=0 #c=0 #t1=0 1 ( ChrAC # c & tr.1s(2,5) vlc=0 #c=0 #t1=0 1 ( ChrAC # c & tr.1s(3,5) vlc=0 #c=0 #t1=0 1 ( 0) 159

175 309 Annex B NALU w/ long startcode, len 2272, forbidden bit 0, nal reference idc 3, nal unit type SH: first mb in slice 1 ( SH: slice type ( SH: pic parameter set id 1 ( SH: frame num ( SH: pic order cnt lsb ( 4) SH: num ref idx active override flag 1 ( SH: num ref pic active fwd minus1 1 ( SH: ref pic list reordering flag l0 0 ( SH: adaptive ref pic buffering flag 0 ( SH: slice qp delta ( 6) 320 *********** Pic: 2 (I/P) MB: 0 Slice: 0 MB runlength = 0 1 ( MB mode( 0, 0) = ( 8x8 mode/pdir( 0) = 4/0 1 ( 8x8 mode/pdir( 1) = 4/0 1 ( 0) 8x8 mode/pdir( 2) = 6/0 011 ( 8x8 mode/pdir( 3) = 4/0 1 ( FMVD(0) = 0 (org mv 0 pred mv 0) 0 1 ( FMVD(1) = 0 (org mv 0 pred mv 0) 3 1 ( FMVD(0) = 0 (org mv 0 pred mv 0) 0 1 ( 0) FMVD(1) = 0 (org mv 0 pred mv 0) 2 1 ( FMVD(0) = 0 (org mv 0 pred mv 0) 2 1 ( FMVD(1) = 0 (org mv 0 pred mv 0) 3 1 ( FMVD(0) = -3 (org mv -3 pred mv 0) ( FMVD(1) = 2 (org mv 2 pred mv 0) ( 2) FMVD(0) = -2 (org mv -2 pred mv 0) ( FMVD(1) = 1 (org mv 1 pred mv 0) ( CBP ( 0, 0) = 0 1 ( 0) 338 *********** Pic: 2 (I/P) MB: 1 Slice: 0 MB runlength = 0 1 ( 0) MB mode( 1, 0) = ( FMVD(0) = 0 (org mv 0 pred mv 0) 1 1 ( 0) 160

176 @18307 FMVD(1) = 0 (org mv 0 pred mv 0) 0 1 ( FMVD(0) = -1 (org mv -3 pred mv -2) ( FMVD(1) = 1 (org mv 2 pred mv 1) ( 1) CBP ( 1, 0) = 0 1 ( 0) 346 *********** Pic: 2 (I/P) MB: 2 Slice: 0 ********** 347 *********** Pic: 2 (I/P) MB: 3 Slice: 0 ********** 348 *********** Pic: 2 (I/P) MB: 4 Slice: 0 ********** 349 Annex B NALU w/ long startcode, len 421, forbidden bit 0, nal reference idc 2, nal unit type SH: first mb in slice 1 ( SH: slice type ( SH: pic parameter set id 1 ( SH: frame num ( SH: pic order cnt lsb ( 2) SH: direct spatial mv pred flag 1 ( SH: num ref idx active override flag 1 ( SH: num ref pic active fwd minus1 1 ( SH: num ref pic active bwd minus1 1 ( SH: ref pic list reordering flag l0 0 ( 0) SH: ref pic list reordering flag l1 0 ( SH: adaptive ref pic buffering flag 0 ( SH: slice qp delta ( 6) 363 *********** Pic: 1 (I/P) MB: 0 Slice: 0 ********** 364 *********** Pic: 1 (I/P) MB: 1 Slice: 0 ********** 365 *********** Pic: 1 (I/P) MB: 2 Slice: 0 ********** 366 *********** Pic: 1 (I/P) MB: 27 Slice: 0 ********** MB runlength = ( B MB mode( 5, 2) = ( FMVD(0) = -15 (org mv -15 pred mv 0) FMVD(1) = 5 (org mv 5 pred mv 0) ( 5) 161

177 @21705 CBP ( 5, 2) = 0 1 ( 0) 372 *********** Pic: 1 (I/P) MB: 40 Slice: 0 MB runlength = ( B MB mode( 7, 3) = ( 3) FMVD(0) = 0 (org mv -7 pred mv -7) 1 1 ( FMVD(1) = 1 (org mv 3 pred mv 2) ( BMVD(0) = 9 (org mv 9 pred mv 0) ( BMVD(1) = -1 (org mv -2 pred mv -1) 011 ( CBP ( 7, 3) = 0 1 ( 0) 380 Annex B NALU w/ long startcode, len 80, forbidden bit 0, nal reference idc 0, nal unit type SH: first mb in slice 1 ( SH: slice type ( SH: pic parameter set id 1 ( SH: frame num ( 2) SH: pic order cnt lsb ( SH: num ref idx active override flag 1 ( SH: num ref pic active fwd minus1 1 ( SH: ref pic list reordering flag l0 0 ( SH: adaptive ref pic buffering flag 0 ( 0) SH: slice qp delta ( 7) 391 *********** Pic: 4 (I/P) MB: 0 Slice: 0 ********** 392 Annex B NALU w/ long startcode, len 458, forbidden bit 0, nal reference idc 2, nal unit type SH: first mb in slice 1 ( SH: slice type ( 6) SH: pic parameter set id 1 ( SH: frame num ( SH: pic order cnt lsb ( SH: direct spatial mv pred flag 1 ( SH: num ref idx active override flag 1 ( 1) 162

178 SH: num ref pic active fwd minus1 1 ( SH: num ref pic active bwd minus1 1 ( SH: ref pic list reordering flag l0 0 ( SH: ref pic list reordering flag l1 0 ( SH: adaptive ref pic buffering flag 0 ( 0) SH: slice qp delta ( 8) 406 *********** Pic: 3 (I/P) MB: 0 Slice: 0 ********** 407 Annex B NALU w/ long startcode, len 65, forbidden bit 0, nal reference idc 0, nal unit type 1 163

179 Bijlage D Figuren PSNR-vergelijking foreman Y-PSNR (db) Bitsnelheid (kbps) XviD VSS H.264 JVT/AVC DivX 5.04 WMV9 Figuur D.1: Vergelijking prestatie codecs (foreman) 164

180 PSNR-vergelijking stefan Y-PSNR (db) Bitsnelheid (kbps) XviD VSS H.264 JVT/AVC DivX 5.04 WMV9 Figuur D.2: Vergelijking prestatie codecs (stefan) 165

181 originele sequentie sequentie DivX 2100 kbps Figuur D.3: Beelden 180 tot en met 185 uit de originele sequentie en de gecodeerde sequentie met DivX 5.04 tegen 2100 kbps (stefan) 166