Ontwerp van videostreamer voor geavanceerde MPEG-4 video

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Ontwerp van videostreamer voor geavanceerde MPEG-4 video door Kristof DEPYPERE Promotoren: Prof. dr. ir. I. MOERMAN en Prof. dr. ir. F. DE TURCK Scriptiebegeleiders: ir. P. DE NEVE en ir. J. BATEN Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

2 Voorwoord Het laatste jaar en de daarbij komende voltooing van deze thesis is zo snel voorbijgevlogen dat we van deze gelegendheid gebruik maken om toch even stil te staan om enkele dankwoorden te uitten. Vooreerst zou ik graag mijn ouders willen danken voor de financiële en morele steun tijdens de studentenjaren. Zonder hun steun zou dit nooit mogelijk zijn geweest. Ik wil hen ook bedanken omdat ze mij steeds hebben vrijgelaten in de keuzes die ik de voorbije jaren heb moeten maken, waardoor ik mijn eigen weg heb kunnen volgen. Ook mijn begeleider Philippe zou ik willen bedanken voor de hulp doorheen het jaar en bij het uitvoeren van de evaluaties. De aangename manier van werken en de nuttige commentaren op de thesistekst hebben deze thesis er alleen maar beter op gemaakt. Verder zou ik nog enkele vrienden willen bedanken voor hun duidelijk interesse en steun bij het tot stand komen van deze thesis. Ook mijn vriendin wil ik bij deze bedanken die mij het voorbije jaar veel heeft gesteund en mijn verminderde aanwezigheid in haar dagelijkse activiteiten met veel begrip heeft aanvaard. Kristof Depypere, juni 2006

3 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. Kristof Depypere, juni 2006

4 Ontwerp van video streamer voor geavanceerde MPEG-4 video door Kristof DEPYPERE Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar Promotoren: Prof. dr. ir. I. MOERMAN en Prof. dr. ir. F. DE TURCK Scriptiebegeleiders: ir. P. DE NEVE en ir. J. BATEN Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Samenvatting In dit eindwerk ontwikkelen we een videostreamer voor de H.264/AVC codec. Deze videostreamer is ontwikkeld voor gebruik in een wetenschappelijke omgeving en bevat verscheidene instelbare parameters. Zo ondersteunt de videostreamer de twee belangrijkste pakketizatiemodi en een instelbare pakketgrootte bij het verzenden van de H.264 video. Er wordt gebruik gemaakt van het RTSP protocol om videobestanden aan te vragen en voor het verzenden van de video zelf, gebruiken we het RTP protocol. De applicatie is ontwikkeld in Java om platformonafhankelijkheid te garanderen. Na de ontwikkeling van de videostreamer, wordt deze reeds gebruikt om metingen uit te voeren tijdens het streamen. De H.264 codec staat nog maar in zijn kinderschoenen zodat er nog veel onderzoek moet gebeuren naar de huidige performantie en nog mogelijke verdere optimalisaties. Aangezien er ook nog maar weinig geweten is over de invloed van pakketverlies op de kwaliteit van de video, hebben we de ontvangen kwaliteit van de H.264 video vergeleken onder pakketverlies en met verschillende parameters zoals pakketgrootte, bitrate en grootte van de video. Trefwoorden H.264, AVC, videostreamer, pakketverlies, RTSP, RTP

5 Development of a videostreamer for advanced MPEG-4 video Kristof Depypere Supervisor(s): Prof. dr. ir. I. MOERMAN and Prof. dr. ir. F. DE TURCK Abstract This article explains the design of a videostreamer for the H.264/AVC[1] codec. We develop a streamer for academic purposes only that makes uses of the RTP[2] and RTSP[3] protocol to deliver the videostreams. The streamer also has to be adjustable with different parameters, so that it can be used to test the performance of the H.264/AVC codec. We also explain some results we got by using the developed videostreamer to test the quality of a received videosequence at different amounts of packetloss. Keywords H.264, AVC, videostreamer, packetloss, RTSP, RTP I. INTRODUCTION The H.264/AVC is a videocodec that uses a collection of the newest technologies and is able to encode a videosequence with up to 4 times the framesize at the same bitrate, comparing to MPEG4-part 2 generation codecs such as DivX and Xvid. The codec is very recent and doesn t have a rich history of research and testing funding it. One can expect many changes and improvements during the years. There aren t much videostreamers that support the H.264/AVC codec, and if they do, they don t allow to adjust the streaming process with different parameters. That s why we develop a videostreamer that supports the H.264/AVC codec and that is adjustable with different parameters. There also isn t much information on the influence of packetloss on the quality of a videosequence. After the development of the videostreamer we are going to do some qualitytests. We use the videostreamer to get some results of the influence of packetloss on the quality of the video while adjusting the framesize, packetsize and bitrate. A. Requirements II. DEVELOPING A VIDEOSTREAMER The videostreamer is to be used in a scientific environment. This means that besides the functionality, the videostreamer needs to have some additional property s to be rendered useful: Platform independence: If we can make sure that the streamer can be used on any platform, it can considerably increase it s useability. In a scientific environment different platforms are frequently used at once. Being able to use the videostreamer on all of these platforms is a huge benefit. That s why we choose to develop the videostreamer in Java. Java is a programming language that is able to ensure platform indepence. The major drawback of Java is that it is an interpreted language, mening that it isn t very performant. Because performance isn t as critical as a usable system, Java is a good choice to make. K. Depypere is with the Civil Engineering Department, Ghent University (UGent), Gent, Belgium. Fig. 1. NAL unit header Readability: It is very likely that in a scientific environment the videostreamer needs to be adjusted. To realize this, we choose to write code that is easy to understand, but perhaps a little less performant. We also make sure there are enough comments in the code to help programmers understand the structure and the functionality of the methods and classes. Extensibility: It is also important to create a videostreamer with a clear structure that allows a programmer to write extended functionality with the least possible amount of adjustments. A clear documentation can also help to accomplish this property. B. The H.264/AVC codec The design of the H.264/AVC codec covers two different layers[4]. A Video Coding Layer (VCL), which efficiently represents the video content, and a Network Abstraction Layer (NAL), which formats the VCL representation of the video and provides header information in a manner appropriate for conveyance by particular transport layers or storage media. The NAL layer divides the videodata in different NAL units, which are the units that are used to packetize the videostream to send over a packet-oriented network. A NAL unit consists of a header and a payload. Figure 1 shows the structure of the NAL unit header: F: 1 bit forbidden zero bit. The H.264 specification declares a value of 1 as a syntax violation. NRI: 2 bits nal ref idc. A value of 00 indicates that the content of the NAL unit is not used to reconstruct reference pictures for inter picture prediction. Such NAL units can easily be discarded. Values greater than 00 indicate that the decoding of the NAL unit is required to maintain the integrity of the reference pictures. Type: 5 bits nal unit type. This component specifies the NAL unit payload type C. Packetization Modes RFC 3984[5] defines three different packetization modes for H.264/AVC video. We have only implemented the first two (more useful) packetization modes: The single NAL unit mode and the non-interleaved mode. The single NAL unit mode is

6 only able to send one single NAL Unit in each packet. The header of the NAL unit serves as the header of the payload in the RTP packet. The single NAL Unit packetization mode is targeted for low latency conversational systems. The non-interleaved mode is able to ensure a maximum packetsize by dividing NAL units that are too big in fragmentation unit packets and by aggregating multiple NAL units in one single-time aggregation packet. Packets with a single NAL unit are also still possible. The NAL units have to be send in decoding order, which is a limitation that the third, non-implemented packetization mode, doesn t have anymore. A fragmentation unit can only contain a part of one NAL unit. A single-time aggregation packet can only contain NAL units that have the same display time, hence the name single-time. All the NAL units in the packet need to be part of the same frame, other NAL units aren t allowed in the same packet. D. Parameters To configure the videostreamer we define three different parameters: Packetization Mode: The user can choose between the single NAL unit mode and the non-interleaved packetization mode. Video Directory: The directory that contains the video s that can be requested to be streamed via the RTSP protocol. Maximum Packetsize: If the streamer uses the noninterleaved packetization mode, it makes sure the packets don t exceed the value defined by the maximum packetsize. If the streamer is in the single NAL unit packetization mode, this value is ignored. III. TESTRESULTS We measured the videoquality after sending the video over a network with packetloss using 4 different measures: PSNR, JND, SSIM and Blocking Measure. PSNR: Peak signal-to-noise ratio. One of the most frequently used quality metrics. JND: Just Noticable Difference. This metric measures the difference in quality as seen by a human observer. It uses specific characteristics of the human eye to determine the values. SSIM: Structural Similarity. This metric is based on measuring three components and combining them into one value (luminance, structure and contrast). Blocking Measure: determines the amount of blocking there is in an image. We varied some parameters of the video to obtain a wide range of results. We changed the framesize, packetsize and bitrate of the video and compared the values of the different measures. The average values of the PSNR and the JND measure are summarized in tables I and II. We could derive from the results that a higher bitrate and a smaller packetsize give poorer quality at the same amount of packetloss. This is probably because of the H.264/AVC codec that has more difficulties decoding a frame with few lesser pieces missing than one big piece. A lower framesize doesn t influence the quality substantially. The lower framesize gave slightly better JND values. This is probably because of the characteristics of the human eye that is less sensitive for higher spatial frequenties, hence smaller framesizes. An error that is packetsize 1492 B 1492 B 1492 B 773 B framesize 416x x x x224 bitrate 512 Kbps 768 Kbps 512 Kbps 512 Kbps 0,05% 42, , , ,296 0,10% 36, , , ,6218 0,50% 30, , , ,9778 1% 23, , , ,0329 TABLE I OVERVIEW AVERAGE PSNR VALUES AT DIFFERENT PACKETLOSS RATES packetsize 1492 B 1492 B 1492 B 773 B framesize 416x x x x224 bitrate 512 Kbps 768 Kbps 512 Kbps 512 Kbps 0,05% 2,9 4,008 2,355 4,425 0,10% 4,494 5,001 2,947 4,351 0,50% 5,824 6,119 4,805 6,765 1% 6,998 7,391 4,986 7,587 TABLE II OVERVIEW AVERAGE JND VALUES AT DIFFERENT PACKETLOSS RATES equally big but in a smaller framesize is less likely to be noticed. IV. CONCLUSIONS In this article we described the major designing issues we had during the development of a videostreamer for the H.264/AVC codec. We explained the structure of the NAL layer of the codec and described the different packetization modes that are used in the streamer. Furthermore we presented some results of the qualitytest of video after sending it over a network suffering from an amount of packetloss. We concluded that a higher bitrate and lower packetsize have a negative impact on the quality and that the framesize has hardly any influence. REFERENCES [1] Draft itu-t recommendation and final draft international standard of joint video specification (itu-t rec. h.264 iso/iec avc), 03_Pattaya/JVT-G050r1.zip, May [2] H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson, Rtp: A transport protocol for real-time applications, RFC: 3550, July [3] R. Lanphier H. Schulzrinne, A. Rao, Real time streaming protocol (rtsp), February [4] Thomas Wiegand Ralf Schafer and Heiko Schwarz, The emerging h.264/avc standard,. [5] S. Wenger; M.M. Hannuksela; T. Stockhammer; M. Westerlund; D. Singer, Rtp payload format for h.264 video, RFC: 3984, February 2005.

7 INHOUDSOPGAVE i Inhoudsopgave Lijst van afkortingen iii 1 Inleiding Situering Doelstelling Overzicht Relevante Technologiën De H264/AVC Codec De videocodeerlaag De netwerkabstractielaag Real-time Transport Protocol Inleiding Structuur van de hoofding RTP payload formaat voor H.264 video Algemene structuur Gebruik van de RTP hoofding Pakketizatie modi Real-time Streaming Protocol Inleiding Werking Session Description Protocol De videostreamer Algemene Vereisten Functionaliteit

8 INHOUDSOPGAVE ii Belangrijke Eigenschappen Bruikbare Bibliotheken Java Media Framework Java RTP Ontwerp VideoStreamer Invoer en Interne Buffering Pakketizeren Overdracht via RTP protocol Overige functionaliteit Bespreking verzonden berichten tussen klant en server Evaluatie Inleiding Testopstelling Testmethode Testconfiguraties Metrieken Evaluatie AVCStreamer Resultaten Invloed van bitrate Invloed van beeldgrootte Invloed Pakketgrootte Besluit Conclusies Uitbreidingen A Inhoud van de CD-ROM 70

9 LIJST VAN AFKORTINGEN iii Lijst van afkortingen AVC API DCT HTML IEC IETF IP ISO ITU-T JMF JND JPEG JVT MPEG NAL PSNR RFC RTP RTCP RTSP SSIM TCP UDP VCL Advanced Video Codec Application Programming Interface Discrete Cosine Transform HyperText Markup Language International Electrotechnical Commission Internet Engineering Task Force Internet Protocol International Organization for Standardization International Telecommunication Union - Telecommunications Java Media Framework Just Noticable Difference Joint Photographic Experts Group Joint Video Team Moving Pictures Expert Group Network Abstraction Layer Peak Signal-to-noise Ratio Request For Common Real-time Transport Protocol Real-time Transport Control Protocol Real-time Streaming Protocol Structural Similarity Transmission Control Protocol User Datagram Protocol Video Coding Layer

10 INLEIDING 1 Hoofdstuk 1 Inleiding Dit hoofdstuk is een inleiding op de rest van de thesistekst. In de eerste sectie situeren we de thesis en in de tweede sectie komt de doelstelling van de thesis aan bod. Tot slot geven we een overzicht van de verschillende hoofdstukken. 1.1 Situering MPEG-4 is een multimedia standaard vooral voor audio en video. Het is gedefinieerd door het MPEG (Moving Pictures Experts Group) committee, die ook bekend staan omwille van de MPEG-1 en MPEG-2 standaarden die beiden Awards gewonnen hebben. MPEG-4 is een uitbreiding van MPEG-1 om video/audio-objecten te ondersteunen, 3D-inhoud, lage bitrate-encoding en DRM (Digital Rights Management). MPEG-4 werd ontworpen om een naadloze levering van audio en video van hoge kwaliteit aan een nieuwe generatie van multimedia toestellen, over het internet en over andere ip-gebaseerde netwerken te garanderen. Deze toestellen variëren van narrowband gsm toestellen tot breedband High Definition (HD) televisies. MPEG-4 voorziet audio en video van hoge kwaliteit gespreid over het hele bandbreedte spectrum. Als bestandsformaat koos de Motion Picture Experts Group voor het Quicktime bestandsformaat, ontwikkeld door Apple. Dit was niet naar de zin van Microsoft die graag hun eigen bestandsformaat in de ISO had zien opnemen, waarop zij prompt op de proppen kwamen met een eigen versie van MPEG- 4. Het is overigens op deze (gesloten en incompatibele) Microsoft-variant van MPEG-4 dat het populaire DivX en Xvid gebaseerd werden. In 2001 hebben de ITU-T Video Coding Experts Group (VCEG) de ISO/IEC Moving Picture Experts Group(MPEG) het Joint Video Team (JVT) opgericht om te werken aan een nieuwe

11 1.2 Doelstelling 2 geavanceerde videocodec 1. Deze codec kreeg als algemene benaming Advanced Video Codec (AVC). Daarnaast gaven de twee groepen afzonderlijk ook hun eigen naam, namelijk H.264 voor de ITU-T groep en MPEG-4 Part 10 voor de ISO/IEC groep. De H.264 codec is enkel een referentie en softwareleveranciers kunnen dus hun eigen codecs en bijhorende encoders ontwikkelen. Enkele voorbeelden hiervan zijn Apple en 3ivx. De H.264 videostandaard is een kluwen van de laatst nieuwe technieken op het gebied van video compressie die samen een sterke vooruitgang boeken ten opzichte van vorige generaties videostandaarden. H.264 levert bijvoorbeeld dezelfde kwaliteit als MPEG-2 maar met een derde tot de helft van de data rate. Wanneer we de videostandaard vergelijken met MPEG-4 Part 2, levert H.264 tot vier keer de framegrootte bij een gegeven data rate. De H.264 videostandaard staat echter nog maar in zijn kinderschoenen. Gebruikers mogen nog vele jaren verbeteringen verwachten aan deze standaard. Daarom is het ook nodig om voldoende onderzoek te verrichten naar de standaard en daarop ook voldoende metingen en testen te doen. 1.2 Doelstelling Zoals we daarnet al aanhaalden is H.264 nog maar in een heel vroeg stadium van de ontwikkeling. Er bestaan nog niet veel videostreamers die deze codec ondersteunen. En als er al streamers bestaan, laten ze vaak niet toe om verschillende parameters in te stellen. De H.264 codec zelf is ook nog niet uitgebreid getest. Over de impact van van pakketverlies op de kwaliteit van de video is nog steeds niet veel geweten. De doelstelling van deze thesis bestaat uit twee delen. Eerst gaan we een streamer ontwerpen met als doel de H.264 standaard te testen en metingen uit te voeren. Het is dus belangrijk om de streamer platformonafhankelijk te maken en om deze met verschillende parameters instelbaar te maken. In een tweede fase gaan we enkele metingen uitvoeren die het gedrag van de H.264 video onder invloed van pakketverlies beschrijven. De evaluatie van de metingen staat beschreven in hoofdstuk 4. 1 codeerder/decodeerder

12 1.3 Overzicht Overzicht We beginnen in hoofdstuk 2 met een bespreking van de relevante technologiën. We bespreken daar achtereenvolgens de H.264/AVC codec, het RTP protocol, het payload formaat voor het verzenden van H.264/AVC video via het RTP protocol, het RTSP protocol en het SDP protocol. Vervolgens bespreken we in hoofdstuk 3 het ontwerp van de videostreamer. We bespreken daar eerst enkele algemene vereisten waarna we nog enkele bruikbare bibliotheken toelichten. Tot slot lichten we dan het ontwerp van de streamer toe. Daarna gaan we in hoofdstuk 4 de invloed van pakketverlies evalueren. We geven daar eerst een beschrijving in sectie 4.1 van de testopstelling, testmethode, testconfiguratie en de gebruikte metrieken. Daarna gaan we in sectie 4.2 kort de geschreven videostreamer zelf evalueren. Tot slot bespreken we de resultaten van de metingen bij pakketverlies met een verschillende bitrate, beeldgrootte en pakketgrootte in sectie 4.3. In hoofdstuk 5 besluiten we deze thesis met enkele conclusies en mogelijke uitbreidingen.

13 RELEVANTE TECHNOLOGIËN 4 Hoofdstuk 2 Relevante Technologiën 2.1 De H264/AVC Codec Video in zijn ongecomprimeerde vorm kan heel groot zijn. Medische beelden die gebruik worden voor bloedvatenonderzoek hebben al snel een grootte van 120 MB, en dit voor slechts 20 seconden beeld. Grote hoeveelheden videodata zijn niet alleen moeilijk op te slaan, maar zijn ook moeilijk te verzenden over een publiek netwerk. Een sterke compressie van de videodata is daarom noodzakelijk. In dit hoofdstuk geven we een overzicht van de gebruike technieken bij de compressie van beelden met de H.264 videostandaard. H.264 is een blokgebaseerd, beweginggecompenseerde videocompressie methode. Het is ontworpen om schaalbaar te zijn, dit wil zeggen dat de efficiëntie ongeveer gelijk blijft voor alle doeleinden, of dit nu een videostroom is met lage bandbreedte of een High Definition broadcast. Een overzicht van de architectuur van de H.264 videostandaard vindt u in afbeelding 2.1. De codec specificatie [8] onderscheidt conceptueel tussen een videocodeerlaag (VCL) een een netwerkabstractielaag (NAL) De videocodeerlaag De VCL laag bevat de functionaliteit voor de signaalverwerking. Verschillende mechanismen zoals transformaties, kwantisatie, en bewegingsgecompenseerde predictie zitten hierin onder andere vervat. Het volgt de grote lijnen van de hedendaagse video codecs, een macroblok gebaseerde codeerder dat gebruik maakt van predictie tussen de verschillende beelden waarbij er bewegingscompensatie wordt gebruikt en er daarna transformatie codering wordt toegepast op het resterende signaal.

14 2.1 De H264/AVC Codec 5 Figuur 2.1: Overzicht van de architectuur De VCL codeerder[4] heeft slices als uitvoer, een bitstring dat de gegevens van een geheel aantal macroblokken bevat. Een macroblok is de basis van een beeld en bevat 16x16 pixels. Elke slice bevat ook een hoofding met het adres van het eerste macroblok in de slice, de initiële kwantisatie parameter en gelijkaardige informatie. De macroblokken in de slices zijn geschikt volgens scan volgorde, tenzij er een andere volgorde is gespecifieerd door gebruik te maken van de zogenaamde Flexibele Macroblok Volgorde Syntax. Predictie binnen de afbeeldingen zelf wordt enkel gebruikt binnen de slices. Deze slices vormen aldus de kleinste onafhankelijk decodeerbare dataeenheid. De slices bevatten op hun beurt een deel van een video frame. Als we verschillende slices samennemen dan krijgen we dus een volledig beeld van de video. Bij het encoderen van kleurenbeelden, gebruikt H.264 evenals zijn voorgangers de YCbCr kleurenruimte die een beeld opsplitst in een luminantie (helderheid) en chrominantie (kleur). Voor elke vier luminantiewaarden zijn er echter slechts 2 chrominantiewaarden. Deze bemonstering van het oorspronkelijke beeld wordt aangeduid met 4:2:0. Men houdt hier rekening met de eigenschappen van het menselijk oog dat veel gevoeliger is voor luminantie dan voor chrominantie. Slice types H.264 definieert vijf verschillende slice types: I, P, B, SI en SP. I slices of Intra slices beschrijven een volledig stilstaand beeld dat alleen referenties naar

15 2.1 De H264/AVC Codec 6 Figuur 2.2: H.264 Blok Diagram zichzelf bevat. Een videostroom kan alleen uit I slices bestaan, maar dit wordt typisch niet gebruikt. Het eerste frame van een video sequentie moet altijd bestaan uit I slices. P slices of Predicted slices gebruiken één of meer reeds gedecodeerde slices als referentie voor het construeren van de afbeelding. De voorspelling is meestal niet exact hetzelfde als de originele afbeelding, zodat er een residu kan toegevoegd worden. B slices of Bi-Directional Predicted slices werken gelijkaardig aan een P slice met dat verschil dat zowel de voorgaande I slice als de volgende P slice (in afspeelvolgorde) gebruikt worden als referentie voor de voorspelling. Opdat dit zou werken moeten B slices gedecodeerd worden nadat de I en P slices gedecodeerd zijn. SI en SP slices of Switching slices kunnen gebruikt worden voor de transitie tussen twee verschillende H.264 videostromen. Deze worden zeer zelden gebruikt. In figuur 2.2[11] zien we de verschillende stappen die uitgevoerd worden bij het compresseren van video in de videocodeerlaag. We gaan deze verschillende stappen even kort bespreken. De basis functionaliteit van het H.264 beeldencoderingsproces is als volgt: Voor elk macroblok wordt de afbeeldingsdata afgetrokken van de voorspelling. Het resultaat wordt dan getransformeerd. De coëfficiënten van deze transformatie worden gedeeld door een constant geheel getal. Deze procedure wordt kwantisatie genoemd. Het is de enige stap in het hele encodeerproces dat verlies introduceert. De deler die gebruikt wordt, noemt men de kwantisatie parameter. De

16 2.1 De H264/AVC Codec 7 gekwantiseerde coëfficiënten worden dan geëncodeerd met behulp van een geavanceerde entropie codering (verliesloos). In de decoder worden deze stappen in omgekeerde volgorde uitgevoerd. Inter/Intra Predictie Bij inter/intra predictie gaat men pixelwaarden voorspellen op basis van naburige pixels en op basis van pixels uit voorgaande beelden. Als men de voorspelde waarde aftrekt van de originele waarde dan verkrijgt men een waarde die veel kleiner is. Predictie wordt bijgestaan door bewegingscompensatie. Men gaat dan rekening houden met de beweging van een object van beeld op beeld zodat men een veel preciesere predictie krijgt en dus een veel kleinere uiteindelijke waarde. Om een beweging van een object voor te stellen gebruikt men bewegingsvectoren. Bewegingsvectoren moeten geen gehele waarden hebben: in H.264 is de nauwkeurigheid één-kwart pixel. Omdat naburige macroblokken de neiging hebben om in dezelfde richting te bewegen, worden bewegingsvectoren ook geëncodeerd met voorspellingen. Als de bewegingsvector van een blok geëncodeerd wordt, worden de bewegingsvectoren van de naburige blokken gebruikt om de huidige bewegingsvector te voorspellen. Daarna wordt enkel het verschil tussen de voorspelling en de huidige bewegingsvector opgeslagen. 4x4 Integer Transformatie Na de aftrek van de afbeeldingsdata van de voorspelde waarde, wordt een transformatie uitgevoerd op het resultaat. Het doel van een transformatie is om de data om te zetten naar een vorm die veel geschikter is voor entropie codering. In H.264 is de manier van werken gelijkaardig aan dat van JPEG en MPEG, maar de gebruikte transformatie is geen 8x8 Discrete Cosinus Transformatie (DCT), maar een 4x4 integer transformatie die afgeleid is van de DCT. Deze transformatie is heel gemakkelijk en snel. Het kan berekend worden door enkel optellingen/aftrekkingen en binaire verschuivingen. Het deelt de afbeelding op in zijn spatiale frequentie componenten zoals DCT, maar door zijn kleinere grootte, is het niet zo vatbaar voor hoogfrequente artefacten zoals zijn voorgangers. Een macroblok B wordt getransformeerd naar B met behulp van de volgende formule. De noodzakelijke schalingsstap is geïntegreerd in de kwantisatie en wordt achterwege gelaten.

17 2.1 De H264/AVC Codec 8 M = (2.1) B = MBM T (2.2) Entropie encodering Het principe van entropie encodering is om veel voorkomende symbolen voor te stellen met een kleine bitstring en minder voorkomende symbolen met een (noodgedwongen) langere string. Op deze manier kan men data een heel stuk verkleinen. Als er weinig symbolen zijn die heel veel voorkomen, dan bereikt men het beste resultaat. Uit de geëncodeerde bitstring kan men zonder verlies de oorspronkelijke bitstring herconstrueren. H.264 ondersteunt twee verschillend entropie coderingsmodi: Context-Adaptive Variable Length Coding (CAVLC) is de standaard methode en Context-Adaptive Binary Arithmetic Coding (CABAC), een optioneel en hoog efficiënt binair encoderingsschema. Geavanceerde codeer hulpmiddelen Naast de algemene structuur die hierboven beschreven werd, biedt H.264 nog andere technieken om de codeerefficiëntie te verhogen. In-Loop Deblocking Filter. Nadat elk individueel frame is gedecodeerd, reduceert een deblocking filter de meest storende blok artefacten. Dit is reeds beschikbaar sinds MPEG-4 Simple Profile als een optionele post-processing stap, maar in H.264 is het sterk geïntegreerd in het encoderings- en decoderingsproces: De frames waardat de blok artefacten reeds verwijderd zijn, worden gebruikt als referentieframes door de volgende P of B slices. Deze techniek omzeilt storende blok artefacten zo goed mogelijk. Figuur 2.3 toont de werking van de deblocking filter. Geavanceerde voorspelling. H.264 kan niet alleen referenties gebruiken naar het laatst gedecodeerde frame, maar naar een willekeurig aantal frames. Dit verhoogt drastisch de encodeerefficiëntie van periodieke bewegingen (long-term voorspelling). Daarbij komt nog dat verschillende voorspellingen kunnen gemixed worden door willekeurige ratios (gewogen voorspelling).

18 2.1 De H264/AVC Codec 9 Figuur 2.3: Voorbeeld van de werking van de deblocking filter. Links: zonder filter en Rechts: met filter Willekeurige slice ordening. Aangezien de slices van een beeld onafhankelijk gedecodeerd kunnen worden (met uitzondering van de slice randen die enkel benaderd kunnen worden), moeten slices niet gedecodeerd worden in de juiste volgorde om een beeld te renderen in een aanvaardbare kwaliteit. Dit is bijvoorbeeld nuttig bij het streamen over UDP waar pakketen out-of-order kunnen afgeleverd worden. Flexibele Macroblok ordening De macroblokken binnen een slice kunnen geëncodeerd worden in een willekeurige volgorde. Dit kan bijvoorbeeld gebruikt worden om de robuustheid tegen transmissiefouten te verhogen. Het herinnert ook aan het Video object planes systeem van MPEG-4 dat gebruikt kan worden om elk object van een scène individueel te encoderen. In normale videostromen wordt deze techniek niet gebruikt, en worden macroblokken in normale volgorde verzonden. Conclusie De videocodeerlaag van de H.264 codec bevat veel nieuwe geavanceerde technieken. De H.264 laat zijn voorgangers op deze manier ver achter zich omdat er niet enkel verbeteringen zijn aangebracht op 1 onderdeel, maar omdat alle aparte onderdelen werden verbeterd en verfijnd. In wat volgt geven we een aantal voorbeelden van de verschillende verbeteringen die zijn aangebracht[1]: Geavanceerde B-frame ondersteuning. Met H.264 kan een B-frame refereren naar een groot aantal frames, om het even waar in de tijdslijn van de video. Traditioneel kon dit enkel naar het frame vlak voor en vlak na het B-frame. Verder kan een B-frame ook

19 2.1 De H264/AVC Codec 10 gebruikt worden om een ander frame te beschrijven, zodat het met andere woorden ook een referentieframe kan zijn, wat niet het geval is bij vroegere codecs. Dit alles laat toe om meer efficiënt te coderen. 4x4 integer transformatie. H.264 is ontworpen om te werken op veel kleinere blokken van pixels dan andere codecs. Zo blijft de H.264 helderder zelfs in gebieden met veel detail. De transformatie die gebruikt wordt is een integer transformatie waardoor de reconstructie bitnauwkeurig blijft in tegenstelling tot vorige codecs waarbij de reconstructie statistisch gegenereerd werd. Verhoogde nauwkeurigheid bij bewegingscompensatie. Er wordt nu met een precisie van 1/4 pixel resolutie gewerkt in plaats van vroeger met een 1/2-pixel resolutie. Bewegende object kunnen veel preciezer afgelijnd worden dan vroeger. Flexibele blokgroottes bij bewegingscompensatie. In vroegere codecs werd er altijd gewerkt met blokgrootten van 16x16 pixels. In de H.264 is het mogelijk te werken op blokgrootten van 16x16 pixels tot 4x4 pixels. Gebieden met ingewikkelde bewegingen kunnen nu veel preciezer beschreven worden. Deblocking filter. Deze geavanceerde filtertechniek reduceert de blocking artefacten in een beeld aanzienlijk De netwerkabstractielaag De tweede laag, de netwerkabstractielaag (NAL), is de belangrijkste bij het streamen. Deze laag encapsuleert de slice uitvoer van de VCL encodeerder in netwerkabstractielaag eenheden (NAL eenheden). Pakket geörienteerde systemen kunnen deze NAL eenheden rechtstreeks gebruiken, terwijl bit en byte geörienteerde systemen de bytestream versie van de NAL eenheden rechtstreeks kunnen gebruiken. De bytestream versie van deze NAL eenheden is de NAL eenheden gescheiden door start codes. Elke NAL eenheid kan slice data bevatten, maar er zijn ook NAL eenheden voor andere doeleinden, zoals signalering, hoofding en additionele data. Een NAL eenheid bestaat uit een hoofding van één byte en een payload. De structuur van de hoofding wordt weergegeven in figuur 2.4. De betekenis van de componenten in de hoofding van de NAL eenheid wordt hierna kort beschreven. F: 1 bit forbidden zero bit. Een waarde van 0 geeft aan dat de hoofding en de payload van de NAL

20 2.1 De H264/AVC Codec 11 Figuur 2.4: De hoofding van de NAL eenheid Type Naam Beschrijving 1 Gecodeerde slice van een niet-idr beeld Slice data voor een P/SP of B slice 5 Gecodeerde slice van een IDR beeld Slice data voor een I/SI slice 6 SEI bericht bevat globale informatie 7 Sequentie parameter set Een hoofding voor de videostroom 8 Beeld parameter set Een hoofding voor de videostroom Tabel 2.1: De belangrijkste Nal eenheid types en hun inhoud eenheid geen bitfouten of syntax schendingen zou mogen bevatten. Een waarde van 1 geeft aan dat de hoofding en payload bitfouten of syntax schendingen zou kunnen bevatten. NRI: 2 bits nal ref idc. Een waarde van 00 toont aan dat de inhoud van de NAL eenheid niet gebruikt wordt om referentie beelden te reconstrueren voor predictie tussen de beelden. Zo een NAL eenheden kunnen verwijderd worden zonder de integriteit van de referentie beelden te beschadigen. Waarden groter dan 00 geven aan dat het decoderen van de NAL eenheid nodig is om de integriteit van de referentie beelden te bewaren. Type: 5 bits nal unit type. Deze component specifieerd het type payload van de NAL eenheid. Een kort overzichtje van de belangrijkste types kan je vinden in figuur 2.1. Voor een referentie naar alle gedefinieerd types van NAL eenheden en hun betekenis, verwijzen we naar sectie in [8]. Het parameter set concept In de H.264 codec heeft men de informatie die relevant is voor meerdere sneden ontkoppeld van de media stroom. Deze meta informatie moet betrouwbaar, asynchroon en voorafgaand aan de RTP pakket stroom verzonden worden. De verzameling van alle meta informatie wordt een pa-

21 2.1 De H264/AVC Codec 12 rameter set genoemd. Er zijn twee verschillende typen van parameter sets: sequentie parameter sets en beeld parameter sets. Een actieve sequentie parameter set blijft onveranderd gedurende de hele gecodeerde video sequentie en een actieve beeld parameter set blijft onveranderd in een gecodeerd beeld. De sequentie en beeld parameter sets bevatten informatie zoals de grootte van het beeld, optionele gebruikte codeer modes, en mapping van een groep slices op een macroblok. Doordat men nu de beeld parameters kan veranderen zonder dat men synchroon update parameters moet verzenden samen met de pakket stroom van de sneden, kan de encodeerder en de decodeerder een lijst bijhouden van verschillende parameter sets. Elke hoofding van een snede kan nu verwijzen naar een parameter set dat het wil gebruiken. Dit mechanisme laat toe dat het verzenden van de parameter sets ontkoppeld wordt aan de pakket stroom. Op deze manier is het mogelijk de parameter sets te verzenden via externe mechanismen of via een controle protocol. Het is zelfs mogelijk dat deze nooit verzonden worden, maar dat ze vast ingesteld zijn door het ontwerp van een applicatie. Door het onderscheid tussen NAL eenheden die zuivere video data bevatten en NAL eenheden die meta informatie bevatten kunnen we twee types van NAL eenheden onderscheiden: De VCL NAL eenheden: Deze NAL eenheden bevatten de eigenlijke video data van de beelden. De niet-vcl NAL eenheden: Deze NAL eenheden bevatten elke geassocieerde additionele informatie zoals parameter sets en SEI 1 berichten. Access Units Om een access unit te kunnen beschrijven hebben we eerst nog een beetje terminologie nodig: Een primair gecodeerd beeld is de voorstelling van een beeld dat gebruikt wordt in het decodeer proces van een bitstroom dat aan H.264 voldoet. Het primair gecodeerde beeld bevat alle macroblokken van het beeld. Een redundant gecodeerd beeld bevat een gecodeerd beeld of een deel daarvan. De inhoud van een redundant gecodeerd beeld zal niet gebruikt worden door het decodeer proces van een bitstroom dat aan H.264 voldoet. De inhoud van een redundant gecodeerd 1 Supplemental Enhancement Information

22 2.1 De H264/AVC Codec 13 Figuur 2.5: Overzicht van de structuur van een access unit beeld kan gebruikt worden door het decodeer proces voor een bitstroom dat fouten of verliezen bevat. Een IDR 2 beeld is een gecodeerd beeld dat enkel I of SI slices bevat dat een reset veroorzaken in het decodeer proces. Na het decoderen van een IDR beeld kunnen alle volgende beelden in decodeer volgorde gedecodeerd worden zonder voorspellingen van een beeld dat zich voor het IDR beeld bevindt. Een access unit bestaat uit een reeks NAL eenheden die altijd een primair gecodeerd beeld bevatten. Daarnaast kan een access unit ook één of meer redundant gecodeerde beelden bevatten of andere niet-vcl NAL eenheden. Het decoderen van een access unit resulteert altijd in een volledig beeld. Een overzicht van de structuur kan men terugvinden in figuur 2.5. Een IDR access unit is een access unit waarbij het primair gecodeerde beeld een IDR beeld is. Telkens wanneer we een IDR access unit ontvangen kunnen we terug een volledig nieuw beeld construeren zonder referenties naar voorgaande beelden. Dit is heel belangrijk als we de codec gaan evalueren in sectie 4 als er pakketverlies optreedt. Een fout in het beeld als gevolg van een verloren pakketje kan slechts duren tot de volgende IDR access unit. In dit hoofdstuk gaan we wat meer uitleg geven over de verschillende protocollen die gebruikt worden bij het verzenden van H.264 video. We beginnen met een korte inleiding over de structuur en werking van het RTP protocol. Daarna bespreken we het RTP payload formaat voor H.264 video. Vervolgens gaan we dieper in op het RTSP protocol en tot slot bespreken we kort even het SDP protocol. 2 Instantaneous Decoding Refresh

23 2.2 Real-time Transport Protocol 14 Figuur 2.6: Structuur van een pakket verzonden via RTP Figuur 2.7: Situering van RTP volgens het OSI-model 2.2 Real-time Transport Protocol Inleiding Het Real-time Transport Protocol (RTP) protocol[9] voorziet in extra netwerk transport functies die applicaties kunnen gebruiken om gegevens in reële tijd te verzenden, zoals audio, video of simulatie gegevens en dit zowel over unicast als multicast netwerken. De belangrijkste kenmerken zijn: payload type, volgnummer, tijdsaanduiding en een connectie identificatie. Het protocol voorziet niet in bronreservatie en garandeert geen quality-of-service voor diensten in reële tijd. Het transport van gegevens wordt gecontroleerd door een extra protocol: het Real-time Transport Control Protocol (RTCP). Zowel het RTP als het RTCP protocol zijn onafhankelijk van de onderliggende netwerk en transport lagen. In het OSI-referentiemodel situeert het RTP protocol zich in de toepassingslaag. Vaak wordt een combinatie van het UDP en IP protocol gebruikt als ondersteunende lagen voor een RTP overdracht. De invullingen voor de onderliggende lagen zijn afhankelijk van het gebruikte transportmedium en technologie. In figuur 2.7 wordt deze invulling volgens het OSI model nog eens weergegeven. Het RTP protocol bevindt zich dus op de toepassingslaag en is de eerste hoofding die er bij het verzenden van een pakket aan toegevoegd wordt. Figuur 2.6 geeft de structuur weer van een verzonden pakket via het RTP protocol.

24 2.2 Real-time Transport Protocol 15 Figuur 2.8: Overzicht van de structuur van de RTP hoofding Structuur van de hoofding De structuur van de RTP hoofding wordt weergegeven in figuur 2.8. De eerste twaalf bytes zijn altijd aanwezig in de hoofding, terwijl de lijst van CSRC identificaties optioneel zijn. De velden hebben de volgende betekenis: version (V): 2 bits: Dit veld duidt de RTP versie aan. padding (P): 1 bit: Als de padding bit gezet is, bevat het pakket één of meer additionele padding bytes aan het einde die geen onderdeel uitmaken van de payload. De laatste byte van de padding bevat het aantal padding bytes die moeten genegeerd worden, zichzelf inclusief. Padding kan nodig zijn bij sommige encryptie algoritmen met vaste blok grootten of voor het dragen van verschillende RTP pakketten in een gegevenseenheid van een lagere protocol laag. extension (X): 1 bit: Als deze bit gezet is, dan moet de hoofding gevolgd worden door exact één uitbreidingshoofding met een vast formaat. CSRC count (CC): 4 bits: De CSRC count bevat het aantal CSRC identifiers dat de hoofding volgen. marker (M): 1 bit: Kan gebruikt worden voor verschillende doeleinden naar gelang het type payload. Bij het verzenden van H.264 video wordt de marker bit gezet voor elk laatste pakket van de access unit. Dit is gelijkaardig aan het normale gebruik van de M bit in

25 2.2 Real-time Transport Protocol 16 video formaten, zodat een efficiënte behandeling van de afspeel buffer mogelijk is. Meer informatie over het zetten van de marker bit vindt u in subsectie payload type (PT): 7 bits: Dit veld identificeert het formaat van de RTP payload en legt de interpretatie door de applicatie vast sequence nummer: 16 bits: Het volgnummer verhoogt met één bij elk verzonden RTP data pakket, en kan door de ontvanger gebruikt worden om pakketverlies te detecteren en de pakketvolgorde te herstellen. De initiële waarde zou willekeurig moeten zijn (onvoorspelbaar). timestamp: 32 bits: De tijdsaanduiding reflecteert het bemonsteringstijdstip van het eerste byte in het RTP data pakket. Het bemonsteringstijdstip moet afgeleid zijn van een klok die lineair en monotoon verhoogt in de tijd om synchronisatie en jitter berekeningen te kunnen uitvoeren (1 tik per video frame is meestal niet voldoende). De frequentie van de klok is afhankelijk van het formaat van de data dat gedragen wordt in de payload en is statisch gespecifieerd in het profiel of de payload format specificatie dat het formaat definieert, of het mag dynamisch gespecifieerd worden voor payload formaten gedefinieerd via niet-rtp middelen. Bijvoorbeeld voor fixed-rate audio, zou de tijdsaanduiding verhoogt worden met één bij elke bemonsteringsperiode. Als een audio applicatie blokken leest die overeen komen met 160 bemonsteringsperioden van het invoer toestel, zou de tijdsaanduiding met 160 verhoogt worden bij elk blok, zowel als het als een pakket wordt verzonden of als men het als stil laat vallen. De initiële waarde voor de tijdsaanduiding zou willekeurig moeten zijn, zoals het volgnummer. SSRC: 32 bits: Het SSRC 3 veld identificeert de synchronisatiebron. Deze identificatie zou willekeurig moeten gekozen worden, met de intentie dat twee synchronisatiebronnen die deelenemen in dezelfde RTP sessie niet dezelfde identificatie kunnen hebben. CSRC list: 0 tot 15 elementen van elk 32 bits: De CSRC (Contributing SouRCe) lijst identificeert de donerende bronnen voor de payload dat in dit pakket bevat zit. Het aantal identificaties wordt bepaald door het CC veld (maximum 15). 3 Synchronization SouRCe

26 2.3 RTP payload formaat voor H.264 video 17 Figuur 2.9: Overzicht structuur van RTP pakket Bijvoorbeeld: Voor audio pakketten worden de SSRC identificaties van alle bronnen die samen zijn gemixt om een pakket te creëren opgesomd, wat een correcte aanduiding van de spreker toelaat bij de ontvanger. 2.3 RTP payload formaat voor H.264 video In de vorige sectie hebben we de werking en structuur van het RTP protocol beschreven. In dit hoofdstuk gaan we de structuur van de payload beschrijven bij het verzenden van H.264 video via RTP. Het RTP payload formaat voor H.264 video wordt beschreven in [12]. Figuur 2.9 geeft nog eens het overzicht van de structuur van een RTP pakket. Dit hoofdstuk is relevant voor het laatste gedeelte van het pakket Algemene structuur Er zijn drie verschillende typen van payload structuren gedefinieerd. De ontvanger kan de gebruikte structuur identificeren via de eerste byte van de RTP payload, dat zowel dient als de RTP payload hoofding als, in sommige gevallen, de eerste byte van de payload. Deze byte is altijd gestructureerd als een NAL eenheid hoofding. Het type veld van de hoofding van de NAL eenheid toont aan welke structuur aanwezig is. De mogelijke structuren zijn de volgende: Single NAL eenheid: Dit pakket bevat slechts één enkele NAL eenheid in zijn payload. Het type veld van de NAL hoofding heeft een waarde die gelijk is aan de waarde van de oorspronkelijke NAL eenheid. Dit is een waarde van 1 tot en met 23. Een geaggregeerd pakket: Dit type van payload wordt gebruikt om verschillende NAL eenheden in een enkel RTP pakket te steken. Er zijn vier verschillende versies voor dit type. Het Single-Time Aggregation Packet type A (STAP-A), het Single-Time Aggregation Packet type B (STAP-B), het Multi-Time Aggregation Packet (MTAP) met 16-bit offset (MTAP16) en het Multi-Time Aggregation Packet (MTAP) met 24-bit offset (MTAP24). De waarden voor het type veld zijn respectievelijk 24, 25, 26 en 27.

27 2.3 RTP payload formaat voor H.264 video 18 Type Pakket Naam 0 ongedefinieerd 1-23 NAL eenheid Een pakket met één NAL eenheid 24 STAP-A Single-time aggregation pakket 25 STAP-B Single-time aggregation pakket 26 MTAP16 Multi-time aggregation pakket 27 MTAP24 Multi-time aggregation pakket 28 FU-A Fragmentatie eenheid 29 FU-B Fragmentatie eenheid ongedefinieerd Tabel 2.2: Samenvatting van de verschillende NAL eenheid types Fragmentatie eenheid: Dit payload type wordt gebruikt om een enkele NAL eenheid te spreiden over verschillende RTP pakketten. Er bestaan 2 verschillende versies, FU-A en FU-B,die overeenkomen met een type waarde gelijk aan 28 en 29 respectievelijk. Een overzicht van de verschillende NAL eenheid types en hun payload structuren is gegeven in tabel 2.2. Single NAL eenheid pakketten Een single NAL eenheid pakket bevat slechts één pakket. Dit betekent dat er geen geaggregeerd of gefragmenteerd pakket kan gebruikt worden binnen een single NAL eenheid pakket. Een NAL eenheid stroom geëncapsuleerd in Single NAL eenheid pakketten moet verzonden worden in decodeer volgorde. De structuur van een single NAL eenheid pakket is weergegeven in figuur De hoofding van de NAL eenheid fungeert ook als hoofding van de RTP payload. Geaggregeerde pakketten Geaggregeerde pakketten bieden de mogelijkheid om verschillende NAL eenheden samen te nemen in grotere pakketten. Deze pakketten zijn geïntroduceerd om de verschillende MTU groottes van twee belangrijke netwerken te ondersteunen: vaste netwerken met een MTU grootte vaak beperkt door de ethernet MTU grootte (ongeveer 1500 bytes) en IP of niet-ip gebaseerde draadloze netwerken met een MTU grootte die meestal gelijk is aan 254 bytes of minder. De geaggregeerde

28 2.3 RTP payload formaat voor H.264 video 19 Figuur 2.10: RTP payload formaat voor een Single NAL unit pakket Figuur 2.11: RTP payload formaat voor geaggregeerde pakketten pakketten vermijden dat er media getranscodeerd moet worden tussen de verschillende netwerken waardoor een ongewilde pakketizatie overhead vermeden wordt. Er zijn twee soorten geaggregeerde pakketten: Single-time geaggregeerde pakketten (STAP): bevat geaggregeerd NAL eenheden met gelijke timestamps. Er zijn twee types gedefinieerd, één zonder DON 4 (STAP-A) en één met DON (STAP-B). Multi-time geaggregeerd pakketten (MTAP): Deze pakketten bevatten NAL eenheden waarvan de timestamps mogelijk verschillen. De structuur van het RTP payload formaat voor geaggregeerde pakketten kan je vinden in figuur MTAPs en STAPs hebben de volgende pakketizatie regels: 4 Decoding Order Number: Als dit veld gebruikt wordt kunnen er pakketten gedefinieerd worden die NAL eenheden bevatten die zich niet in decodeer volgorde bevinden. Aan de hand van dit veld kan dan de decodeer volgorde gereconstrueerd worden.

29 2.3 RTP payload formaat voor H.264 video 20 Figuur 2.12: Payload formaat voor STAP-A De RTP timestamp moet gezet worden naar de timestamp van de eerste NAL eenheid die zich in het geaggregeerd pakket bevindt. Het type veld van de hoofding van de RTP payload moet gezet worden naar de waarden die je kan terugvinden in tabel 2.2. De F bit moet op nul staan als alle NAL eenheden in het geaggregeerde pakket ook hun F bit op nul staan hebben. Staat er één F bit van de NAL eenheden op 1 dan moet ook de F bit op 1 staan. De NRI moet het maximum zijn van alle NAL eenheden in het geaggregeerd pakket. De marker bit wordt gezet naar de waarde die de laatste NAL eenheid zou hebben in het geaggregeerd pakket als het in zijn eigen RTP pakket zou verzonden worden. Tot slot gaan we nog even dieper in op de structuur van het STAP-A pakket. Dit pakket is het belangrijkste voor deze thesis. Voor een gedetailleerde beschrijving van de structuur van de andere geaggregeerde pakketten verwijzen we naar [12]. Een STAP-A pakket bestaat uit een 16 bit veld die de lengte aangeeft van de volgende NAL eenheid in bytes (zonder deze twee lengte bytes, maar met de hoofding byte van de NAL eenheid), gevolgd door de NAL eenheid zelf met zijn hoofding. Een STAP-A pakket is byte-gealigneerd binnen de RTP payload, maar het kan niet gealigneerd zijn op een 32-bit woord grens. Figuur 2.12 toont de structuur van een STAP-A pakket en figuur 2.13 toont een concreter voorbeeld van een STAP-A pakket.

30 2.3 RTP payload formaat voor H.264 video 21 Figuur 2.13: Voorbeeld van een STAP-A pakket met twee NAL eenheden Gefragmenteerde pakketten Gefragmenteerde pakketten maken het mogelijk om NAL eenheden op te splitsen in verschillende RTP pakketten. Door dit te doen in de applicatie laag in plaats van te vertrouwen op onderliggende lagen zoals bv IP hebben we de volgende voordelen: Het payload formaat kan NAL eenheden groter dan 64 kbytes verzenden over een IPv4 netwerk. worden. Vooral NAL eenheden in High Definition formaten kunnen al heel snel groot Het fragmentatie mechanisme maakt het mogelijk één enkel beeld te fragmenteren en voorwaartse error correctie toe toe passen. Een pakket wordt dan bijvoorbeeld opgesplitst in vaste blokken van k bytes zodat er gemakkelijk error correctie kan worden toegepast. Een uitgebreide bespreking kan je terug vinden in sectie 12.5 van [12]. Fragmenteren kan enkel bij een Single NAL eenheid en kan niet voor geaggregeerde pakketten. Een fragment van een NAL eenheid bevat een geheel aantal bytes van de originele NAL eenheid en moet na elkaar verzonden worden met opeenvolgende sequentie nummers zonder dat daar andere RTP pakketten tussen komen. Gefragmenteerde pakketten mogen ook niet genest worden, een gefragmenteerd pakket mag geen ander gefragmenteerd pakket bevatten. Figuur 2.14 toont het RTP payload formaat voor FU-A pakketten. Een FU-A bestaat uit een fragmentatie eenheid indicator en een fragmentatie eenheid hoofding van elk één byte, gevolgd door de payload van de fragmentatie eenheid.

31 2.3 RTP payload formaat voor H.264 video 22 Figuur 2.14: RTP payload formaat voor FU-A Figuur 2.15: De fragmentatie eenheid indicator De fragmentatie eenheid indicator ziet er als volgt uit: Een waarde van 28 of 29 in het type veld van de fragmentatie eenheid indicator identificeert een FU-A en een FU-B respectievelijk. De waarden van de F bit en het NRI veld is gelijk aan de waarden van de NAL eenheid die gefragmenteerd wordt. De fragmentatie eenheid hoofding heeft de volgende structuur: S: 1 bit Dit is de start bit. Als deze op 1 staat dan geeft dit aan dat we te maken hebben met het eerste pakket van de gefragmenteerde NAL eenheid. E: 1 bit Dit is de end bit. Als dit op 1 staat dan geeft dit aan dat we te maken hebben met het laatste pakket van de gefragmenteerde NAL eenheid. De laatste byte van de payload is dan ook de laatste byte van de oorspronkelijke NAL eenheid. Wanneer de FU payload niet het laatste fragment is van een gefragmenteerde NAL eenheid staat de end bit op 0. Figuur 2.16: De hoofding van de fragmentatie eenheid

32 2.3 RTP payload formaat voor H.264 video 23 R:1 bit Dit is de reserved bit. Deze moet altijd op 0 staan en moet genegeerd worden door de ontvanger. Type: 5 bits Het payload type van de NAL eenheid volgens de waarden in table Gebruik van de RTP hoofding We hebben in sectie 2.8 al kort beschreven wat de functies zijn van de verschillende velden in de hoofding van het RTP protocol. Als we nu het RTP protocol gebruiken voor het verzenden van H.264 video zijn er enkele velden die op een meer specifieke manier moeten behandeld worden. Marker bit (M): 1 bit Deze bit wordt gezet voor elk laatste pakketje van de access unit, zoals aangeduid door de RTP timestamp. Deze methode is gelijkaardig aan het gebruik van de M bit bij elk video formaat, zodat een efficënt afspeelbuffer management mogelijk is. Voor geaggregeerde pakketten (STAP en MTAP), moet de M bit in de RTP hoofding gezet worden op de waarde die het zou hebben als de laatste NAL eenheid die zich in het geaggregeerde pakket bevindt, zou verzonden worden in een afzonderlijk RTP pakket. Decodeerder kunnen deze bit gebruiken als een vroege indicatie van het laatste pakket van een access unit, maar moeten zeker niet vertrouwen op deze eigenschap. Payload type (PT): 7 bits Voor H.264 video wordt in deze thesis steeds de waarde 96 gebruikt. Sequentie nummer (SN): 16 bits Dit wordt gezet en gebruikt volgens RFC In de Single NALU en niet-geweven pakketizatie modus, wordt het sequentie nummer gebruikt om de decodeer volgorde van de NALU te bepalen. Timestamp: 32 bits De RTP timestamp krijgt de waarde van de sampling timestamp van de video. Een 90 khz klok ratio moet gebruikt worden. Als we bijvoorbeeld een videostroom hebben aan 30 frames per seconde, krijgen we een timestamp die telkens met een waarde van 3000 verhoogt voor elk volgend frame Pakketizatie modi Bij het verzenden van H.264 video heeft men de keuze uit drie verschillende pakketizatie modi: 1. Single NALU modus

33 2.4 Real-time Streaming Protocol 24 Type Pakket Single NAL Niet-geweven Geweven Eenheid Modus Modus Modus 0 ongedefinieerd ig ig ig 1-23 NAL eenheid ja ja nee 24 STAP-A nee ja nee 25 STAP-B nee nee ja 26 MTAP16 nee nee ja 27 MTAP24 nee nee ja 28 FU-A nee ja ja 29 FU-B nee nee ja ongedefinieerd ig ig ig Tabel 2.3: Samenvatting van de mogelijke types per pakketizatie modus (ja = toegestaan, nee = niet toegestaan, ig=ignore 2. niet-geweven modus 3. geweven modus De Single NALU modus is speciaal gericht naar conversationele systemen dat voldoen aan de richtlijnen van de ITU-T Recommendation H.241[7]. De niet-geweven modus is bedoeld voor conversationele systemen die niet voldoen aan de ITU-T Recommendation H.241. In de niet-geweven pakketizatie modus worden NAL eenheden verzonden in decodeer volgorde. De geweven modus daarentegen is bedoeld voor systemen dat geen lage vertragingen vereisen. De geweven modus laat toe om NAL eenheden te verzenden, die zich niet in decodeer volgorde bevinden. Tabel geeft een overzicht van welke pakketen die mogelijk zijn bij elk van de pakketizatie modi. 2.4 Real-time Streaming Protocol Inleiding Het Real-time Streaming Protocol(RTSP)[6] is een protocol op applicatie niveau (zie figuur 2.17) dat gebruikt wordt om de levering van data met reële tijd eigenschappen te controleren. RTSP voorziet een uitgebreid raamwerk om gecontroleerde overdracht van reële tijd data, zoals

34 2.4 Real-time Streaming Protocol 25 Figuur 2.17: Situering van RTSP volgens het OSI-model video en audio, op aanvraag mogelijk te maken. Het protocol is ontworpen om meerdere sessies tegelijk te kunnen beheren en kan zowel gebruik maken van UDP, multicast UDP en TCP. Het RTSP is ook op geen enkele manier afhankelijk van het gebruikte protocol voor de transport van de media. In de meeste gevallen is dit het RTP protocol, maar dit kan ook om het even welk ander protocol zijn. Het RTSP protocol is heel gelijkaardig aan het HTTP protocol, maar verschilt enkel in een paar belangrijke opzichten: RTSP introduceert enkele nieuwe methoden en heeft een verschillende protocol identificatie. Een RTSP server moet een status bijhouden in de meeste gevallen, een HTTP server heeft bij nature geen status. Zowel een de RTSP server als de klant kunnen aanvragen doen. De data zelf wordt door een ander protocol getransporteerd. De aanvraag URI bevat altijd het absolute pad. Het protocol heeft drie belangrijke functies: Opvragen van media van een server: Met behulp van RTSP kunnen klanten gemakkelijk bepaalde media bestanden aan servers opvragen. Deze functie is de reden waarom dit protocol gebruikt werd in deze thesis. Klanten die willen dat de server een bepaald videobestand streamt, kunnen dit gemakkelijk via dit protocol aanvragen. Na het aanvragen van de videostroom is het ook mogelijk om de videostroom verder te controleren, zoals bijvoorbeeld het pauseren en stoppen ervan.

35 2.4 Real-time Streaming Protocol 26 Uitnodigen van een media server voor een conferentie: Een media server kan uitgenodigd worden om deel te nemen aan een conferentie. Hij kan daar dan zelf media afspelen in de presentatie of hij kan alle media van de presentatie of een deel daarvan opnemen. Toevoegen van media aan een bepaalde presentatie: Specifiek voor live presentaties, de server kan dan aan de klant laten weten dat er nieuwe media beschikbaar is gekomen Werking Elke presentatie en media stroom kan geïdentificeerd worden door een RTSP URL. Elk videofragment en audiofragment van een presentatie kan zo afzonderlijk geïdentificeerd worden. De videofragmenten en audiofragmenten kunnen op totaal verschillende servers staan. We gaan nu even dieper in op de structuur van de RTSP URL. RTSP URL Een RTSP URL kan drie verschillende schema s hebben: rtsp, rtsps of rtspu. Het rtsp schema vereist dat de RTSP berichten verzonden worden via een betrouwbaar protocol (TCP voor het internet), terwijl het rtsps schema het gebruik van een onbetrouwbaar protocol aanduidt (UDP voor het internet). Het rtsps schema geeft aan dat een TCP protocol beveiligd met TLS moet gebruikt worden. Als de poort niet meegegeven is wordt een poortnummer van 554 aangenomen. URLs kunnen verwijzen naar een stroom verwijzen of naar een aggregatie van stromen, bv een presentatie. Zodus kunnen aanvragen zowel verwijzen naar de hele presentatie of naar een individuele stroom binnen de presentatie. Sommige aanvraag methodes kunnen echter enkel gebruikt worden bij volledige presentaties en omgekeerd. We geven als voorbeeld de volgende RTSP URL: rtsp://media.example.com:554/twister/audiotrack Dit identificeerd de audiotrack van de prestentatie ẗwister die kan gecontrolleerd worden door RTSP aanvragen over het TCP protocol naar poort nummer 554 op de host media.example.com. De volgende URL,

36 2.4 Real-time Streaming Protocol 27 rtsp://media.example.com:554/twister identificeert dan weer de volledige presentatie die zowel audio- als videostromen kan bevatten. RTSP is een tekst-gebaseerd protocol. De klant en server kunnen verschillende berichten verzenden in tekstformaat om een aantal taken uit te voeren. In wat volgt geven we een overzicht van de mogelijke berichten en hun functionaliteiten. Aanvraag berichten Een aanvraag bericht begint met een aanvraag-lijn. De aanvraag lijn zit er uit als volgt: Methode + SPATIE + Aanvraag-URI + SPATIE + RTSP-versie + CRLF. De methode geeft aan welke actie er moet uitgevoerd worden op de media stroom aangeduid door de URI. We vatten even kort de functionaliteit van de verschillende methodes samen. OPTIONS Een OPTIONS aanvraag kan op elk moment aangevraagd worden, bv als de klant een aanvraag wil doen die niet standaard is. Deze methode beïnvloed de toestand van de server niet. DESCRIBE De DESCRIBE methode wordt gebruikt om de beschrijving van een presentatie of media object te ontvangen. Het bevat ook informatie over welke verschillende beschrijvingsformaten geldig zijn. De server antwoordt dan met een beschrijving van de aangevraagde bron in een formaat die geldig is voor de klant. Een veel gebruikte manier is via het sessie descriptie protocol(sdp) wat meer in detail wordt besproken in sectie 2.5. De DESCRIBE aanvraag en zijn antwoord zijn samen de media-initializatie fase van het RTSP. ANNOUNCE De ANNOUNCE methode heeft twee verschillende doeleinden: Als de aanvraag verzonden wordt van klant naar server, post de ANNOUNCE methode de beschrijving van een presentatie of media object geïdentificeerd door de aanvraag-url aan een server. Wanneer het verzonden wordt van server naar klant, update de ANNOUNCE de sessie beschrijving in reële tijd. Als een nieuwe media stroom is toegevoegd aan de presentatie (bv, tijdens een live presentatie), moet de hele beschrijving van de

37 2.4 Real-time Streaming Protocol 28 presentatie opnieuw verzonden worden, in plaats van enkel de extra componenten zodat componenten kunnen verwijderd worden. SETUP De SETUP aanvraag voor een URI specifieerd het transport mechanisme dat gebruikt wordt voor de media stroom. Een klant kan een SETUP aanvraag doen voor een stroom dat reeds aan het spelen is om zijn transport parameters aan te passen, dat de server mag, maar niet moet toelaten. Als de server dit niet toelaat, moet het antwoorden met 445 Method Not Valid In This State. De klant moet telkens wel alle transport parameters aangeven, zelfs als het geen invloed heeft over deze parameters. Op deze manier kunnen firewalls en andere tussenkomende apparaten bespaard worden van de taak om het DESCRIBEantwoord te parsen dat gereserveerd is voor media initialisatie. PLAY De PLAY methode laat de server weten om te beginnen met het verzenden van data via het mechanisme dat in de SETUP gedefinieerd is. Een klant mag geen PLAY request verzenden als er nog SETUP aanvragen zijn die nog niet als geslaagd worden beschouwd. De PLAY methode specifieerd ook welke precies bereik van het bestand moet afgespeeld worden. Verschillende PLAY aanvragen worden in een wachtrij geplaats en worden sequentieel afgespeeld zonder extra pauzes ertussen. PAUSE Met de PAUSE aanvraag kunnen klanten een stroom tijdelijk pauseren. Dit kan zowel een hele presentatie zijn, of een deel van de presentatie, zoals bijvoorbeeld de audio. Bij het verder afspelen van een bestand, moeten de verschillende stromen van een presentatie terug gesynchroniseerd zijn. De server moet ook alle bronnen bijhouden bij het pauseren van een stroom, maar ze mogen wel de bronnen vrijgeven als er langer gepauseerd is als aangeduid in de timeout parameter van de beschrijving van de sessie in het SETUP bericht. TEARDOWN De TEARDOWN aanvraag stopt het verzenden van de media stroom aangeduid door de gegeven URI. De gebruikte bronnen worden ook vrijgegeven. Na een TEARDOWN aanvraag is elke RTSP sessie identificator die bij de sessie hoort niet meer geldig. Tenzij alle transport parameters beschreven zijn in de sessie beschrijving, moet er terug een SETUP bericht verzonden worden om de stroom opnieuw af te spelen. GET PARAMETER De GET PARAMETER aanvraag vraagt de waarde van een bepaalde parameter van een presentatie aan die gespecifieerd is in de URI.De inhoud van het antwoord is afhankelijk van de implementatie zelf en is niet vooraf bepaald. Het verzenden

38 2.4 Real-time Streaming Protocol 29 Figuur 2.18: Overzicht van de verschillende RTSP methodes van een GET PARAMETER aanvraag zonder inhoud kan gebruikt worden om te testen of de klant of server nog aanwezig zijn ( ping ). SET PARAMETER Deze methode zet een waarde voor een bepaalde parameter voor een presenatie of media stroom. Een aanvraag zou enkel ëën waarde mogen bevatten om de klant toe te laten om te weten te komen waarom het zetten van een bepaald parameter is mislukt. Indien een aanvraag verschillende parameters bevat, moet de server enkel handelen als al deze parameters gezet kunnen worden. Een server moet toelaten om een bepaalde waarde van een parameter meermaals te zetten, maar het mag het veranderen van bepaalde parameterwaarden weigeren. REDIRECT Een REDIRECT aanvraag laat de klant weten dat het moet verbinden naar een andere server. A redirect request informs the client that it must connect to another server location. Als de klant wil dat het verzenden van de huidige media stroom doorgaat, moet het een TEARDOWN verzenden naar de oude server en een SETUP aanvraag naar de nieuwe server. RECORD Deze methode start het opslaan van een bereik van een media stroom volgens de presentatiebeschrijving. Al deze verschillende methodes zijn niet allemaal even belangrijk. overzicht van de verschillende methodes en hun belang. Figuur 2.18 geeft een

39 2.5 Session Description Protocol Session Description Protocol We hebben al even kort aangegeven in sectie 2.4 dat het sessie descriptie protocol (SDP) vaak gebruikt wordt om multimedia sessies te beschrijven. Ook in deze thesis wordt het SDP protocol gebruikt om de videostroom volledig te beschrijven. SDP werd ontworpen om multimedia conferenties te adverteren en om alle informatie over te omschrijven die het mogelijk maken om aan zo een conferentie deel te nemen. Tegelijkertijd werd SDP ook ontworpen voor algemeen gebruik zodat het voor een heel breed bereik aan netwerk applicaties kon gebruikt worden. De informatie die SDP bevat is de naam van de sessie en het doel, de tijd van de sessie, het type media(audio of video), media formaat(bv. MPEG), gebruike transport protocol en poortnummer, vereisten voor de bandbreedte en contact informatie. SDP is geen transport protocol maar vertrouwt op een ander protocol om de informatie over te dragen zoals bijvoorbeeld SIP (sessie initiatie protocol) en RTSP. We gaan niet gedetailleerd de syntax van het SDP protocol beschrijven maar geven een concreet voorbeeld van hoe het protocol in deze thesis gebruikt wordt. Concreet voorbeeld OPTIONS rtsp:/localhost:1234/sample1.mp4 RTSP/1.0 CSeq: 1 User-Agent: VLC Media Player (LIVE555 Streaming Media v ) De klant (VLC Media Player) begin de RTSP sessie met een OPTIONS request. RTSP/ OK Status: 200 CSeq: 1 Server: (AvcStreamer Version 1.0; Platform/Linux) Public: DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,OPTIONS De server antwoordt met een reply met daarin alle RTSP methodes die hij aanbiedt. DESCRIBE rtsp://localhost:1234/sample1.mp4 RTSP/1.0\r\n CSeq: 2 Accept: application/sdp

40 2.5 Session Description Protocol 31 User-Agent: VLC Media Player (LIVE555 Streaming Media v ) Vervolgens vraagt de klant om de media op URL rtsp://localhost:1234/sample1.mp4 te beschrijven. protocol. Hij geeft ook aan dat hij enkel een beschrijving wil ontvangen volgens het SDP RTSP/ OK CSeq: 2 Server: AvcStreamer Version 1.0; Platform/Linux Date: :38:54 GMT Content-Type: application/sdp Content-length: 282 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): AVCStreamer IN IP Owner Username: AVCStreamer Session ID: Session Version: 2 Owner Network Type: IN Owner Address Type: IP4 Owner Address: Session Name (s): sample1.mp4 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Connection Information (c): IN IP Connection Network Type: IN Connection Address Type: IP4 Connection Address: Media Description, name and address (m): video 0 RTP/AVP 96 Media Type: video Media Port: 0 Media Proto: RTP/AVP Media Format: 96

41 2.5 Session Description Protocol 32 Media Attribute (a): range:npt= Media Attribute (a): control:trackid=1 Media Attribute (a): rtpmap:96 H.264/90000 Media Attribute (a): fmtp:96 packetization-mode=1;profile-level-id=4d401e; sprop-parameter-sets=j01ahqkymb73oa==,km4nia== De server antwoordt met een volledige beschrijving van de media. Hierin staan verschillende parameters zoals lengte, sessie ID, type van de media... Het belangrijkste attribuut is het laatste. Daarin worden de sequentie en de beeld parameter sets doorgegeven in 64-base encodering en het profiel van de video. Er wordt ook aangegeven welke pakketizatemodus er gebruikt wordt. Een pakketizatiemodus waarde van 1 geeft aan dat het om de niet-geweven modus gaat. Als dit bericht met de parameter sets verloren gaat is het onmogelijk voor de klant om de ontvangen video te reconstrueren. Voor een gedetailleerde behandeling van het verzenden van de parameter sets verwijzen we naar sectie 8.4 van [12]. SETUP rtsp://localhost:1234/sample1.mp4/trackid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port= User-Agent: VLC Media Player (LIVE555 Streaming Media v ) De klant vraagt om een bepaalde mediastroom op te zetten. Hij geeft ook door welke poorten hij gaat gebruiken voor het RTP en RTCP protocol. RTSP/ OK CSeq: 3 Server: AvcStreamer Version 1.0; Platform/Linux Date: :38:54 Session: Transport: RTP/AVP;unicast;client_port= ;server_port= De server bevestigt de aanvraag en geeft ook door welke poorten hij gaat gebruiken voor het RTP en RTCP protocol. PLAY rtsp://localhost:1234/sample1.mp4 RTSP/1.0 CSeq: 4

42 2.5 Session Description Protocol 33 Session: Range: npt= User-Agent: VLC Media Player (LIVE555 Streaming Media v ) De klant vraagt om de video af te spelen. RTSP/ OK CSeq: 4 Date: :38:54 Server: AvcStreamer Version 1.0; Platform/Linux De server bevestigt de aanvraag. TEARDOWN rtsp://localhost:1234/sample1.mp4 RTSP/1.0 CSeq: 5 Session: User-Agent: VLC Media Player (LIVE555 Streaming Media v ) De klant vraagt om de RTP sessie stop te zetten.

43 DE VIDEOSTREAMER 34 Hoofdstuk 3 De videostreamer Het doel van deze thesis is om een videostreamer te schrijven voor de H.264 codec, die gemakkelijk gebruikt kan worden om verschillende metingen uit te voeren. In dit hoofdstuk bespreken we de belangrijkste punten bij het verwezelijken van de streamer. De structuur van dit hoofdstuk volgt grotendeels de verschillende stappen die zijn genomen tijdens het tot stand komen van deze thesis. We beginnen in sectie 3.1 met een beschrijving van functionaliteit en de belangrijkste eigenschappen waaraan de streamer moet voldoen. Vervolgens bespreken we in sectie 3.2 nog twee bruikbare bibliotheken die gebruikt kunnen worden bij het ontwerp van een videostreamer. In sectie 3.3 eindigen we dan met een overzicht van het ontwerp van de videostreamer. We gaan hierbij niet in detail en beschrijven het ontwerp op een hoog niveau, anders zou dit ons veel te ver leiden. Voor een gedetailleerde beschrijving verwijzen we naar de API van het programma. 3.1 Algemene Vereisten We gaan even concreet beschrijven wat de vooropgestelde doelstellingen precies inhouden en dit vertalen naar functionaliteit en andere belangrijke eigenschappen Functionaliteit De functionaliteit is vooral geschreven voor de H.264 codec. De streamer moet enkel in staat zijn om deze codec te behandelen en geen andere. Daarbij is het belangrijk dat de streamer voldoende instelbaar is om het hele bereik van de mogelijkheden bij het verzenden van video gecompresseerd met de H.264 codec aan te spreken. De focus ligt dus vooral bij de H.264

44 3.1 Algemene Vereisten 35 video. De audio of andere bijkomende gegevens zoals ondertiteling die met een videobestand kunnen samengaan zijn niet belangrijk. Bij het verzenden van een videobestand is dus de eerste belangrijke functie de extractie van enkel het videospoor uit het bestand. Een tweede functie is het verzenden van de geëxtraheerde video zelf. Daarbij is het belangrijk om alle mogelijke parameters en modi instelbaar te maken. Bij het verzenden van video bestaan er verschillende pakketizatie-modi. Een overzicht van de verschillende pakketizatie-modi hebben we reeds besproken in sectie Deze modi moeten zeker instelbaar zijn. In het geval van de niet-geweven modus moet het ook mogelijk zijn om de maximale pakketgrootte te veranderen. Bij het gebruik van een streamer is het ook handig om de poort en de map, waarin de videobestanden zich bevinden, instelbaar te maken Belangrijke Eigenschappen Naast de functionaliteit zijn er nog enkele belangrijke eigenschappen om van de streamer een bruikbaar geheel te maken. Er mag niet vergeten worden dat de streamer vooral bedoeld is voor gebruik in een wetenschappelijke omgeving. Enkel het implementeren van de functionaliteit is niet voldoende om ervoor te zorgen dat de streamer een nuttig werktuig wordt. Overdraagbaarheid In een wetenschappelijke omgeving wordt er niet enkel gekeken naar één platform. Door ervoor te zorgen dat de code gebruikt kan worden in om het even welke omgeving, kan veel aan het gebruiksgemak ervan verbeterd worden. Op deze manier is het niet nodig om de code te hercompileren en/of aan te passen voor een bepaalde setup, maar kan ervoor gezorgd worden dat de code altijd en overal werkt. Uitbreidbaarheid De functionele vereisten en zelfs de H.264 codec kunnen in de toekomst nog altijd veranderingen ondergaan. Daarom is het ook belangrijk om een overzichtelijk structuur en duidelijk documentatie te hebben die het een heel stuk gemakkelijker maken voor externe mensen om uitbreidingen of veranderingen door te voeren. Leesbaarheid Dit hangt voor een groot stuk samen met het vorige stukje. Een code die gemakkelijk te lezen is, maar misschien niet altijd even efficiënt is te verkiezen over een code die de efficiëntie als belangrijkste beschouwt. Een duidelijke commentariëring en een overzichtelijke API (Application Programming Interface) zijn hierbij onontbeerlijk.

45 3.2 Bruikbare Bibliotheken Bruikbare Bibliotheken Omdat we als opdracht krijgen een video streamer te schrijven, is het natuurlijk niet noodzakelijk dat volledig van nul begonnen wordt. Het is zeker aan te raden om gebruik te maken van een bibliotheek die al een heel tijdje in gebruik is en zich zodus al voldoende heeft bewezen. Als deze bibliotheek ook nog in de vooropgestelde vereisten past, is er niets dat ons zou kunnen tegenhouden om van deze bibliotheek gebruik te maken. In het begin van de thesis is er vrij snel gekozen voor een implementatie in Java. Java is een object-geörienteerde programmeertaal die in tegenstelling tot andere talen zoals C platformonafhankelijk is. Dit is dus een perfecte invulling om de overdraagbaarheid van de code te garanderen. Het grootste nadeel van Java is dat deze taal niet performant is. Voor echt op performantie gerichte applicaties is het aangewezen om C te gebruiken. In deze thesis is de performantie van ondergeschikt belang waardoor de keuze voor Java snel gemaakt is. We beschrijven nu twee bibliotheken die gebruikt kunnen worden bij het programmeren van een streamer in Java Java Media Framework Het Java Media Framework (JMF)[10] is een raamwerk dat ontwikkeld werd door Sun en IBM, speciaal voor het verwerken van media binnen Java. De laatst nieuwe versie is JMF 2.1.1e die dateert van 23 mei De werkelijke kracht van JMF ligt hem in de uitbreidingsmogelijkheden ervan. Zoals de datum van de laatst nieuwe versie reeds aangeeft is er al een hele tijd geen nieuwe versie meer uitgekomen. Er gaat dan ook de ronde dat JMF achtergelaten zou zijn door Sun omwille van verschillende problemen zoals de licentieëring van de verschillende media formaten en codecs. Sun heeft bijvoorbeeld oorspronkelijk wel drie codecs voor MPEG-4 meegeleverd[5], maar nadat de originele makers ervan vergoedingen begonnen te vragen heeft Sun deze er terug uitgehaald. De functionaliteit dat standaard is meegeleverd is dan ook reeds grotendeels achterhaald. We gaan even dieper in op de werking van JMF en gaan dan verder met de bespreking van de functionaliteit. De werking van JMF is analoog aan bijvoorbeeld de werking van een stereo. Een stereo ontvangt geluid via een invoer en verwerkt vervolgens dit geluid door er effecten op te steken, te versterken,... Tenslotte speelt de stereo het geluid af via zijn luidsprekers. Ook in JMF zijn er drie verschillende stadia, het inlezen van de media, de verwerking ervan en de uitvoer. Figuur 3.1 geeft een overzicht van de verschillende stadia.

46 3.2 Bruikbare Bibliotheken 37 Figuur 3.1: Verschillende stadia bij verwerking van media in JMF Tijdens het invoer stadium wordt de data van een bron gelezen en doorgegeven via buffers aan het verwerkingsstadium. Het verwerkingsstadium bestaat uit een aantal codecs of effecten die ontworpen zijn om de data stroom aan te passen naar een bepaalde uitvoer. Deze codecs kunnen functies uitvoeren als compressie en decompressie van audio naar verschillende formaten, het verwijderen van ruis of het toevoegen van een effect zoals bijvoorbeeld een echo Nadat de gegevens verwerkt zijn worden deze naar het uitvoer stadium verplaatst. Dat kan het opslaan zijn van een bestand of het tonen van video op een scherm. We haalden zonet al aan dat de functionaliteit reeds grotendeels achterhaald is. Zo is er geen ondersteuning voor MP4 bestanden. Concreet betekent dit dat er in het verwerkingsstadium geen module bestaat die de demultiplexing van de tracks uit een MP4 bestand voor zijn rekening neemt. Dit maakt dat het onmogelijk is om H.264 video media uit een MP4 bestand te halen. Stel dat we de H.264 video via een andere manier uit het MP4 bestand halen dan is er ook geen standaard codec in JMF geïmplementeerd die deze H.264 video kan omzetten naar een formaat geschikt voor RTP overdracht. RTP is wel aanwezig in JMF, maar RTSP is dan weer enkel mogelijk langs de klant zijde. Veel bruikbare functionaliteit is dus niet terug te vinden in de standaard JMF bibliotheek. Nu is de grootste kracht van JMF niet de functionaliteit die het biedt, maar de mogelijkheid tot uitbreiding. De architectuur is speciaal in dit opzicht ontworpen. Het bestaat uit 2 verschillende lagen: de Presentation and Processing API en de Plug-In API. Figuur 3.2 geeft een overzicht van de architectuur. Uitbreiden van JMF gebeurt door het implementeren van een plug-in interface. Er zijn vijf typen van plug-in interfaces: demultiplexer, codec, effect, multiplexer en renderer. Elk van deze typen staan in voor het verwerken van een multimedia object op een bepaalde manier. (De)multiplexer. Staat in voor het scheiden van individuele mediasporen uit een samengestelde mediastroom en omgekeerd. Een demultiplexer implementeert bijvoorbeeld

47 3.2 Bruikbare Bibliotheken 38 Figuur 3.2: Architectuur van het Java Media Framework de functionaliteit om een videospoor uit een MP4 bestand te halen. Codec. Deze interface staat in voor het transcoderen van een mediaformaat naar een ander mediaformaat. Een codec implementeert bijvoorbeeld de functionaliteit om een ongecomprimeert videospoor om te zetten naar een videospoor in H.264 formaat. Effect. Deze interface is bijna gelijkaardig aan een codec, met dat verschil dat er enkel een kleine aanpassing uitgevoerd wordt aan de invoer, en deze niet omgezet wordt naar een volledig ander formaat. audiofragment. Een effect kan bijvoorbeeld een echo toevoegen aan een Renderer. Deze interface geeft aan hoe een gedecodeerde mediastroom verwerkt en gepresenteerd moet worden. Een renderer kan bijvoorbeeld een videospoor afspelen op een scherm. Het uitbreiden van JMF bestaat dus uit het implementeren van één van de bovengenoemde interfaces. Nadat een interface aangemaakt is, kan deze geregistreerd worden in JMF met behulp van een manager. Deze managers zorgen voor de creatie en registratie van alle objecten. Hoe dit precies gebeurd is heel technisch van aard en leidt ons te ver. Wat echter wel de essentie is, is dat JMF een overzichtelijke structuur heeft die duidelijk gedocumenteerd is met voorbeelden en tutorials en zodus gemakkelijk uit te breiden is. Het uitbreiden van JMF om de nodige functionaliteit uit te voeren lijkt op het eerste gezicht een goede keuze. Niets is minder waar. Als we JMF willen gebruiken voor het pakketizeren van H.264 video zijn er heel wat zaken die extra moeten geïmplementeerd worden, voordat we een bruikbaar geheel hebben. Zo moet er een datasource en format object aangemaakt

48 3.2 Bruikbare Bibliotheken 39 worden die correct de H.264 video omschrijft. Datasource objecten encapsuleren een bepaalde invoer gedurende het hele verwerkingsproces en format beschrijft het gebruikte formaat. In elk stadium wordt hiervan gebruik gemaakt. Ook moeten er veranderingen komen aan het standaard RTP protocol dat niet volledig is afgestemd voor de overdracht van H.264 video. Het RTP protocol maakt gebruik van de gegevens die het datasource object levert over de video (zoals de framerate en de lengte) om de pakketten tijdig te verzenden. Het tijdstip waarop een pakket wordt verzonden ligt dus vast. Ook is het bij het streamen van H.264 video standaard dat er een 90khz sampling klok wordt gebruikt, waarmee in JMF ook geen rekening wordt gehouden. Een streamer implementeren met behulp van JMF leidt ons veel te ver. Door de gebrekkige standaard functionaliteit die dateert van 2003 en het feit dat we gebruik maken van een codec die heel recent is, leent JMF zich niet goed om onze doelstelling te bereiken Java RTP Java.net.RTP[13] is een implementatie van het RTP en RTCP protocol in Java. Het werd speciaal ontworpen om een platform onafhankelijke RTP implementatie te hebben met multicast mogelijkheden, die dan kon gebruikt worden in applicaties zoals een whiteboard. Een whiteboard heeft verschillende initialisatie vereisten waarbij iedereen die deelneemt dezelfde inhoud moet hebben op elk moment. Dit wordt een probleem als een gebruiker pas later een whiteboard binnenkomt en dan gesynchroniseerd moeten worden. Daarom moeten er servers zijn die ervoor zorgen dat die late gebruikers bediend worden en verantwoordelijk zijn voor het leveren van alle data aan de gebruiker. Java.net.RTP werd ontworpen en ontwikkeld om modulair te zijn met algemene late-initialisatie klassen die een laat-initialisatie protocol implementeren. De architectuur werd gemotiveerd door de nood aan een modulair, eenvoudig en platform onafhankelijke RTP implementatie dat gemakkelijk kon geïntegreerd worden in om het even welke applicatie die RTP als zijn transport protocol nodig heeft. Figuur 3.3 geeft een overzicht van de architectuur. De hoogste klasse waarmee de gebruiker interageert is Session. Deze klasse encapsuleert alle setup, startup en shutdown methoden voor het RTP en RTCP protocol. Session dient ook als interface om de toestand van de objecten en hun interacties onderling te controleren. Vanuit het standpunt van de gebruiker interageert de Session klasse met het netwerk en is het verantwoordelijk voor het verzenden en ontvangen van RTP en RTCP pakketten. Wat bijdraagt tot de netwerk interactie kan geclassificeerd worden in twee verschillende processen:

49 3.2 Bruikbare Bibliotheken 40 Figuur 3.3: Overzicht architectuur van Java RTP Synchrone processen: Het verzenden van RTP pakketten Asynchrone processen: Ontvangen van RTCP pakketten Ontvangen van RTP pakketten Verzenden van RTCP pakketten De synchrone interactie met het netwerk is triviaal en wordt opgeroepen door de gebruiker als deze een RTP pakket wil verzenden. De asynchrone interactie anderzijds, vereist dat de RTP en RTCP ontvanger op verschillende threads lopen en wachten op de aankomst van een pakket. Na de ontvangst van een pakketje, worden er verschillende taken uitgevoerd zoals het genereren van een event. Door events te gebruiken is het mogelijk om zich in te schrijven voor bepaalde gebeurtenissen en anderen dan weer te negeren. Voor een beschrijving van het event model verwijzen we naar [13].

50 3.3 Ontwerp VideoStreamer 41 In figuur 3.3 zijn er verschillende threads te zien. RTPThreadHandler wordt gebruikt door Session om RTP pakketten te verzenden en te ontvangen. RTCPReceiverThread is gelijkaardig aan RTPThreadHandler en ontvangt RTCP pakketten in een oneindige lus, maar het verschilt aangezien het geen pakketten kan verzenden. Voor het verzenden van RTCP pakketten is een andere klasse, RTCPSenderThread voorzien. De functionaliteit voor het verzenden en ontvangen van RTCP pakketten is niet in een klasse ondergebracht om het ontwerp modulair en eenvoudig te houden. De RTCP zender en ontvanger hebben beiden ingewikkelde algoritmes en om te verhinderen dat veranderingen in de RTCP zend module de ontvanger module aantasten (en omgekeerd), worden deze functionele modules als onafhankelijke modules geïmplementeerd. RTCPThreadHandler is de superklasse, die dient als initiator voor de zender en ontvanger klassen. Deze klasse heeft als enig doel om de RTCP zender en ontvanger threads op te starten en af te sluiten. Het Java.net.RTP pakket bevat veel functionaliteit die we voor het implementeren van een videostreamer in principe niet nodig hebben. Zo moeten er enkel RTP pakketten verzonden worden en niet ontvangen en hebben we enkel unicast mogelijkheid nodig. De architectuur van het pakket is echter zo overzichtelijk en aanpasbaar dat we de bibliotheek gemakkelijk kunnen bewerken voor het gebruik in een videostreamer. 3.3 Ontwerp VideoStreamer Bij het ontwerpen van een videostreamer voor de H.264 codec hebben we gekozen voor de ontwikkeling van een nieuw systeem. Dit omdat er concreet weinig bibliotheken bestaan die in Java geschreven zijn, en die bruikbare functionaliteiten bieden voor de ontwikkeling van een videostreamer die gebruik maakt van deze recente codec. We maken wel gebruik van de Java RTP bibliotheek die beschreven staat in sectie Bij de bespreking van het ontwerp gaan we niet gedetailleerd alle functionaliteiten en methodes bespreken, maar beschrijven we op een hoog niveau de structuur en de werking van de streamer. De architectuur van de AVCStreamer 1 bestaat uit drie belangrijke onderdelen: 1. Invoer en Interne Buffering: Dit bestaat uit het lezen van de invoerbestanden en het extraheren van de NAL eenheden. Concreet moet de streamer MP4 bestanden kunnen inlezen en het videospoor eruithalen. Bufferen is in dit stadium heel belangrijk. Invoer 1 Advanced Video Codec Streamer

51 3.3 Ontwerp VideoStreamer 42 is heel traag en bij de start van het verzenden van de video hebben de gegevens een tijdslimiet tegen dat ze moeten verzonden zijn. Indien men niet zou bufferen, zou op sommige momenten het inlezen veel te veel vertraging met zich meebrengen zodat de gegevens niet meer op tijd verzonden kunnen worden, waardoor de video niet goed meer afpeelt. 2. Pakketizeren: Het videospoor moet ingedeeld worden in pakketjes met een structuur die geschikt is voor het verzenden via RTP. In sectie hebben we dit reeds besproken. 3. Overdracht via RTP protocol: Alle aangemaakte pakketjes moeten op tijd en correct volgens de regels[9] met het RTP protocol verzonden worden. We maken hierbij gebruik van de Java RTP bibliotheek die we in sectie beschreven hebben Invoer en Interne Buffering De eerste stap die we moeten uitvoeren is het inlezen van een MP4 bestand en daaruit het videospoor halen. We maken hierbij gebruik van een externe tool om deze stap zo snel mogelijk te laten uitvoeren. We gebruiken mp4creator van MPEG4IP [2] als externe tool, maar we hadden evengoed mp4box van GPAC [3] kunnen gebruiken. De klassestructuur die ervoor zorgt dat het videospoor uit het MP4 bestand wordt gehaald, wordt weergegeven in figuur3.4. Figuur 3.4: Klassediagram van componenten voor extractie videospoor De interface mp4tool definieert de methodes die geïmplementeerd moeten worden om het

52 3.3 Ontwerp VideoStreamer 43 videospoort uit het MP4 bestand te halen. Als men een andere tool wil gebruiken moet men enkel de methodes implementeren die in de interface zijn gedefinieerd. Een tweede stap is het inlezen van het videospoor en het extraheren van de NAL eenheden. Het gebruik van buffering is hierbij heel belangrijk omdat invoer heel traag is en videobestanden vaak heel groot zijn. Figuur 3.5 geeft een overzicht. Bij het inlezen van het videospoor maken we gebruik van de BufferedInputStream klasse die standaard met Java is meegeleverd. Deze klasse is er reeds op voorzien om zijn invoer zo goed mogelijk te bufferen. Het mist echter de mogelijkheid om bits afzonderlijk in te lezen, waardoor we zelf een klasse gedefinieerd hebben die als een soort van wrapper werkt voor de BufferedInputStream. Deze klasse noemt ByteStream. ByteStream verzorgt dus enkel de laag-niveau invoer van het videospoor. Een derde stap is tenslotte de extractie van de NAL eenheden. De klasse NalReader implementeert deze functionaliteit. We hebben bij het inlezen van de NAL eenheden gezorgd voor een extra buffer. NAL eenheden kunnen vaak sterk verschillen in grootte en het gevaar bestaat dat op een bepaald moment een NAL eenheid zo groot is dat de extractie ervan de deadline voor het verzenden niet meer haalt. Daarom is er nog een extra BufferedNalReader klasse die zorgt voor een buffering van de NAL eenheden, waardoor de vertraging dat door een grote NAL eenheid veroorzaakt wordt voor een groot deel kan opgevangen worden. De NaluBuffer klasse bevat de reeds gebufferde NAL eenheden die de NaluProducer reeds uit de invoerstroom heeft gehaald door de NaluReader de opdracht te geven een volgend NAL eenheid te extraheren. Figuur 3.5: Klassediagram van de invoer componenten

53 3.3 Ontwerp VideoStreamer Pakketizeren Na het inlezen van de NAL eenheden, moeten we pakketjes gereed maken voor het verzenden via RTP. We hebben in sectie aangehaald dat er drie pakketizatiemodi bestaan. In deze thesis zijn er reeds twee van de drie pakketizatiemodi geïmplementeerd, namelijk de niet-geweven modus en de single NAL eenheid modus. De derde modus, de geweven modus, stelt de gebruiker in staat om de verschillende NAL eenheden in een willekeurige volgorde te verzenden. De impact hiervan is een studie op zich en brengt heel wat mogelijkheden met zich mee. Wegens de beperkte tijd is er gekozen voor een werkende streamer die de belangrijkste pakketizatiemodi ondersteunt. Het implementeren en meten van de impact van de geweven pakketizatiemodus is een mogelijke uitbreiding dat besproken wordt in sectie 5.2. Figuur 3.6: Klassediagram van de pakketizatie componenten Figuur 3.6 geeft een overzichtje van de klassen voor het pakketizeren. De klasse Packetizer is een algemene abstracte klasse die de algemene functionaliteiten bevat voor het pakketizeren. De subklassen SingleNaluPacketizer en NonInterleavedPacketizer implementeren respectievelijk de single NAL eenheid modus en de niet-geweven modus. De Packetizer krijgt NAL eenheden binnen via de BufferedNalReader en heeft pakketjes als uitvoer via de getpacket() methode.

54 3.3 Ontwerp VideoStreamer Overdracht via RTP protocol Voor de overdracht via RTP wordt gebruik gemaakt van het Java.net.RTP pakket dat in sectie reeds beschreven werd. In de AVCStreamer is er één klasse dat de interactie met de RTP bibliotheek verzorgt en dat is de Transmitter klasse. Figuur 3.7 geeft deze klasse weer. Figuur 3.7: De Transmitter klasse Overige functionaliteit Naast het zuiver streamen van de video moeten externe aanvragen via het RTSP protocol ook behandeld worden. Het RTSP protocol wordt uitgevoerd door de Server klasse. Deze klasse verzorgt elke communicatie via RTSP en luistert in een oneindige lus op een bepaalde poort naar RTSP aanvragen. Voor het configureren van de AVCStreamer wordt er gebruik gemaakt van standaard ASCIIconfiguratiebestanden. Dit laat toe om alle mogelijke vrijheidsgraden bij het instellen van het programma te controleren via een eenvoudige textuele configuratie. Het configuratiebestand (standaard config.txt) bevat verschillende sleutel-waarde paren. Een overzichtje van de verschillende sleutels, hun betekenis en de mogelijke waarden volgt hieronder. Het is wel belangrijk op te merken dat de sleutel-waarde paren niet van volgorde mogen veranderen en altijd aanwezig moeten zijn. Bij het opstarten van de AVCStreamer wordt er een standaard config.txt

55 3.3 Ontwerp VideoStreamer 46 bestand aangemaakt met de standaard waarden. Dit config.txt bestand zal zich altijd in de map bevinden waarin het programma werd opgestart. DIR. De map waarin de videobestanden zich bevinden. Als een videobestand via RTSP wordt aangevraagd, moet het bestand zich in deze map bevinden opdat AVCStreamer dit bestand zou kunnen terugvinden. PACKETIZATION. De pakketizatie modus dat wordt gebruikt. Een 0 geeft aan dat de Single NAL eenheid pakketizatie modus gebruikt wordt en een 1 duidt op de nietgeweven pakketizatie modus. Standaard staat deze waarde op 1. MAXPAYLOADSIZE. De maximale grootte in bytes van de payload in een RTP pakket. In de niet-geweven pakketizatie modus kunnen meerdere NAL eenheden in één RTP pakket of kunnen meerdere NAL eenheden in één RTP pakket samengenomen worden. Bij het aanmaken van deze RTP pakketten wordt ervoor gezorgd dat de maximale grootte onder deze waarde blijft. Bij het verzenden van een pakket met AVCStreamer moet je 54 bytes extra rekenen die nog bij de payload grootte toegevoegd worden. Een maximale pakketgrootte van 1500 bytes betekent dus een maximale grootte van de payload van 1446 bytes. Standaard staat de MAXPAYLOADSIZE op 1438 bytes wat ook de standaard is bij Darwin Streaming Server, de open source streaming server van Apple. PORT. De poort dat gebruikt wordt voor de RTSP server om aanvragen te verzenden en te ontvangen. Standaard staat deze op BANDWITH. Wordt gebruikt door de Java.net.RTP bibliotheek, maar is voor deze thesis van geen belang. Dit kan nog wel nuttig zijn bij latere uitbreidingen. BUFFERSIZE. Dit is de grootte van de buffer voor de reeds ingelezen NAL eenheden op te slagen. De standaard waarde is 120. Er wordt ook een scheduling algoritme gebruikt, maar dit is zo eenvoudig mogelijk gehouden aangezien scheduling geen doelstelling was van deze thesis. Het scheduling algoritme stuurt op vaste intervallen een access unit door. Als een access unit volledig is doorgestuurd wacht het algoritme tot het begin van het volgende interval om de volgende access unit door te sturen.

56 3.3 Ontwerp VideoStreamer 47 Richting Protocol Info klant-server RTSP DESCRIBE rtsp:// :1234/sample1.mp4 RTSP/1.0 server-klant RTSP/SDP Reply: RTSP/ OK, with session description klant-server RTSP SETUP trackid=3 a=rtpmap:96 H264/90000 RTSP/1.0 server-klant RTSP Reply: RTSP/ OK klant-server RTSP PLAY rtsp:// :1234/sample1.mp4 RTSP/1.0 server-klant RTSP Reply: RTSP/ OK server-klant RTP Payload type=unknown (96), SSRC= , seq=120, Time= , Mark server-klant RTP Payload type=unknown (96), SSRC= , seq=121, Time= , Mark server-klant RTP Payload type=unknown (96), SSRC= , seq=122, Time= , Mark klant-server RTSP TEARDOWN rtsp:// :1234/sample1.mp4 RTSP/1.0 server-klant RTSP Reply: RTSP/ OK Tabel 3.1: Overzicht van de verzonden berichten bij het streamen Bespreking verzonden berichten tussen klant en server Om de structuur van de berichten en het gebruik van de protocollen te verduidelijken geven we hier een concreet voorbeeld van de verzonden berichten tussen de QuickTime videospeler en AVCStreamer. Tabel 3.1 vat de belangrijkste informatie samen. Eerst wordt de RTP sessie opgestart via het RTSP protocol. De klant vraagt om de media te beschrijven via een DESCRIBE en een URI. De server antwoordt hierop met een volledige beschrijving met behulp van het SDP protocol. Daarna volgen de SETUP van het spoor met als spoornummer 3 (in ons geval is er enkel een videospoor), rtp payload type 96 en een klokrate gelijk aan HZ. Tenslotte volgt een PLAY aanvraag en na bevestiging begint de streamer de video via het RTP protocol te verzenden. Bij het verzenden via RTP is het payload type steeds gelijk aan 96. Dit staat gedefineerd in RTP als een dynamische payload dat gebruikt kan worden voor payload types die niet standaard gedefinieerd zijn. Omdat H.264 nog niet in gebruik was bij het ontwerp van het RTP protocol is er (nog) geen vast type voor dit soort video. De SSRC is een unieke identificatie van de

57 3.3 Ontwerp VideoStreamer 48 synchronisatiebron en blijft steeds dezelfde. Het sequentienummer (seq) duidt de volgorde van het RTP bericht aan en verhoogt telkens met 1 in waarde. Als voorlaatste hebben we de Time dat het bemonsteringstijdstip aangeeft van het stuk video dat zich in het RTP pakket bevindt. Dat de decodeervolgorde niet gelijk is aan de afspeelvolgorde kunnen we eenvoudig zien aan de waarde van de Time. Het eerste RTP bericht heeft als Time waarde , het daaropvolgende bericht en het laatste bericht Indien we te maken hebben met een video aan 30 fps 2 en een klokrate van Hz moet er tussen de tijdstippen van twee opeenvolgende frames in afspeelvolgorde een verschil zijn van We zien dus dat het laatste frame volgt op het eerste frame en het tweede frame volgt op het laatste. Tot slot hebben we de Mark die aangeeft of het pakket het laatste pakket is van een access unit. We zien dat in het voorbeeld elke access unit uit slechts één RTP pakket bestaat. 2 frames per seconde

58 EVALUATIE 49 Hoofdstuk 4 Evaluatie 4.1 Inleiding Een nieuwe codec wordt niet alleen geëvalueerd op basis van zijn compressievermogen. Het is ook belangrijk dat de videostroom zijn kwaliteit blijft behouden bij optredende fouten. Op de vooravond van de grote doorbraak van digitale televisie is het vooral belangrijk om een codec te gebruiken die robuust is bij het verzenden over een netwerk. Bij het verzenden van een pakket over het netwerk kunnen verschillende problemen optreden zoals transmissiefouten, vertragingen, variërende vertragingen en verlies van pakketten. Deze problemen moeten zo goed mogelijk verborgen blijven voor de gebruiker en een robuuste codec kan daar veel aan helpen. Door de geavanceerde compressie van H.264 is het een sterke kandidaat om de nieuwe standaard te worden voor digitale televisie. Het is namelijk heel belangrijk om de gebruikte bandbreedte van een netwerk zo klein mogelijk te houden. In het ontwerp van de H.264 codec is er ook expliciet aandacht besteed aan het verzenden ervan over een netwerk. In het ontwerp vertaalde zich dat in de toevoeging van de NAL laag en de NAL eenheden. In dit hoofdstuk gaan we de invloed van pakketverlies op de kwaliteit van H.264 video evalueren Testopstelling De testopstelling bestaat uit een linux-server, een click router en een windows-server waar videolan op draait om de video te visualiseren. Figuur 4.1 geeft een overzicht van deze opstelling. De Click Router zorgt voor de simulatie van het pakketverlies tijdens het streamen van de server naar videolan. We gebruiken vier verschillende waarden voor het pakketverlies: 0.05%, 0.1%, 0.5% en 1%. De Click Router genereert echter een random pakketverlies volgens één

59 4.1 Inleiding 50 Figuur 4.1: Testopstelling voor kwaliteitsmeting met pakketverlies van deze vier waarden. De actuele waarden komen niet exact overeen met de ingestelde waarden, maar door een voldoende groot videofragment te kiezen, kunnen we deze waarden sterk benaderen Testmethode De bedoeling van de metingen die we gaan uitvoeren is om het kwaliteitsverschil te meten voor en na het verzenden van een videofragment over een netwerk met pakketverlies. Dit videofragment is geëncodeerd volgens de H.264 codec door gebruik te maken van x264, een open-source bibliotheek voor het encoderen van H.264/AVC video. We meten dus geen kwaliteitsverlies van de codering zelf, enkel de invloed van pakketverlies wordt in rekening gebracht. Het videofragment zelf wordt voldoende lang gekozen, zodat we statistisch gemiddelde meetresultaten kunnen verwachten bij een enkele uitvoering van de test. We gebruiken de Videolan Client om de videostroom te ontvangen en om te zetten naar het wetenschappelijke YUV bestandsformaat waarop we gemakkelijk bewerkingen kunnen uitvoeren om correcte meetresultaten te verkrijgen. Na het opslagen van het bestand gaan we dit syncen met het oorspronkelijke bestand. We gaan dit doen door uit het oorspronkelijke videobestand alle frames te verwijderen die niet meer terug te vinden zijn in het ontvangen videofragment. Op deze manier is het gemakkelijk om kwaliteitsanalyses uit te voeren door de frames van beide bestanden één voor één te vergelijken. Tot slot gebruiken we verschillende metrieken om het kwaliteitsverschil tussen het ontvangen en verzonden videofragment te meten Testconfiguraties Bij het testen op pakketverlies hebben we verschillende configuraties gebruikt. We zijn vertrokken van een ongecomprimeerd AVI bestand en hebben dit gecompresseerd met x264. We vatten belangrijke parameters van de geëncodeerde video even samen:

60 4.1 Inleiding 51 bframes: Dit hebben we op nul gezet. keyint: Dit staat op een default waarde van 250 en geeft het aantal frames tussen een IDRframe. Dit heeft gevolgen voor de encodeerefficiëntie, de zoekbaarheid en de foutpropagatie in een beeld. Hoe hoger de waarde, hoe efficiënter geëncodeerd kan worden, maar hoe langer een fout als gevolg van bijvoorbeeld pakketverlies blijft voortbestaan. Hoe lager de waarde, hoe zoekbaarder een videofragment wordt. Voor een beeld van 25 fps betekent dit dat men kan zoeken met een nauwkeurigheid van 10 seconden. cabac: Dit is de niet standaard entropiecoderingsmodus, die we reeds hebben besproken in sectie fps: Er zijn 30 frames per seconde. lengte: De lengte van het videofragment is 4 minuten en 57 seconden. Dit is lang genoeg gekozen zodat we bij de metingen statistisch relevante gemiddelden mogen verwachten. Hierdoor is het voldoende om elke meting slechts een keer uit te voeren. frameref: Het aantal referentieframes is gelijk aan 2. Dit wil zeggen dat er tot 2 frames kunnen gebruikt worden om de waarden in een P/B-frame te voorspellen. loopfilter: De deblockingfilter is ingeschakeld. Bij het testen gebruiken we twee verschillende formaten: 416x224 en 208x112, en twee verschillende bitrates: 512 Kbps en 768 Kbps. Tot slot gebruiken we ook nog twee verschillende pakketgrootten, 1492 bytes en 773 bytes. Met een pakketgrootte van 1492 bytes laten we alle parameters variëren over de vier pakketverlieswaarden: 0.05%, 0.1%, 0.5% en 1%. Hierdoor krijgen we 16 metingen. Met de pakketgrootte van 773 bytes laten we enkel het videobestand van 512 Kbps met de 4 lopen over de pakketverlieswaarden en krijgen we er nog eens 8 metingen bij. Deze metingen zullen ons toelaten om een goed idee te krijgen van het gedrag van de H.264 codec op pakketverlies. De resultaten worden besproken in sectie 4.3. We beperken ons tot de niet-geweven pakketizatie modus, omdat de videolan client er niet in slaagt om videostromen met de Single NAL eenheid modus correct weer te geven. Quicktime deed dit wel correct, maar er is geen mogelijkheid om in Quicktime de ontvangen video op te slaan naar een bestandsformaat dat toelaat om er analyses op uit te voeren.

61 4.2 Evaluatie AVCStreamer Metrieken We gebruiken verschillende metrieken om de kwaliteit van de ontvangen video te meten. In wat volgt bespreken we elke metriek en zijn betekenis. PSNR: Deze metriek, die in de praktijk vaak gebruikt wordt, noemt men de piek-tot-piek signaal-tot-ruis ratio. In het algemeen is deze metriek gelijkwaardig aan de gemiddelde kwadratische fout, maar het is gemakkelijker te gebruiken wegens de logaritmische schaal. Het heeft dezelfde nadelen als de gemiddelde kwadratische fout. De PSNR waarde wordt berekend met de onderstaande formule. d(x, y) = 10.log n 2 n,n i=1,j=1 (x ij y ij ) 2 Blocking metriek: Deze metriek werd gecreëerd om de graad van blocking in een beeld weer te geven. Op plaatsen in het beeld waar er hoog contrast is, is het bijvoorbeeld slechter om blokken te hebben dan in delen waar het oppervlak heel vak is. De metriek bevat ook heuristische methoden om randen van objecten te detecteren, die geplaatst worden aan de rand van het blok. In dit geval wordt de waarde van de metriek naar beneden afgerond om een preciesere meting van de blocking mogelijk te maken. Er wordt ook informatie uit voorgaande frames gebruikt om een betere nauwkeurigheid te verkrijgen. SSIM: Deze metriek is gebaseerd op het meten van drie componenten (overeenkomsten in luminantie, contrast en structuur) en het combineren ervan in een waarde. JND: De Just Noticeable Difference metriek is ontworpen om het verschil tussen twee beelden te meten, gezien door een menselijke kijker. De JND metriek is gebaseerd op eigenschappen van het menselijk zicht zoals luminantie, spatiale frequentie, lokaal contrast en het maskeren van het contrast. FD: De frame damage geeft het aantal beschadigde frames weer op het totaal aantal frames. De metriek wordt uitgedrukt in procent. 4.2 Evaluatie AVCStreamer Voordat we overgaan op de bespreking van de verschillende resultaten van de kwaliteitsmetingen, gaan we eerst even dieper in op de performantie van de videostreamer zelf. De AVCStreamer

62 4.2 Evaluatie AVCStreamer 53 is onafhankelijk van het gebruikte encodeerprofiel en kan vervolgens in principe elk soort videofragment aan, geëncodeerd volgens H.264. Enkel videobestanden met een pic order cnt type verschillend van 0 worden niet aanvaard. Een andere waarde heeft gevolgen voor de manier waarop een H.264 videofragment geparsed wordt, waardoor het aantal referentieframes niet meer geëxtraheerd kunnen worden. Een videobestand met een pic order cnt type verschillend van 0 is er echter tijdens deze thesis nog niet tegengekomen. Het grootste probleem waarmee de AVCStreamer nog te kampen heeft, is performantie. De streamer is in Java geschreven en voert alle berekeningen zelf uit, met uitzondering van de extractie van de videosporen. Dit heeft als gevolg dat videostromen die teveel berekeningen vragen, niet meer de tijdsbeperkingen halen die er zijn bij het verzenden. Er zijn verschillende oorzaken die ervoor zorgen dat de streamer een videofragment niet meer aankan. De bitrate is een eerste oorzaak. Videofragmenten aan 512 Kbps en 768 Kbps zijn in vele gevallen nog mogelijk. Als we echter videofragmenten van 1024 Kbps en hoger gaan gebruiken, zien we dat de tijdslimieten niet meer gehaald worden. Hoe hoger de bitrate, hoe groter de NAL eenheden en Access Units worden. Dit heeft als eerste gevolg dat er meer gegevens moeten verwerkt worden binnen een interval. Een tweede gevolg is dat door de grotere NAL eenheden de pakketten groter dan de maximaal gedefinieerde pakketgrootte in vele kleinere pakketten moeten opgesplitst worden. Hierdoor wordt er meer overhead gecreëerd waardoor al deze pakketten niet meer binnen de tijdslimiet kunnen verzonden worden. Een tweede oorzaak is het gebruik van B-frames. B-frames en P-frames zijn elk kleiner in grootte dan de keyframes (I-frames) en de streamer heeft dan vaak ook niet veel moeite om deze frames te verwerken. Als we B-frames gaan gebruiken heeft dit als gevolg dat de encoder de andere frames met veel meer informatie kan opslagen. Als we bijvoorbeeld een bitrate van 512 Kbps hebben ingesteld, kan de encoder veel meer bits gebruiken om een I-frame voor te stellen, aangezien er voor B-frames veel minder bits nodig zijn omdat deze gebruik maken van bidirectionele voorspellingen. De grotere I-frames kunnen ervoor zorgen dat de tijdslimiet niet meer gehaald wordt. Een tweede gevolg van B-frames is dat de decodeervolgorde veel meer gaat verschillen van de afspeelvolgorde. Het duurt langer vooraleer een volgend B-frame wordt verzonden dat als volgend frame moet afgespeeld worden. Omdat het scheduling algoritme hier geen rekening mee houdt kan dit soms problemen geven. Een derde oorzaak is het gebruik van een kleiner keyframe interval. Een I-frame betekent meer gegevens tijdens een interval en betekent dus meer rekenwerk, waardoor de tijdslimiet

63 4.3 Resultaten 54 eventueel niet meer gehaald kan worden. Een vierde oorzaak is een te kleine pakketgrootte. Als we te maken hebben met NAL eenheden die veel groter zijn in vergelijking met de maximale pakketgrootte kan dit veel overhead met zich meebrengen, aangezien een NAL eenheid dan in vele kleinere pakketjes moet gesplitst worden. We hebben in sectie 5.2 enkele uitbreidingen gedefinieerd die aan de bovenstaande problemen tegemoet kunnen komen. 4.3 Resultaten In dit hoofdstuk bespreken we de verkregen resultaten van de kwaliteitsmetingen van de H.264 video op pakketverlies. We bespreken achtereenvolgens de invloed van 3 parameters op de kwaliteit bij pakketverlies: bitrate, beeldgrootte en pakketgrootte Invloed van bitrate We beschouwen bij de besprekingen in deze sectie enkel de resultaten van de 416x224 video met een pakketgrootte van 1492 bytes. De onderstaande tabel geeft de actuele pakketverliezen die de videobestanden ondergaan hebben: Theoretisch Pakketverlies 512 Kbps 768 Kbps 0,05% 0,04% 0,06% 0,10% 0,15% 0,09% 0,50% 0,55% 0,51% 1,00% 0,93% 0,98% Tabel 4.1: Overzicht actuele Pakketverliezen per bitrate Ook nog belangrijk om op te merken is dat de videobestanden beide verschillen in aantal NAL eenheden en gemiddelde pakketgrootte. De onderstaande tabel vat deze waarden samen: Kbps Gemiddeld aantal NAL eenheden Gemiddelde pakketgrootte Tabel 4.2: Overzicht gemiddelde pakketgroote en NAL eenheden

64 4.3 Resultaten 55 PSNR PacketLoss 0.05% PSNR PacketLoss 0.05% PSNR (db) PSNR(dB) frames frames Figuur 4.2: 512 Kbps met PSNR gemiddel- Figuur 4.3: 768 Kbps met PSNR gemiddel- de: 42,2388% de: 36,3369% De tabel geeft aan dat de pakketgrootten niet zozeer verschillen, maar dat het gemiddeld aantal NAL eenheden wel een belangrijk verschil is. Per frame worden er gemiddeld 1,9 NAL eenheden verzonden in het geval van 512 Kbps, en 2,6 NAL eenheden in het andere geval. Meetgegevens De grafieken in figuur 4.2 en figuur 4.3 geven een grafiek van de PSNR voor respectievelijk 512 Kbps en 768 Kbps aan 0,05 % pakketverlies. In het 512 Kbps geval zijn er 94,68 % goede frames en in het tweede geval 91,64 % goede frames. Het lager aantal goede frames bij de 768 Kbps bitrate is waarschijnlijk te wijten aan het groter aantal NAL eenheden per frame. Bij het ontbreken van 1 pakketje van een frame wordt deze al als incorrect frame gerekend. De gemiddelde PSNR ligt ook iets lager voor de hogere bitrate. De grafieken in figuur 4.4 en 4.5 geven de resultaten weer bij 1% pakketverlies. Het aantal goede frames is in het 512 Kbps geval 41,68% en in het tweede geval 34,65%. De hogere bitrate heeft dus weer minder goede frames, wat te verwachten is. Als we echter gaan kijken naar de gemiddelde PSNR waarden dan zien we dat de PSNR waarde bij de hogere bitrate beter is. De hogere bitrate heeft dus meer foute frames, maar de fouten waren gemiddeld gezien minder groot, waardoor toch een betere beeldkwaliteit verkregen werd in het geval van 1% pakketverlies. Een grafiek met een overzicht van de gemiddelde PSNR per pakketverlieswaarde wordt weergegeven in figuur 4.6. Hier zien we dat de hogere PSNR waarde bij 1% pakketverlies bij uitzondering hoger is voor de hogere bitrate. Dit is heel merkwaardig aangezien het actuele pakketverlies zelfs hoger was voor de hogere bitrate. Het hoger zijn van de PSNR waarde bij 1% pakketverlies

65 4.3 Resultaten 56 PSNR PacketLoss 1% PSNR PacketLoss 1% PSNR (db) PSNR (db) Frames frames Figuur 4.4: 512 Kbps met gemiddelde Figuur 4.5: 768 Kbps met gemiddelde PSNR: 23,7123% PSNR: % Figuur 4.6: Gemiddelde PSNR waarden aan een bitrate van 768 Kbps kan te wijten zijn aan het syncen. We hebben immers alle frames uit het oorspronkelijk videofragment weggesmeten die we niet meer konden terugvinden in het ontvangen fragment. In het geval van veel pakketverlies zou dit wel eens tot verkeerdelijke resultaten kunnen leiden. We mogen dus aannemen dat in het algemeen de PSNR waarden lager zijn voor een hogere bitrate. De grafiek van de gemiddelde JND waarden wordt weergegeven in figuur 4.7. Volgens de JND metriek is de kwaliteit bij de lagere bitrate beter in alle gevallen. Dit spreekt ook de hogere gemiddelde PSNR bij 1% pakketverlies van de hogere bitrates tegen. De verklaring is hier waarschijnlijk te zoeken in het feit dat veel kleinere fouten veel storender zijn voor een menselijke kijker dan minder en grotere fouten. Doordat we met deze tweede metriek al een ander beeld krijgen op de kwaliteit, blijkt hier duidelijk het belang van meerdere metrieken te gebruiken.

66 4.3 Resultaten 57 Figuur 4.7: Overzicht gemiddelde JND waarden SSIM PacketLoss 0.5% SSIM PacketLoss 0.5% 1,2 1, ,8 0,8 SSIM 0,6 SSIM 0,6 0,4 0,4 0,2 0, frames frames Figuur 4.8: 512 Kbps Figuur 4.9: 768 Kbps We nemen de SSIM metriek er even bij in figuur 4.8 en figuur 4.9. Bij een pakketverlies van 0.5% hebben de bitrate van 512 Kbps en van 768 Kbps een gemiddelde SSIM waarde die bijna gelijk zijn, namelijk 0,9596 en 0,9476 respectievelijk. Als we naar de grafieken kijken merken we echter wel een duidelijk verschil op. De grafiek van de 768 Kbps heeft vaak diepere en langere dalingen dan de 512 Kbps. Als we tot slot de blocking metriek er even bijnemen in de figuren 4.10 en figuur 4.11 zien we duidelijk minder blocking in het geval van de 512 Kbps dan in het geval van 768 Kbps. Als we er een grafiek(figuur 4.12) bijnemen met de totale blocking verschillen tussen het ontvangen en het oorspronkelijke beeld zien we dat dit geldt voor alle pakketverliezen, met als uitzondering het geval van de 0,1% pakketverlies. Als we rekening houden met het feit dat de actuele pakketverlieswaarde voor de hogere bitrate in dat geval bijna de helft was van de lagere bitrate kunnen we veronderstellen dat een hogere bitrate nadeliger is voor de blocking.

67 4.3 Resultaten 58 Blocking Measure PacketLoss 0.5% Blocking Measure PacketLoss 0.5% Blocking Measure frames Blocking Measure frames Figuur 4.10: 512 Kbps Figuur 4.11: 768 Kbps Figuur 4.12: Overzicht totale blockingverschil

68 4.3 Resultaten 59 Conclusie We zien dat een hogere bitrate bij pakketverlies het meeste aan kwaliteit moet inboeten. Er is meer blocking aanwezig en de JND waarde is hoger dan in het geval van een lagere bitrate. De PSNR waarden zijn ook lager voor de hogere bitrate, met een uitzondering voor het geval met 1% pakketverlies. De SSIM waarden tussen de twee bitrates verschillen niet veel in waarde, maar liggen toch iets lager voor het videofragment aan 768 Kbps. Een grotere bitrate heeft als gevolg dat er meer bytes worden gebruik om een beeld op te slaan. Als we dit verzenden over een netwerk resulteert dit in een groter aantal pakketten dan in het geval van een lagere bitrate. De bovenstaande metingen tonen aan dat de kwaliteit van de ontvangen videosequentie in het geval van een hogere bitrate slechter is. Dit wil eigenlijk zeggen dat een beeld dat geëncodeerd is met meer bytes, een slechtere kwaliteit geeft bij een zelfde procentueel gegevensverlies. In het geval van de hogere bitrate bestaat dit gegevensverlies vaker uit het verlies van meerdere pakketjes die procentueel gezien minder gegevens van het beeld bevatten per pakket. In het geval van de lagere bitrate zijn dit vaker minder pakketjes met procentueel gezien meer gegevens van het beeld. Aangezien we een slechtere kwaliteit verkrijgen bij een hogere bitrate kunnen we concluderen dat de H.264 codec meer problemen heeft bij het decoderen van een beeld waar meerdere verspreide en kleinere delen ontbreken, dan het decoderen van een beeld waar minder maar groterere delen van ontbreken Invloed van beeldgrootte We beschouwen enkel de resultaten van de 512 bitrate video met een pakketgrootte van 1492 bytes. Tabel geeft de actuele pakketverliezen die de videobestanden ondergaan hebben: Theoretisch Pakketverlies 416x x112 0,05% 0,04% 0,09% 0,10% 0,15% 0,14% 0,50% 0,55% 0,48% 1,00% 0,93% 0,99% Tabel 4.3: Overzicht actuele Pakketverliezen per framegrootte Omdat we met een gelijk aantal Kbps werken is het aantal NAL eenheden en grootte van de pakketten bij beide videofragmenten ongeveer gelijk en houden we hiermee geen rekening in de verdere besprekingen.

69 4.3 Resultaten 60 Figuur 4.13: Aantal correcte frames Figuur 4.14: Gemiddelde PSNR waarden Figuur 4.15: Gemiddelde JND waarden Meetgegevens Figuur 4.13 geeft een overzicht van het aantal correct ontvangen frames. Wie zien dat in het geval van een grotere beeldgrootte er meer correcte frames zijn ontvangen. In figuur 4.14 zien we dat over het algemeen gezien, een kleinere beeldgrootte een betere PSNR geeft. Enkel bij een pakketverlies van 0.5% duikt de PSNR waarde van de kleinere beeldgrootte onder de andere beeldgrootte, wat waarschijnlijk te wijten is aan een lager actueel pakketverlies. Een grafiek met de gemiddelde JND waarden kan men terugvinden in figuur De grafiek geeft aan dat een lagere beeldgrootte een betere beeldkwaliteit geeft bij evenveel pakketverlies. De grafiek is zeer gelijkaardig aan de grafiek van de gemiddelde PSNR waarden. Het grote verschil is dat de verschillen groter zijn geworden in het geval van de JND metriek. Dit is te wijten aan het feit dat het menselijk oog minder gevoelig is bij hogere spatiale frequenties (in dit geval veroorzaakt door een kleiner beeld), waar de JND metriek rekening mee houdt. De gemiddelde waarden van de SSIM metriek zijn bijna identiek. In figuur 4.16 en 4.17 zien we grafieken van de SSIM waarden bij een beeldgrootte van 416x224 en 208x112 respectievelijk. De grafieken zijn gelijkaardig en de SSIM metriek stelt ons dus niet in staat om een conclusie

70 4.3 Resultaten 61 SSIM PacketLoss 0.1% SSIM PacketLoss 0.1% 1,2 1, ,8 0,8 SSIM 0,6 SSIM 0,6 0,4 0,4 0,2 0, frames frames Figuur 4.16: SSIM voor 416x224 Figuur 4.17: SSIM voor 208x112 Figuur 4.18: Totaal verschil tussen blocking measure waarden te trekken. Figuur 4.18 geeft de totale verschillen tussen de blocking waarden weer tussen de ontvangen en verzonden videobeelden. De gemiddelde waarden variëren enorm en lijken niet af te hangen van de grootte van het beeld. Ook uit de blocking measure zijn er geen conclusies te trekken. Conclusie De beeldgrootte heeft slechts weinig invloed op de kwaliteit van het beeld bij pakketverlies. Het aantal correct ontvangen frames, de PSNR waarden, de SSIM waarden en de blocking measure tonen geen duidelijk verschil. De JND metriek geeft wel aan dat de kleinere beeldgrootte een betere kwaliteit geeft, maar dit is enkel te wijten aan specifieke karakteristieken van het menselijk oog en hangt niet af van het pakketverlies.

71 4.3 Resultaten Invloed Pakketgrootte We gaan nu de invloed van de pakketgrootte op de kwaliteit van de video met pakketverlies bespreken. We nemen een videofragment van 512 Kbps met een beeldgrootte van 416x224 pixels. We testen dit videofragment voor twee verschillende waarden van maximale pakketgrootte: 1492 Bytes en 773 Bytes. Onderstaande tabel geeft de actuele waarden van de pakketverliezen: Theoretisch Pakketverlies 1492 Bytes 773 Bytes 0,05% 0,04% 0,04% 0,10% 0,15% 0,09% 0,50% 0,55% 0,46% 1,00% 0,93% 0,81% Tabel 4.4: Overzicht actuele Pakketverliezen per maximale pakketgrootte Omdat we de maximale pakketgrootte halveren, zal er een groot verschil zijn tussen het aantal NAL eenheden en de gemiddelde pakketgrootte. De onderstaande tabel 4.5 geeft een overzicht van de verschillende waarden. Het aantal NAL eenheden is bijna verdubbeld en de gemiddelde pakketgrootte nagenoeg gehalveerd. Max. Pakketgrootte Gem. NAL eenheden Gem. pakketgrootte ,21 Tabel 4.5: Overzicht gemiddelde pakketgroote en NAL eenheden Meetgegevens Figuur 4.19 en figuur 4.20 geven respectievelijk het aantal goede frames en de gemiddelde PSNR waarden weer. Het aantal correct ontvangen frames is veel lager bij een kleinere pakketgrootte. Het verschil met een grotere pakketgrootte neemt toe als er meer pakketverlies optreedt. Dit is te wijten aan het feit dat een frame uit dubbel zoveel NAL eenheden bestaat. Een teloorgang van slechts 1 van die pakketjes geeft reeds een fout frame. Als we de uiteindelijke PSNR waarden gaan vergelijken zien we dat het verschil tussen de gemiddelde waarden niet zo groot is. De PSNR waarde van het videofragment met de kleinere maximale pakketgrootte is zelfs beter bij een pakketverlies van 1%. Dit is waarschijnlijk te wijten aan een kleinere actuele waarde voor het pakketverlies.

72 4.3 Resultaten 63 Figuur 4.19: Aantal correcte frames Figuur 4.20: Gemiddelde PSNR waarden 120 PSNR PacketLoss PSNR PacketLoss 0.1% PSNR(dB) PSNR(dB) frames frames Figuur 4.21: pakketgrootte 1492 Bytes Figuur 4.22: pakketgrootte 773 Bytes De grafiek met de gemiddelde PSNR waarden is een goede indicatie voor de performantie van de H.264 codec. Een verlies van een pakket met grootte 1492 Bytes en twee pakketten met grootte 773 Bytes mag geen groot verschil teweegbrengen in de uiteindelijke kwaliteit. Er is een verschil, maar dit blijft relatief klein. Als we twee PSNR grafieken gaan vergelijken bij 0,1 % pakketverlies zien we dat er in het geval van de kleine pakketgrootte er meer fouten voorkomen, maar dat de grootte van de fout kleiner blijft. Als we de grafiek in figuur 4.23 beschouwen, zien we dat JND waarden van het videofragment met de kleinere pakketgrootte hoger liggen. Op 0,1% pakketverlies gaat hij er wel iets onder, wat waarschijnlijk te wijten is aan de lagere actuele pakketverlies. De SSIM waarden weergegeven in figuur 4.24, geven ook aan dat de kwaliteit van het videofragment met de kleinere pakketgrootte lager is dan met een grotere pakketgrootte. Op de grafiek van de Blocking Measure in figuur 4.25 is er beduidend meer blocking aanwezig in het videofragment met de kleinere pakketgrootte.

73 4.3 Resultaten 64 Figuur 4.23: Gemiddelde JND waarden Figuur 4.24: Gemiddelde SSIM waarden Figuur 4.25: Totaal verschil tussen blocking measure waarden