Low cost multirate video transcoder met parallelle hardwareversnelling

Transcriptie

1 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg Gent Low cost multirate video transcoder met parallelle hardwareversnelling Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica Wouter DERYCKERE Promotoren: ing. Wim VAN DEN BREEN ir. Paul BECUE (Televic conference) dr. ir. Pieter DEMUYTERE (Televic conference)

2

3 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg Gent Low cost multirate video transcoder met parallelle hardwareversnelling Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica Wouter DERYCKERE Promotoren: ing. Wim VAN DEN BREEN ir. Paul BECUE (Televic conference) dr. ir. Pieter DEMUYTERE (Televic conference)

4 Woord vooraf Een masterproef is nooit het werk van een persoon alleen. Daarom zou ik graag verschillende mensen willen bedanken voor hun bijdrage aan dit project. Ten eerste wil ik mijn stagebedrijf Televic en zijn medewerkers bedanken voor de kans die ze mij hebben gegeven. Toen ik hen voor de eerste keer contacteerde werd ik met open armen ontvangen. Persoonlijk kon ik mij geen betere stageplaats voorstellen. Alle communicatie was perfect, het aangeboden projectvoorstel was uitdagend en nooit werd ik aanzien als een gratis werkkracht. Ook het feit dat ze speciaal materiaal hebben aangekocht is een blijk van groot vertrouwen tegenover hun studenten. In het bijzonder wil ik Paul Becue en Pieter Demuytere, mijn begeleiders bij Televic, bedanken. Altijd stonden zij voor mij klaar indien ik vragen had of wanneer ik de mening van een expert zocht. Het waren ook zij die verantwoordelijk waren voor de goede opvolging van dit project. Ook mijn interne begeleider, Wim Van Den Breen, verdient ook een dankbetuiging voor de correcte opvolging van mijn masterproef en het nalezen van deze scriptie. Daarnaast wil ik ook nog mijn ouders en mijn vriendin bedanken. Niet alleen omdat ze mij de kans hebben gegeven om deze opleiding te volgen maar ook voor de morele steun in mindere tijden. Als laatste heb ik ook nog een dankwoord voor mijn medestagiaires bij Televic die zorgden voor de goede sfeer op de werkvloer. Samen lachen, een babbeltje slaan maar ook het delen van frustraties. Dankzij hen vertrok ik elke dag met plezier richting Televic. 4

5 Abstract Deze scriptie is het naslagwerk van mijn masterproef over de implementatie van een video transcoder cluster aan de hand van de Raspberry Pi. Buiten de theoretische uitleg over o.a. codecs en protocollen wordt ook de effectieve implementatie besproken. Deze transcoder cluster is gebouwd om live videobeelden te streamen naar verschillende mobiele toestellen. Elke transcoder in de cluster gebruikt andere parameters zodat er uit het systeem parallel verschillende videostreams komen met elk een andere kwaliteit en resolutie. Zo kan elke gebruiker de beste stream selecteren. De implementatie zelf is volledig gebeurd in C++. Het aanspreken van de componenten in de GPU gebeurt via OpenMAX. De clusterlogica gebruikt een master-slave structuur en communiceert via TCP-berichten. Dit project concludeert dat het mogelijk is om met een kleine investering toch een cluster te bouwen die diverse hoge kwaliteit videostreams kan aanbieden. Dit met een minimale vertraging. 5

6 Inhoudsopgave Woord vooraf 4 Abstract 5 Lijst met figuren 9 1 Inleiding 10 2 Het concept 11 3 Van bits tot videostream Kleurruimte: RGB en YUV Resolutie en framerate Videocodecs MJPEG JPEG-codec JIF H H.264 frames H.264 profielen en levels H.264 levels SODB, RBSP en NAL units SPS en PPS Bestandsformaten en media containers Netwerk en stream protocollen Netwerklaag: IP multicast Transportlaag: TCP Transportlaag: UDP Transportlaag: UDP jumbograms Applicatielaag: RTP RFC 2435: JPEG over RTP RTP-JPEG-header Restart header Quantization Table header C++: RTP-JPEG-Decoder RFC 3984: H.264 over RTP

7 INHOUDSOPGAVE RTP H.264 header FU header Samenvatting C++: RTP H264 encoder Applicatielaag: RTSP Session description protocol Applicatielaag: RTCP Applicatielaag: HTTP progressive downloading Applicatielaag: HTTP Live Streaming Native ondersteuning door mobile devices GStreamer Principe Voorbeelden GStreamer streamservers GStreamer cliënts Raspberry Pi 49 7 OpenMAX Algemeen Flags Tunnels Callbacks ILclient vs native OpenMAX Implementatie in C Opstarten Ophalen en wijzigen van eigenschappen Opzetten tunnel Implementatie van de transcoder Algemene structuur Parameters video encoder Fase 1: RTPToFile Fase 2: Implementatie van de transcoder Implementatie 1: Frame per frame Implementatie 2: Frame per frame met timeout Implementatie 3: Meerdere frames Implementatie 3: Events Performantie: delay Meten van delay Meetresultaten Oplopende delay bij andere resolutie Oplopende delay: het Resize component Encoder Oplopende delay: het probleem Implementatie 4: Events zonder oplopende delay

8 INHOUDSOPGAVE Performantie Implementatie 5: Performantie update RTSP sink GStreamer en OpenMAX Performantie Clustering Opstelling Opstelling adaptive bitrate streaming Implementatie adaptive bitrate streaming Javascript bandwidth sensing Implementatie protocol Beoordeling van het systeem Delay van het netwerk Bottleneck 1: ethernet poort van de Raspberry Pi Bottleneck 2: CPU Conclusie 89 Bibliografie 90

9 Lijst met figuren 2.1 Schematische voorstelling van het concept JPEG coding (HCL Technologies Ltd, Geciteerd april 2014) H.264 profielen (Ozer, 2009) RBSP (Raw Byte Sequence Payload) (codesequoia, Geciteerd april 2014) NAL Unit (codesequoia, Geciteerd april 2014) NALByteStream (codesequoia, Geciteerd april 2014) Sequence parameter set (International telecomunication union, 2010, Tabel ) OpenMAX states (The Khronos Group Inc, 2005) Structuur applicatie Quantization Parameter (Pixeltool, Geciteerd april 2014) Rate controller (Pixeltool, Geciteerd april 2014) Delay afhankelijk van de uitvoerresolutie CPU idle time Oplopende delay bij de crop of resize functie Delay van de encoder bij verschillende bitrates Delay van de encoder OpenMAX: Delay van de transcoder OpenMAX: Framerate van de transcoder CPU idle

10 Hoofdstuk 1 Inleiding Mobile devices, zoals een smartphone of tablet, zijn de dag van vandaag niet meer weg te denken uit onze maatschappij. Omwille van hun beperkte schermresolutie en rekenkracht is een livestream verzorgen voor zo n toestel niet eenvoudig. Ten eerste is er de beperkte bandbreedte van draadloze communicatie kanalen zoals 3G en WIFI. Daarnaast is er ook de beperkte rekenkracht om bijvoorbeeld videobeelden te decomprimeren. Een bijkomend probleem is de beperkte native ondersteuning van protocollen en media codecs. Om een goede live ervaring te garanderen voor elk mobiel toestel moet een streamserver dus meerdere streams aanbieden met verschillende parameters zoals kwaliteit en beeldresolutie. Dit is bijvoorbeeld mogelijk bij youtube waar alle filmpjes op voorhand gecodeerd werden met verschillende resoluties. Voor live beelden is het vooraf coderen niet mogelijk omdat er slechts een minimale vertraging getolereerd wordt tussen de realiteit en de getoonde videobeelden. Televic conference NV is expert in het ontwikkelen van verschillende conferentiesystemen. Dit gaat van draadloze microfonen tot volledige conferentiesystemen met live video streaming, stemmodule en de mogelijkheid om documenten onderling te delen. Omdat ook televic zoekt naar een oplossing om de ideale live ervaring naar mobiele toestellen te brengen, werd deze masterproef voorgesteld. Het project zelf is een Proof Of Concept, dus er wordt niet verwacht dat er een marktklaar product wordt ontwikkeld, maar wel om aan te tonen dat het project in praktijk te implementeren is. De beste manier om dit aan te tonen is het zelf ontwikkelen van een prototype. De eerste hoofdstukken van deze scriptie leggen de verschillende concepten, protocollen en media frameworks uit die gebruikt werden in dit project. Daarna volgt de uitleg over de effectieve implementatie waar zowel de code om te transcoderen als de clusterlogica zullen worden uitgelegd. Als laatste volgt de conclusie over de haalbaarheid van dit concept. 10

11 Hoofdstuk 2 Het concept Momenteel zijn er geen mogelijkheden om de live videobeelden uit het conferentiesysteem van Televic on the fly te coderen en te verzenden naar meerdere clients. Het coderen van deze live videostream is noodzakelijk aangezien het internet slechts een beperkte bandbreedte heeft. Het basisidee is om gebruik te maken van verschillende lowcost devices en deze te clusteren. Deze opstelling heeft twee grote voordelen in vergelijking met één grote transcoding server, namelijk de lage aankoopprijs en de mogelijkheid om dynamisch het systeem uit te breiden. Ook de gebruikskosten liggen een stuk lager dan bij één zware transcoding server omdat er meerdere processoren gebruikt worden die een veel lager verbruik hebben. Elke System on a Chip (SoC) zal onafhankelijk van de andere SoCs de inkomende stream coderen. De codeerparameters, zoals bitrate en resolutie, zullen bij elke SoC anders zijn. Hierdoor krijgen we verschillende streams die verschillen in kwaliteit en dus ook in benodigde bandbreedte. Daarna zal elk mobiel toestel die live wil meekijken onderzocht worden door het systeem. Deze zal de best mogelijke stream voor het toestel selecteren en die zenden naar de client. Een ideale stream wordt ervaren indien het beeld vloeiend afspeelt en de vertraging tussen de realiteit en de ontvangen beelden nihil is. Voor dit project is latency dus enorm belangrijk. Om dit te garanderen moet er gebruik worden gemaakt van hardware acceleration. Dit wil zeggen dat de wiskundige berekeningen die nodig zijn voor te (de)coderen niet door de trage CPU maar door de snellere GPU worden gedaan. Als SoC werd de Raspberry Pi voorgesteld. Deze SoC heeft naast een CPU ook een zware GPU met ingebouwde hardware encoders en decoders. 11

12 HOOFDSTUK 2. HET CONCEPT 12 Figure 2.1: Schematische voorstelling van het concept

13 Hoofdstuk 3 Van bits tot videostream In dit hoofdstuk gaan we dieper in op de algemene technieken die gebruikt worden bij een digitale progressive videostream. Al deze technieken kunnen onderverdeeld worden in verschillende lagen. Onderaan vinden we de colorspace of kleurruimte, dit is de methode die beschrijft hoe elke pixelkleur gedefinieerd wordt in het geheugen. In de volgende fase kan er optioneel een codec gebruikt worden die de frames comprimeert. Eenmaal we een stroom van frames hebben, kan deze gemultiplexd worden samen met de beschikbare audiostreams, ondertitels en andere metadata in een mediacontainer. Deze kan op zijn beurt op de schijf worden geplaatst of verzonden worden via een netwerkprotocol. 3.1 Kleurruimte: RGB en YUV We beginnen met de kleurruimte of colorspace (Merckx, 2009, Deel 1) (Fourcc, Geciteerd april 2014) (Microsoft, 2011). Elk frame dat uit een videostream komt is een onafhankelijke afbeelding. Een afbeelding bestaat uit een bepaalde resolutie van pixels. Er bestaan verschillende methodes om dat pixel om te zetten naar een bitwaarde. Om het kleur te definiëren moet de pixel gelokaliseerd worden in een bepaalde kleurruimte. Al deze kleurruimtes kan je verdelen onder meerdere categorieën, de twee bekendste zijn: RGB en YUV. Bij RGB wordt er een rood(r), groen(g) en blauw(b) kanaal uit de pixel gefilterd. Bij YUV is dit de helderheid (Y) en 2 kleurcomponenten (Chrominance U en V). Daarnaast bestaan er ook nog de YIQ (voorloper YUV) en CMYK (printers) kleurruimtes. De meeste pixelindelingen van de RGB-familie zijn gelijkaardig: per pixel worden er een paar bits gereserveerd die overeenkomen met de waarde van een van de drie kleurkanalen. Soms is er ook een alpha kanaal die de doorzichtigheid van de pixel bevat. Deze wordt aangeduid als alpha (A). Een paar bekende kleurruimtes zijn: RGB 24 bevat 24 bits per pixel, namelijk 1 byte per kleurkanaal 13

14 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 14 RGB 16 bevat 5 bits voor rood, 6 bits voor groen en 5 bits voor blauw ARGB 32 bevat 1 byte voor elk kanaal (alpha, rood, groen en blauw) Bij de YUV-collectie zijn er meer variaties mogelijk. Een packed formaat zet per pixel de Y-, U- en V-waarden na elkaar. Dit is vergelijkbaar met wat RGB doet. Bij een planar formaat zijn er 3 onafhankelijke kanalen met waarden. Eén voor alle Y-waarden, één voor alle U-waarden en één voor alle V-waarden. Meestal worden deze 3 kanalen daarna gewoon na elkaar geplaatst in een buffer. In OpenMAX (7) bestaan er ook semiplanar formaten. Deze hebben een rij voor alle Y-waarden, en één voor de U- en V-waarden. (Maemo, Geciteerd april 2014) Bij RGB wordt de pixelkleur gemaakt door 3 kleuren te mengen. Hoe groter de waarde, hoe groter dit kanaal zijn aanwezigheid mag tonen. Bij YUV is dit anders. Daar wordt de kleur aangeduid door de combinatie van de U- en V-waarden. Daarna wordt aan de hand van de Y-waarde de kleur lichter of donkerder gemaakt. YUV wordt vaak gecombineerd met downsampling. Dit is een eenvoudige manier van beeld compressie. Aangezien het menselijk oog minder gevoelig is aan chrominantieverschil, worden er voor de U- en V-waarden minder bits gebruikt dan voor de Y-waarde. Bij subsampling wordt niet voor elke individuele pixel een chrominatie waarde berekend. Een subsampling van twee betekend dat alleen de chrominantie waarden van de even pixels zullen gestockeerd worden. Subsampling kan je doen in een verticale en horizontale richting. Als voorbeeld nemen we het I420 formaat (of IYUV) dat gebruikt wordt in dit project. Horizontaal Verticaal Y Sample periode 1 1 V Sample periode 2 2 U Sample periode 2 2 Deze tabel toont aan dat bij I420 alle Y-pixelwaarden gebruikt worden. Alleen indien de rij en kolom index even zijn dan zullen de U en V waarden ook gebruikt worden. Dit is een eenvoudige manier om het datagebruik te minimaliseren zonder aan groot kwaliteitsverlies te lijden. Als je weet dat het aantal pixels (de resolutie) in een afbeelding gelijk is aan de hoogte maal de breedte dan kun je de gemiddelde bits per pixel ratio berekenen voor de I420 kleurruimte: het aantal Y waarden is gelijk aan de hoogte maal de breedte want er is geen subsampling. Het aantal U en V waarden is gelijk aan de hoogte 2 breedte 2. Als je veronderstelt dat elke waarde exact 1 byte inneemt dan is het aantal bits per pixel gemakkelijk te berekenen. Namelijk: resolutie+ resolutie + resolutie 4 4 resolutie, wat neerkomt op 1.5 byte of 12 bits per pixel. De sample periode wordt vaak genoteerd aan de hand van het j:a:b formaat. J is de referentiewaarde waar de andere waarden zullen aan gestaafd worden, meestal is dit 4. A is het aantal chrominantiewaarden in een even rij van J-pixels. B is het aantal chrominantiewaarden

15 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 15 in een oneven rij van J pixels lang. In ons voorbeeld zijn er in een even rij van vier pixels lang twee chrominantiewaarden. Een oneven rij van vier pixels lang bevat er geen. Dus kan dit formaat worden omschreven als YUV 4:2:0. Een ander aantal bekende YUV formaten zijn: I420 (aka IYUV): YUV 4:2:0 formaat, gebruikt bij JPEG-codering UYVY (aka Y422, UYNV, HDYC): een YUV 4:2:2 formaat, gebruikt bij MPEG-codering Meer informatie over andere YUV formaten kan gevonden worden op org/yuv.php. 3.2 Resolutie en framerate De framerate van een videostream is het aantal frames die per seconde getoond worden. Dit is uitgedrukt in Frames Per Second (FPS). De resolutie is de breedte en de hoogte van het frame. In de onderstaande tabel staat een lijst van standaard resoluties met hun bijhorende aspect ratio. Naam Resolutie Aspect ratio VGA 640*480 4:3 HD *720 16:9 HD * :9 4K UHDTV 3840* :9 8K UHDTV 7680* :9 3.3 Videocodecs Een codec is een manier om data te comprimeren of te decomprimeren. Compressie wordt bijna altijd gebruikt om minder bandbreedte of schijfruimte te verbruiken. Zo heeft een raw 720p videobeeld dat een framerate van 30 FPS heeft en I420 als colorspace gebruikt, een bandbreedte nodig van 316Mbps. Deze waarde kan je bekomen door de bits per pixel te vermenigvuldigen met de resolutie en de framerate. Het dus onmogelijk om raw 720p te streamen over een normaal 100Mbps ethernet netwerk. Voor dit project maken we gebruik van 2 videocodecs: MJPEG en H.264. Aangezien het coderen en decoderen door externe bibliotheken of door de hardware wordt gedaan, zullen we niet dieper ingaan op de wiskundige bewerkingen van deze codecs. Toch is het nodig om de algemene methodes te begrijpen.

16 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM MJPEG De gemakkelijkste codec om te gebruiken is Motion JPEG (MJPEG), niet te verwarren met MPEG. Deze methode houdt in dat elk frame onafhankelijk van de andere frames gecodeerd wordt via de JPEG-codeer methode. JPEG zelf is een goede compressie codec om te gebruiken bij afbeeldingen. Toch is MJPEG een slechte codec voor video s. De belangrijkste reden hiervoor is dat de compressie onafhankelijk is van de veranderingen tussen opeenvolgende frames. Zo zal de compressie van een film met altijd dezelfde frame enorm slecht zijn in vergelijking met bv MPEG1, MPEG2 of H.264 die wel rekening houden met variaties tussen opeenvolgende frames. Toch wordt deze codec vaak gebruikt. Het grootste voordeel aan MJPEG is zijn eenvoud. Zo moeten er geen vorige frames bijgehouden worden wat resulteert in een snellere en goedkopere decoder en encoder. De meeste USB-webcams hebben dan ook deze encoder aan boord. Dit is nodig omdat de bandbreedte van USB te laag is om er hoge kwaliteit videobeelden over te verzenden. Voor dit project wordt MJPEG gebruikt om 720p beelden aan te leveren over een 100Mbps netwerk. Aangezien JPEG geen vaste minimum compressiefactor aanbiedt, is het dan ook niet zeker dat de benodigde bandbreedte onder de 100Mbps blijft JPEG-codec JPEG gebruikt twee methodes om data te comprimeren. De belangrijkste is de mogelijkheid om de kwaliteit te verlagen, downsampling genoemd. Figure 3.1: JPEG coding (HCL Technologies Ltd, Geciteerd april 2014) Hoe de JPEG-encoder exact werkt kan je afleiden uit blokschema 3.1. In de eerste fase wordt de raw YUV-afbeelding opgedeeld in segmenten van acht op acht pixels. Deze array van waarden wordt daarna geconverteerd met een discrete cosinus transformatie (DCT). Dit houdt in dat de punten gemapt worden op een som van cosinussen. DCT is een

17 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 17 lossy compressiemethode. De volgende fase is de quantization fase. Elke waarde uit de matrix wordt gedeeld door een waarde uit de quantization matrix. Door gebruik te maken van een andere quantization tabel kan de kwaliteit van de afbeelding verlaagd worden. Dit resulteert in veel nullen in de rechteronderhoek van de matrix. Daarna worden er nog een paar andere compressietechnieken toegepast. De belangrijkste is de huffman codering. Deze compressiemethode stelt een frequentietabel op van alle mogelijke waarden die in de data voorkomen. Uit deze frequentietabel wordt dan een boomstructuur opgebouwd. De waarde die het meest voorkomt krijgt de kortste bitwaarde (0 of 1). Hoe minder frequent een waarde voorkomt, hoe langer de bitwaarde die gebruikt zal worden om de waarde voor te stellen JIF Uit de vorige afbeelding (3.1) is af te leiden dat een JPEG-bestand een samenraapsel is van de effectieve data, headers, quantization matrixen en huffman tabellen. Dit bestandsformaat wordt omschreven als de JPEG Interchange Format (JIF). Ook voor dit project moeten we onze data encapsuleren volgens het JIF-formaat. Het JIF-formaat wordt beschreven in de ISO/IEC :1994 of de T.81 (09/92) standaard. (itu-t81) Een JIF-bestand start altijd met een Start Of Frame marker, deze kan je herkennen aan de startwaarde FF D8. Daarna volgen er verschillende blokken met data. De eerste twee bytes van elk blok bevatten altijd een marker om aan te duiden wat de volgende data precies inhoudt. Zo heb je een marker voor een quantization tabel (FF DB), een huffman tabel (FF C4), enz. Alle mogelijke markers kan je terugvinden in de JPEG-standaard. Er zijn varianten op dit bestandsformaat zoals JFIF (ISO/IEC JPEG Part 5) en EXIF (JEITA CP-3451) H.264 H.264, ook gekend als AVC of MPEG-4 part 10, is de opvolger van H.263 en MPEG-2. Het is een onderdeel van de grotere MPEG-4 standaard (iso). Deze standaard bestaat uit verschillende parts die elk een bepaalde technologie omschrijven. Veel gebruikte parts zijn: Part 10: H.264 videocodec Part 12: Algemeen bestandsformaat, gebaseerd op Apple quicktime format Part 14: Specifiek bestandsformaat voor MP4-bestanden

18 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 18 Al deze standaarden kan je terugvinden onder de ISO/IEC-norm nummer Voor sommige parts kan je de documentatie gratis downloaden zoals part 4, 5, 10, 12, 20, 22, 26, 27 en 28. De andere delen zijn betalend. Al de informatie over H.264 kan gevonden worden onder ISO/IEC :2012 of T-REC-H I (International telecomunication union, 2010) H.264 frames Er bestaan 3 types van frames. Het type is afhankelijk van welke informatie er nodig is om het frame te kunnen (de)coderen. I frame: is onafhankelijk van andere frames P frame: is afhankelijk van vorige frames (Ook Delta frames genaamd) B frame: is afhankelijk van voorgaande en opvolgende frames H.264 gebruikt altijd I- en P-frames. B-frames kunnen optioneel gebruikt worden. MJPEG daarentegen gebruikt alleen maar I-frames. Het is niet altijd nodig om een volledige frame te klasseren als een I, P of B frame. Zo is het bij sommige H.264 profielen (zie afbeelding 3.2) mogelijk om per deel van een frame (een slice genaamd) in te stellen wat zijn afhankelijkheid is met andere slicen. Dan spreken we van SI en SP slicen H.264 profielen en levels H.264 ondersteunt verschillende profielen. Een profiel is een verzameling van verschillende compressiemethodes die ondersteund worden. Hoe hoger het profiel, hoe meer compressietechnieken er kunnen gebruikt worden en hoe hoger dus de compressiefactor wordt. De volgende profielen bestaan voor H.264: Baseline Profile (BP) Extended Profile (XP) Main Profile (MP) High Profile (HiP) High 10 Profile (Hi10P)

19 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 19 High 4:2:2 Profile (Hi422P) High 4:4:4 Predictive Profile (Hi444PP) Bron:(International telecomunication union, 2010) Het is belangrijk dat zowel de decoder als de encoder het gebruikte profiel ondersteunen. Omdat we een zo n breed mogelijk spectrum van toestellen willen ondersteunen kiezen we voor het baseline profiel. Indien men zeker is dat alle clients een hoger profiel accepteren, dan kan er geopteerd worden om een hoger profiel te gebruiken. Deze zal immers een veel betere compressieratio behalen. In de tabel 3.2 staat een overzicht van alle mogelijke compressie methodes en welke profielen welke methoden ondersteunen. Figure 3.2: H.264 profielen (Ozer, 2009) Het is nuttig om sommige methodes en eigenschappen onder te loep te nemen aangezien deze de uitvoer kunnen beïnvloeden. 1. De bitdepth en het chromaformaat vertellen welke colorspace als uitvoer uit de decoder zal komen. 2. Een H.264 encoder kan in plaats van een volledig frame ook stukken van een frame of slices teruggeven. Indien de optie SI en SP ondersteund wordt, dan is het mogelijk om in plaats van de frames, de slicen te kenmerken als SI of als SP slice. 3. B-frames zijn tevens een optie die gebruikt kan worden.

20 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM H.264 levels Naast het H.264 profiel moet er ook nog een H.264 level (International telecomunication union, 2010, P291) (Ozer, 2009) gekozen worden. Een level is een reeks van afspraken die het maximum bepalen van bepaalde parameters. Deze parameters zijn bijvoorbeeld de maximum video bitrate, de minimale compressie ratio en de maximale frame size. Net zoals bij H.264 profielen moeten zowel de encoder als de decoder het gebruikte level ondersteunen. De specifieke waarden voor elk level kunnen teruggevonden worden in de officiële documentatie (International telecomunication union, 2010, P291) SODB, RBSP en NAL units Een H.264 stream kan worden afgespeeld door de frames te concateneren. Dit komt omdat een raw H.264 frame niet bestaat. Er worden namelijk altijd extra velden toegevoegd aan de data. De zuivere H.264 data noemt men een SODB (String Of Data Bits). Zoals de naam doet vermoeden is dit een bitstream wat minder praktisch is als een bytestream. Daarom wordt deze bitstream geconverteerd tot een bytestream. Eerst wordt de SODB aangevuld met één stop bit (1), daarna volgen er verschillende nul bits tot de lengte van de SODB een veelvoud is van 8. Indien de SODB met stopbit exact een aantal bytes lang is, dan worden er geen extra nullen toegevoegd. Na de conversie heb je een RBSP (Raw Byte Sequence Payload). (International telecomunication union, 2010, p65) Figure 3.3: RBSP (Raw Byte Sequence Payload) (codesequoia, Geciteerd april 2014) De H.264 codec maakt gebruik van NAL-units. Network Abstraction Layer units zijn een encapsulatie van een RBSP-pakket voorgegaan door een NAL unit type. Dit is praktisch omdat de decoder zo kan weten welk soort data er in de NAL-unit zit: een I frame, een P frame, SPS, PPS, enzovoort. In de onderstaande tabel (International telecomunication union, 2010, tbl 7.1) staan alle NAL-types. De belangrijkste zijn in het vet gemarkeerd.

21 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 21 nal unit type NAL unit 0 Unspecified 1 Coded slice of a non-idr picture 2 Coded slice data partition A 3 Coded slice data partition B 4 Coded slice data partition C 5 Coded slice of an IDR picture 6 Supplemental enhancement information (SEI) 7 Sequence parameter set 8 Picture parameter set 9 Access unit delimiter 10 End of sequence 11 End of stream 12 Filler data 13 Sequence parameter set extension 14 Prefix NAL unit 15 Subset sequence parameter set Reserved 19 Coded slice of an auxiliary coded picture without partitioning 20 Coded slice extension Reserved non-vcl non-vcl Unspecified non-vcl non-vcl NAL unit type 1 indiceert een P-frame. Type 5 een I-frame. Naast het toevoegen van een NAL-unit type, wordt er ook gezorgd voor het wegwerken van de verboden bytes. Indien de RBSP een bepaald bytepatroon bevat dat verboden is, dan zullen deze veranderd worden naar een gelijkaardig patroon die wel toegelaten is. De verboden bytepatronen worden gebruikt om te synchroniseren en mogen dus niet aanwezig zijn in de RBSP-data. De volgende bytepatronen zijn verboden en worden gewijzigd: - 0x wordt 0x x wordt 0x x wordt 0x x wordt 0x Alhoewel 0x niet gebruikt wordt om te synchroniseren is dit patroon ook verboden. Indien we dit byte patroon zouden laten staan, dan zou de decoder het verschil niet zien tussen een verbeterd byte patroon en een origineel omdat deze beiden zouden starten met 0x

22 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 22 Figure 3.4: NAL Unit (codesequoia, Geciteerd april 2014) De laatste fase is het toevoegen van een startcode aan de NAL-units. Deze synchronisatie byte wordt gebruikt om het begin van de volgende NAL-unit aan te duiden. Dit bytepatroon is 0x of 0x Aangezien dit startpatroon een verboden bytepatroon is, zal deze dus ook nooit voorkomen in de data zelf. (International telecomunication union, 2010, p66). Figure 3.5: NALByteStream (codesequoia, Geciteerd april 2014) SPS en PPS In het overzicht van de NAL-unit types staan twee speciale NAL-units, namelijk de Sequence parameter set (SPS) en de Picture parameter set (PPS). Deze twee pakketten bevatten alle algemene informatie over de H.264 video stream en worden meestal eenmaal verzonden in het begin van de stream. De SODB van de SPS bevat de volgende velden: zie tabel 3.6. Merk op dat de SPS een variabele lengte heeft. Het ontleden van deze bitstream zou ons te ver afleiden maar het is toch noodzakelijk om een paar belangrijke velden te bekijken: profile idc en level idc: bevatten het profiel en het level van de H.264 stream. chroma format idc, bit depth luma minus8 en bit depth chroma minus8: Geven de YUV-colorspace terug. pic width in mbs minus1 en pic height in map units minus1: Geven de resolutie van de frames terug. Naast de SPS-informatie is er ook nog de PPS-informatie. Deze bitstream bevat meer informatie over de coderingseigenschappen van de stream. Meer informatie over de exacte velden kunnen teruggevonden worden in (International telecomunication union, 2010, Tabel ).

23 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 23 Het is belangrijk om te weten wat de SPS en PPS informatie inhoudt. Zonder deze pakketten is het onmogelijk om een stream te decoderen. Gelukkig worden deze twee pakketten automatisch door de encoder aangemaakt en is het dus niet nodig om deze zelf bit voor bit te construeren. 3.4 Bestandsformaten en media containers Indien je een mediabestand wil maken met audiokanalen, videokanalen, ondertitels en metadata moeten al deze kanalen gemultiplexd worden tot één bestand. Dit is slechts optioneel. Zo kan je met VLC player perfect een H.264 videostream afspelen zonder dat deze in een container zit. Ook bieden streamprotocollen zoals RTP de functie aan om deze streams naast elkaar te verzenden. Dan is de client verantwoordelijk om deze onafhankelijke streams samen te voegen door hun timestamps te vergelijken. Een van de bekendste bestandsformaat is de MP4 container. Deze is net zoals H.264 een deel van de MPEG-4 standaard. Andere bekende zijn Quicktime File Format (.mov), Matroska (.mkv) en MPEG-TS (.ts). Elk bestandsformaat biedt ondersteuning voor een beperkt aantal codecs. Een overzicht is te vinden op container_formats.

24 HOOFDSTUK 3. VAN BITS TOT VIDEOSTREAM 24 Figure 3.6: ) Sequence parameter set (International telecomunication union, 2010, Tabel

25 Hoofdstuk 4 Netwerk en stream protocollen Er bestaan verschillende protocollen om een mediastream te verzenden naar de verschillende clients. We overlopen laag per laag het TCP/IP model. 4.1 Netwerklaag: IP multicast De meeste communicatie gaat van één server naar één client, maar soms zijn er meerdere clients die dezelfde data willen ontvangen. Een mogelijke oplossing is dan om de pakketten te verzenden naar het broadcast adres, dit is het laatste IP-adres van een netwerk. Dit bericht zal dan ontvangen worden door alle clients die een IP-adres hebben in dezelfde IP-range. Broadcast berichten worden niet gerouteerd. Het grootste voordeel van broadcasten is dat elk pakket slechts eenmaal moet verzonden worden. Het grootste nadeel is dan weer dat er verschillende clients deze berichten zullen ontvangen terwijl deze de data niet nodig hebben. Een andere oplossing is gebruik te maken van een IP multicasting (RFC 1112). Bij IP-multicasting wordt als ontvanger IP een klasse D adres ingevuld (eerste 4 bits zijn 1110). Elke client die deze berichten wil ontvangen zend eerst een inschrijving over het netwerk. De routers in dit netwerk zijn verantwoordelijk dat elke ingeschreven client een kopie van de multicast berichten ontvangt. Multicasting is alleen mogelijk over een LAN-netwerk waarbij alle interne routers multicasting ondersteunen. In dit project wordt multicasting gebruikt om de live beelden naar alle transcoders te verzenden. De uitgaande streams naar alle verschillende clients zijn allemaal unicast berichten. Dit moet omdat de clients via het internet zijn verbonden. 25

26 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN Transportlaag: TCP Omdat we moeten kunnen streamen over het internet, zijn er slechts twee mogelijke protocollen die we kunnen gebruiken op de transportlaag: TCP en UDP. Streamen over TCP is in praktijk mogelijk. Zo kan je een H.264 stream die uit een encoder komt encapsuleren en verzenden in een TCP-stream. TCP werkt met het principe van handshaking. Dit wil zeggen dat een verbinding tussen 2 apparaten wordt opgezet en wordt onderhouden. Hierdoor ondersteunt TCP retransmitting van verloren pakketten. Bij live streaming is deze techniek niet aan te raden aangezien er moet gewacht worden op een frame dat toch te laat zal arriveren. Bij een H.264 stream zou dit wel handig zijn omdat het droppen van een frame resulteert in een fout die ook nog zichtbaar is in de volgende frames. Het constant moeten wachten op acknowledgement berichten, het opnieuw verzenden van verloren pakketten en de handshaking zorgen ervoor dat er tijd en bandbreedte verspild wordt. TCP werkt ook niet goed samen met IP-multicast. (Panko, 2008, P363) 4.3 Transportlaag: UDP Helaas is ook het UDP-protocol niet ideaal. UDP-pakketten worden namelijk afzonderlijk van elkaar verzonden. Dit wil zeggen dat er geen mogelijkheid is tot fragmentatie van een frame over meerdere UDP-pakketten. Dus is het verplicht om exact één frame in één UDP-pakket te verzenden. Het lenght veld in de UDP-header is 16 bit lang. Dus de payload van een UDP-pakket kan maximaal 64KB zijn inclusief de UDP-header. Als je weet dat een raw 720p frame zo n bytes inneemt, dan kan je concluderen dat er een verplichte constante minimale compressiefactor van 15 op 1 moet zijn. Dit is niet te garanderen voor elke frame. Het is mogelijk om frames te fragmenteren indien er gebruikt wordt gemaakt van het bovenliggende RTP-protocol. 4.4 Transportlaag: UDP jumbograms Zoals omschreven in de vorige paragraaf is de maximale payload van een UDP-pakket gelimiteerd door de beperkte lengte van het lenght field in de UDP-header. De maximale payload is: 2 16 min de lengte van de UDP-header. Deze header is altijd 8 byte lang. Indien er gebruik wordt gemaakt van IPV4, dan is dit limiet nog kleiner. Een IPV4-header heeft ook een lenght veld van 16 bit lang. De maximale payload van een IPV4-pakket kan dus maximaal 2 16 lenght(ip V 4header) zijn. Een IPV4-header is minimaal 20 bytes indien

27 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 27 er geen extra headers aanwezig zijn. Met deze informatie is het mogelijk om exact te bereken hoeveel payload een UDP-pakket kan bevatten indien deze over IPV4 wordt verzonden lenght(ip V 4header) lenght(udp header) = = 65507bytes Deze limiet is te omzeilen door gebruik te maken van jumbograms (RFC 2675) (RFC, 1999) (niet te verwarren met jumbo frames). Jumbograms zijn alleen te gebruiken bij IPV6. Nu heeft ook IPV6 een lengte veld van 16 bit lang. Bij jumbograms wordt dit veld op 0 gezet en wordt er een extra jumbogram IPV6-header toegevoegd. Deze extra header bestaat uit een 32 bit lenght veld waarin de correcte lengte te vinden is. Dit laat toe om een IP-payload van 2 32 i.p.v bytes te verzenden. Het UDP lenght field wordt op 0 gezet. Dit veroorzaakt geen problemen aangezien de exacte lengte van het UDP-pakket kan berekend worden met de data uit de IPV6-header. Helaas is dit protocol niet bruikbaar voor dit project omdat niet alle routers en besturingssystemen dit ondersteunen. 4.5 Applicatielaag: RTP Het Real Time Protocol (RTP) werkt bovenop UDP en is ontworpen voor live streaming. Het grootste nadeel van UDP, namelijk de gelimiteerde frame size, lost RTP op door één frame te fragmenteren over verschillende UDP-pakketten. RTP laat verschillende soorten payloads toe. Zo is er een standaard voor H.264 over RTP (RFC 6184), JPEG over RTP (RFC 2435), MP3 over RTP (RFC 5219), enzovoort. Merk op dat het gebruik van een media container met RTP niet nodig is. Indien er een film wordt verzonden over RTP dan zijn er twee of meerdere onafhankelijke RTP-streams die elk verantwoordelijk zijn voor een kanaal (audio, video,...). Deze streams worden dan naast elkaar verzonden naar de client. Zolang de ontvanger dit ondersteunt en de timestamps van de pakketten in orde zijn, zal de client een vloeiende film met beeld en geluid afspelen. Wanneer er meerdere paden zijn tussen de server en de client, dan is het mogelijk dat de volgorde van de fragmenten verstoord wordt. Daarom is het aan te raden om de pakketten te ordenen wanneer deze aankomen aan de client zijde. Ongeacht zijn payload heeft elk RTP-pakket altijd dezelfde header: V=2 P X CC M PT sequence number timestamp synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers

28 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 28 (RFC, 2003a) Deze header bevat de volgende velden: V Versie: 2bit: is altijd 2 P Padding: 1bit: Indien 1 is de data verlengd met nullen tot deze een vaste lengte heeft. De laatste byte vertelt dan hoeveel bytes er toegevoegd zijn (inclusief zichzelf). X Extension: 1bit: Een extra header is voorzien. CC CSRC count: 4bit: Aantal CSRC identifiers, zie CSRC. M Marker: 1bit: Duidt een belangrijk pakket aan. De exacte betekenis is afhankelijk van het onderliggende payload type. PT Payload Type: 7bit: Type van de payload. Een overzicht van de mogelijke payload types kan teruggevonden worden op De meeste protocollen kiezen voor een dynamische payload type. Dit wil zeggen dat alle informatie over de payload gekend is door zowel de client als de server. Dit kan gebeuren door een SDP-bestand of door het RTSP-protocol. Sequence number Sequence number: 16bit: Identificatienummer van het RTP-pakket. Alle fragmenten van hetzelfde frame hebben toch een ander sequentienummer. De sequence number incrementeert altijd met 1. Timestamp Timestamp: 32bit: Het aantal ticks van een klok. De snelheid van de klok is gekend door zowel de client als de server. Voor H.264 video signalen is dit bijna altijd een 90 KHz klok. Alle pakketten die data bevatten van hetzelfde frame hebben dezelfde timestamp. SSRC synchronization source identifier: 32bit: Een random waarde om de RTP-stream te identificeren. Dit is nodig indien er meerdere RTP-streams aankomen op één machine (bv een RTP-videostream en een RTP-geluidsstream). CSRC CSRC list identifies: 32bit per item : Optioneel, kan maximaal 15 items bevatten. Het aantal CSRC-objecten is meegegeven in het CC-veld. Dit is een lijst van andere SSRCs die samen horen met deze stream. In de meeste gevallen is padding false, extensions false en zijn er geen CSRSs en dus is CC gelijk aan 0. Na de algemene RTP-header volgt de payload specifieke header. In dit project worden er twee types gebruikt: JPEG over RTP en H.264 over RTP.

29 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN RFC 2435: JPEG over RTP RFC 2435 bespreekt het protocol om JPEG-gecodeerde frames te verzenden over RTP. Opeenvolgend bevat elk pakket dan de volgende stukken: 1. RTP-header 2. RTP-JPEG-header 3. Optioneel een restart marker 4. Optioneel een quantization table header 5. Payload De opbouw van de algemene RTP-header staat uitgelegd in de vorige paragraaf 4.5. Al deze informatie is te vinden in de RFC (1998b) RTP-JPEG-header Elk RTP pakket met JPEG-data begint met een RTP-JPEG-header. Deze bevat de algemene informatie over de JPEG-payload Type-specific Fragment Offset Type Q Width Height Type-specific Type-specific: 8 bits: Is afhankelijk van het type veld en heeft meer specifiek het JPEG-type terug. Fragment offset Fragment offset: 24 bits: De offset van de JPEG-data. Wanneer de fragment offset gelijk is aan 0, dan bevat het RTP-pakket de eerste scan van de JPEG-frame. Type Type: 8 bits: Het JPEG-type van de afbeelding. Type 0-63 zijn gereserveerd. Types 64 tot en met 127 zijn identiek dezelfde types maar met restart headers. JPEG-types 128 tot en met 255 zijn dynamisch toe te wijzen. Q Q: 8 bits: Definitie van de quantization table. Een waarde tussen 0 en 127 wil zeggen dat een algoritme is gebruikt om de quantization tabel te berekenen. Welk algoritme er exact is gebruikt is afhankelijk van het JPEG-type. Een waarde tussen 128 en 255 betekent dat de quantization tabel wordt meegezonden na de RTP-JPEG-header. zie

30 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 30 Width Width: 8 bits: De breedte van de JPEG-frame. Height Height: 8 bits: De hoogte van de JPEG-frame Restart header Indien de JPEG-type tussen 64 en 127 ligt, dan is de JPEG-data gecodeerd met restart markers. Deze markers zijn nuttig voor wanneer de JPEG-decoder een fout tegenkomt. Dan kan hij doorschuiven naar de volgende slice aan de hand van deze marker. Omdat deze functie niet ondersteund wordt door onze JPEG-encoder, gaan we hier niet dieper op in. De restart header ziet er als volgt uit: Restart Interval F L Restart Count Quantization Table header De quantization tabel header wordt alleen meegezonden met de eerste scan van een JPEG-frame. Dus wanneer de offset gelijk is aan 0. Indien het quanitization (Q) veld een waarde bevat tussen 0 en 127, dan kan je aan de hand van het JPEG-type de quantization tabel worden berekend. Indien de waarde tussen 128 en 255 ligt, dan moeten de quantization tabellen meegegeven worden in een Quantization Table Header. Het aantal quantization tabels die worden meegegeven is afhankelijk van het type MBZ Precision Length Quantization Table Data MBZ: 8bit: moet 0 zijn. Niet gebruikt. Lenght: 16bit: lengte in bytes van de Quantization Table Data (Header niet meegerekend). Kan 0 zijn indien er geen quantization table is meegegeven.

31 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 31 Quantization Table Data: 0 of meerdere Quantization tabels. Precision: 8bit: Voor elke quantization table wordt er een bit gezet in het precisionveld. Voor de eerste tabel is dit het meest rechtse bit (LSB), voor de tweede tabel de tweede meest rechtse bit enz. Indien deze bit op 0 is ingesteld, dan is de coëfficiënt van de tabel te vinden in de laatste 8 bit van de 64 byte tabel. Indien de bit op 1 is gezet, dan zijn het de laatste 16 bit van de 128 byte tabel C++: RTP-JPEG-Decoder Voor dit project moet er een 720p beeld verzonden worden over een 100Mbps netwerk. Daarom is er geopteerd om de beelden te verzenden met JPEG over RTP. In plaats van een bestaande bibliotheek te gebruiken, is er beslist om alles volledig zelf te schrijven. De belangrijkste reden hiervoor is dat zelf geschreven code veel minder resources gebruikt. Dit is belangrijk indien deze beperkt zijn zoals bij een SoC. De implementatie zelf ondersteunt niet alle opties die de RFC beschrijft. Alleen de nodige headers zijn geïmplementeerd: 1. Aangezien er slechts één weg is tussen de camera en de cluster is het onmogelijk dat de volgorde van de pakketten gewijzigd wordt. Er is toch een controle geïmplementeerd indien pakketten niet in de juiste volgorde zouden aankomen, maar herordening gebeurt niet. Indien er toch iets mis is gegaan, dan zal de JPEG-decoder het volledige frame droppen. 2. Er worden twee quantization tables meegegeven. 3. Om de JPEG-data in een JIF-formaat te capsuleren wordt er gebruikgemaakt van de voorbeeldcode die vermeld staat in de RFC. (RFC, 1998b, Appendix B) De volgende code wordt gebruikt om de JPEG-data uit de RTP-frames te halen: Eerst worden de fragmentoffset en de timestamp uit de ruwe UDP data gefilterd: uint32_t fragmentoffset=0 (rawudp[13]<<16 rawudp[14]<<8 rawudp[15]); uint32_t timestamp=(rawudp[4] << 24 ) (rawudp[5]<<16) (rawudp[6]<<8) rawudp[7]; int pakketsize = data->udppackets[data->udpreader]->len; Er wordt gecontroleerd of de sequence nummer gelijk is aan het vorige sequence nummer vermeerderd met 1. Indien dit niet het geval is dan plaatsen we de initialised waarde terug op false. Het programma zal dan wachten tot het opnieuw een volledige JPEG frame kan samenstellen voordat het deze naar de decoder zendt.

32 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 32 if (((rawudp[2] << 8) rawudp[3])!= seq+1){ initialised=false; } seq=(rawudp[2] << 8) rawudp[3]; Er zijn drie mogelijke payloads: De eerste scan van een frame, een tussenscan of de laatste scan. Een eerste scan kan herkend worden aan zijn offset-veld dat op 0 staat. Als de marker bit aan staat dan is de data de laatste scan. Indien het RTP-pakket het eerste deel bevat van een frame, dan moeten de JIF-headers aangemaakt worden. Indien het een tussenstuk is dan moet de JPEG-data gewoon gekopieerd worden. Als de JPEG-data de laatste scan bevat dan moet de code doorgezonden worden naar de decoder. Aangezien er fouten in de RTP offset kunnen zitten, is het nodig om toch nog eens te controleren dat de JIF al zijn headers gegenereerd heeft voordat de data wordt doorgezonden naar de decoder. Anders kan de JPEG-decoder een fatale fout maken, hij zal namelijk de random JPEG-data interpreteren als een JIF-header. De MakeHeader functie kan teruggevonden worden in de JPEG over RTP RFC (RFC, 1998b, Appendix B). int offset=20; if (fragmentoffset==0){ //make headers and write them! uint headerlen = MakeHeaders(jpegFrame->pBuffer, rawudp[16],rawudp[18],rawudp[19], //new frame offset= 24 + (QTH header) + (QTH data) offset=24+(rawudp[22]<<8 rawudp[23]); }else{ //write rest of frame memcpy(jpegframe->pbuffer+headerlen, rawudp+offset, pakketsize-offset); jpegframe->nfilledlen = headerlen + (pakketsize-offset);... initialised=true; if (initialised){ //add the next JPEG Scan to the buffer memcpy(jpegframe->pbuffer+jpegframe->nfilledlen, rawudp+offset, pakketsize jpegframe->nfilledlen += (pakketsize-offset); }else{ //headerpart is gone! } } if ((((rawudp[1] & 128) >> 7)==1) && initialised){ //when marker is set, end of JPEG frame! stop=true; }

33 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN RFC 3984: H.264 over RTP Ook voor een H.264-payload is er een RTP-standaard voorzien. Dit protocol biedt veel meer functies aan dan de JPEG over RTP standaard. Al deze informatie kan teruggevonden worden op en De RFC 6184 (RFC, 2011) is een herwerking van de RFC 3984 standaard. Onderliggend zijn er niet veel veranderingen en doet het er ook niet toe welke RFC er gebruikt wordt. Na de algemene RTP-header die hierboven vermeld werd, volgt de H.264 RTP-header RTP H.264 header F NRI Type F: 1bit: 0: De data bevat geen bit errors. 1: De data kan bit errors bevatten. NRI: 2 bit: de NAL reference id: Dit is een twee bit waarde die de prioriteit van het RTP-pakket aanduidt. Waarde 00 zegt het systeem dat de data onbelangrijk zijn voor de reconstructie van de H.264-stream. Elke waarde groter dan 00 eist dat het frame moet gelezen worden. In ons voorbeeld zijn alle NRI gelijk aan 01. De NRI moet gelijk zijn aan 00 indien het NAL-type gelijk is aan: 6, 9, 10, 11, of 12. TYPE: 5 bits: Het NAL-type. Er bestaan verschillende types van H.264-pakketten. In onderstaande tabel staat een overzicht van alle NAL-Types: NAL Type Packet Type name Section undefined NAL unit Single NAL unit packet per H STAP-A Single-time aggregation packet STAP-B Single-time aggregation packet MTAP16 Multi-time aggregation packet MTAP24 Multi-time aggregation packet FU-A Fragmentation unit FU-B Fragmentation unit undefined - De NAL types van 0-23 zijn reeds uitgelegd in het paragraaf

34 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 34 Voor dit project gebruiken we twee NAL-types: Single NAL unit packet en FU-A. Indien ons H.264 frame in één RTP pakket kan, dus moet het niet gefragmenteerd worden, dan nemen we het type van de oorspronkelijke frame (die altijd tussen 0 en 24 ligt). Deze wordt dan geplaatst in het type-veld. Daarna plaatsen we de H.264 data met optionele padding. Dit is een Single NAL unit packet. Indien onze data te groot is om in één RTP pakket geplaatst te worden, dan wordt deze gefragmenteerd en wordt het type op FU-A (28) geplaatst. Dan volgt er een FU header en daarna pas de gefragmenteerde data. Een FU-B pakket heeft ook een FU header met daarna nog een extra DON (decoding order number) veld. Dit nummer kan gebruikt worden door gateways en routers die een RTP-pakket verder willen opsplitsen in twee pakketten zonder de volledige RTP-sequentienummer aan te moeten passen van het RTP-pakket en al de daaropvolgende RTP-pakketten. Een client moet dan gewoon de waarde van het RTP sequence nummer field en het DON field concateneren om het exacte sequentienummer te weten. De FU-A pakketten kunnen eventueel door een router omgezet worden naar FU-B pakketten indien de MTU van het ene netwerk groter is dan de MTU van het andere netwerk. STAP-A, STAP-B, MTAP16 en MTAP24 zijn types die toelaten om verschillende H.264 delen van opvolgende frames in één RTP-pakket te stoppen. Voor dit project worden deze types niet gebruikt FU header Deze header is alleen nodig indien het NAL-type ingesteld is op 28 (FU-A). De FU-header bestaat uit: S E R Type S: 1 bit: De starbit staat op 1 indien de payload het eerste deel van een frame bevat. E: 1 bit: De endbit staat op 1 indien de payload het laatste deel van een frame bevat. Deze bit is dus altijd identiek aan de RTP marker bit die ook aan staat indien de payload de laatste scan van een frame bevat. R: 1 bit: gereserveerde bit: altijd 0 Type: 5 bit: Het oorspronkelijke NAL-type. Deze waarde ligt tussen 0 en 24.

35 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN Samenvatting Indien we een H.264 frame moeten fragmenteren, dan encapsuleren we de data in een FU-A-pakket die er als volgt uitziet: V=2 P X CC M PT sequence number timestamp synchronization source (SSRC) identifier F NRI 28 (type) S E R Type FU payload :.OPTIONAL RTP padding Indien het H.264 frame in één pakket kan, dan kan deze geplaatst worden in single NAL unit frame die er als volgt uit ziet: V=2 P X CC M PT sequence number timestamp synchronization source (SSRC) identifier F NRI Type FU payload :.OPTIONAL RTP padding C++: RTP H264 encoder Voor we kunnen beslissen of we het H.264 frame moeten fragmenteren, moeten we eerst de maximale grootte van een UDP-pakket kennen. Een NAL-UNIT mag nooit de MTU overschrijven van zijn protocol. Een ethernetpakket heeft als MTU 1500 bytes. Gevolgd door de volgende headers:

36 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 36 IP header: 20 byte UDP header: 8 byte RTP header:12 byte H264 RTP: 1 byte FU header: 1 byte Er resteert dus nog 1458 bytes voor de effectieve RTP-payload. Dit project heeft een sendrtppacket functie die een H.264 frame over RTP verzendt. De data die aangeleverd wordt kan een volledig H.264 frame zijn, of een deel ervan. Het eerste probleem is het verwijderen van de H.264 startcode. Indien de lengte kleiner is dan 3 dan is het zeker dat er geen startcode aanwezig is en de data dus een deel is van het vorige frame. Daarna roept deze functie de processrtppacket functie aan met het H.264 type, dat hij uit de startcode heeft gehaald, als argument. Indien er geen startcode aanwezig was dan wordt het type van het vorige deel gebruikt. void sendrtppakket(char* RTP, uint32_t timestamp,char* databuffer, unsigned int datalen, bool startbit, bool endbit, RTSPClient** RTPClients, int sock, int aantalclients){ static int vorigetyp; if (datalen<3){ //too small to contain a H264 startcode processrtppacket(rtp, timestamp,databuffer,datalen, 0, startbit, endbit,rtpclients }else{ //search H264 startcode int offset=0; if (databuffer[0]==0 & databuffer[1]==0){ while ((databuffer[offset])!=0x0 (databuffer[offset+1])!=0x1){ offset++; } } offset++; offset++; int type=(databuffer[offset])&31 ;// offset++; if (offset!=3){ // H264 startcode, send startcode processrtppacket(rtp, timestamp,databuffer+offset,datalen-offset, 0,startbit, vorigetyp=type; }else{

37 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 37 } } } //No H264 startcode, is part of the previous slice, use previous type. processrtppacket(rtp, timestamp,databuffer,datalen, 0, startbit, endbit,rtpcli De processrtppacket functie fragmenteert (indien nodig) het frame en encapsuleert de data in een H.264-RTP-pakket. void processrtppakket(char* RTP, uint32_t timestamp,char* databuffer, unsigned int datalen, bool singleframe, bool startbit, bool endbit, RTSPClient** RTPClients,int type, int sock, int aantalclients){ static int16_t seqnr; if (datalen > 1394){ //split int i=0; while (((i+1)*1394) < datalen){ processrtppakket(rtp,timestamp,databuffer+(i*1394), 1394, 0, startbit, 0,RTPC startbit=0; i++; } processrtppakket(rtp,timestamp,databuffer+(i*1394), datalen-(i*1394), 0, 0, endbi return; }else{ Indien de grootte kleiner is dan de limiet dan moet deze gecapsuleerd worden in een RTP-pakket: RTP[0]=128; // , Version=10, Padding=0, Extension=0, CC=0000 RTP[1]=96 endbit<<7;//type=96, marker bit RTP[2]=(seqNr&65280)>>8; RTP[3]=(seqNr&255); RTP[4]=(timeStamp >> 24) & 255; RTP[5]=(timeStamp >>16 ) & 255; RTP[6]=(timeStamp >>8) & 255; RTP[7]=(timeStamp & 255); //SSRC RTP[8]=1; RTP[9]=2; RTP[10]=3;

38 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 38 RTP[11]=4; //databuffer int ret; int offset; if (singleframe){ RTP[12]=type 64; offset=13; }else{ RTP[12]=64 28; //0 10 TYPE(5bits) Type van FU-A is 28 RTP[13]=startbit<<7 endbit<<6 type; //S E R Type offset=14; } Daarna wordt de RTP -buffer en de data buffer naar alle toestellen verzonden over UDP. 4.6 Applicatielaag: RTSP RTSP (Real time streaming protocol, (RFC, 1998a)) wordt gezien als een zusterprotocol van RTP. RTP incapsuleert een mediastream en verzendt deze naar een IP-adres. RTSP daarentegen zorgt voor de communicatie tussen de clients en de RTP server. Hij verzorgt als het ware de authenticatie van nieuwe clients en onderhandelt de instellingen van de RTP-stream. Het protocol werkt net als HTTP met commando s die verzonden worden over TCP en die resulteren in exact één antwoordbericht. De belangrijkste commando s die kunnen verzonden worden zijn: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE en TEARDOWN. Een nieuwe client die een RTP-stream wil ontvangen zal dan ook deze commando s in deze volgorde verzenden. RTSP-pakketten hebben steeds dezelfde structuur: OPTIONS rtsp:// RTSP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v ) De eerste regel bevat het RTSP-commando, de URL van de RTSP-stream en daarna de RTSP-versie. Daarna volgen een aantal Sleutel: waarde parameters. Er wordt altijd een CSeq-waarde meegegeven! De reactie van de RTSP-server ziet er als volgt uit:

39 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 39 RTSP/ OK Supported: play.basic, con.persistent Cseq: 1 Server: Wowza Media Server build8031 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER Cache-Control: no-cache Opnieuw is de eerste regel een uitzonderlijke regel. Deze bestaat uit de versie gevolgd door de statuscode. Merk op dat de statuscodes en de berichtindeling dezelfde zijn als bij het HTTP-protocol. Daarna volgen opnieuw een aantal sleutel: waarde regels. Belangrijk is dat er altijd een CSeq-waarde wordt meegegeven. Deze waarde is dezelfde als de CSeq-parameter die werd meegezonden met de request. Na deze headers kan er nog data volgen. Dit kan indien er een content-lenght -waarde aanwezig is. De delimiter tussen de headers en de data zijn twee newlines karakters. Nu we weten hoe het protocol algemeen zijn berichten opstelt kunnen we dieper ingaan op de verschillende commando s en hun antwoord. Nadat de client een TCP-connectie heeft opgezet met de server via poort 554 (standaard) zendt deze zijn eerste bericht. De meeste mediaplayers volgen een vaste sequentie om dat te verzenden. Options: Dit commando vraagt welke RTSP-commando s er ondersteund worden door de server. Deze stap kan eventueel overgeslagen worden indien de client veronderstelt dat de server alle mogelijke commando s ondersteunt. Het describe commando vraagt de RTP-informatie op aan de server. De reactie bevat de omschrijving van de aangeboden stream in SDP-formaat (session description protocol 4.7). Deze data wordt niet meegegeven als parameter maar als extra data. Vanaf deze stap zendt de server ook een session -waarde mee in de header. Alle volgende antwoorden zullen vanaf nu ook deze session-waarde vermelden. Daarna volgt de setup instructie. Deze zet de RTP-verbinding op tussen de client en de server. De client heeft de SDP informatie aanvaard en geeft informatie van zijn kant terug in de Transport -parameter. Een voorbeeld hiervan is: Transport: RTP/AVP;unicast;client_port= De Transport waarde bevat opnieuw meerdere parameters die gescheiden zijn door een ;. RTP/AVP duidt aan dat RTP over UDP moet worden verzonden. Ook RTP over TCP wordt ondersteund om firewalls te omzeilen. De belangrijkste waarde is de client port -parameter. Deze geeft twee poorten terug: de bestemming poort waar de RTP-pakketten naar toe moeten worden gezonden en de bron poort waarvan RTCP-pakketten kunnen komen (zie RTCP 4.8). Het antwoord op een setup bericht bevat ook dezelfde transport header die aangevuld wordt met nog een paar extra velden.

40 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 40 Transport: RTP/AVP;unicast;client_port= ;source= ; server_port= ;ssrc=0dcab11f Deze extra velden zijn het bron IP-adres en de server poorten. De eerste server port is de bron poort vanwaar de RTP-pakketten zullen worden verzonden. De tweede is de RTCP-poort op de server naar waar RTCP-informatie kan worden verzonden. Ook volgt er nadien een SSRC-waarde. Zoals uitgelegd in het hoofdstuk RTP (4.5) is dit de identificatie van een RTP stream. Na een setup request zijn alle gegevens gekend om een RTP-stream te beginnen. Om deze stream te controleren kan de gebruiker drie commando s zenden: Play, Pause en Teardown. Play zorgt ervoor dat de RTP-pakketten worden verzonden naar de client. Dit gebeurt tot de server een teardown commando ontvangt. Bij live streaming is het pause commando redelijk nutteloos, maar deze kan wel praktisch zijn bij een Video On Demand service. Er bestaan nog andere commando s maar met deze selectie is de basis gelegd van een werkende RTSP-server. 4.7 Session description protocol Het session description protocol wordt gebruikt om meer informatie over één of meerdere streams te omschrijven. Het is een tekstuele notatie die omschreven is in RFC 4566 (RFC, 2006). Bij wijze van voorbeeld nemen we de SDP bestand die gebruikt wordt voor dit project. v=0 o= IN IP s=televic RTSP\r\n" c=in IP m=video 0 RTP/AVP 96 a=width:integer;1280 a=height:integer;720 a=cliprect:0,0,720,1280 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=428028; sprop-parameter-sets=j0kakjwgkav+waeje1a=,km4cxia= a=framerate:30.0 a=control:trackid=1 De exacte uitleg over elke parameter staat omschreven in de RFC (RFC, 2006). Indien een H.264-videostream omschreven wordt, dan is er meestal gebruikgemaakt van een dynamisch type. In ons geval omschrijft de SDP het dynamische type nummer 96. Deze gebruikt een klok van 90KHz om de timestamp te bepalen. Ook de framerate en de resolutie

41 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 41 worden vastgezet op respectievelijk 30FPS en 1280*720. De belangrijkste H.264-informatie is terug te vinden in het profile-level-id en de sprop-parameter-sets waarden. Het profile-level-id bevat de eerste, tweede en de derde byte van de SPS (zonder startcode of type) in hexadecimale notatie. De sprop-parameters-set bevatten de SPS en de PPS in base64 encodering (zonder startcode maar met type). Deze twee tekenreeksen worden gescheiden door een komma. 4.8 Applicatielaag: RTCP RTCP (Real-time Transport Control Protocol) is een zuster protocol naast RTP en RTSP. Deze verzendt statistieken over de stream. Zo kunnen jittering en synchronisatieproblemen gerapporteerd worden door Receiver reports te zenden naar de server. Net zoals alle andere protocollen is ook dit protocol omschreven in een RFC (RFC, 2003b). De uitleg over de effectieve pakketsamenstelling van een receiver report zou ons te ver leiden. Het is wel belangrijk om te weten dat een RR RTCP-bericht verzonden wordt door een media player naar een streamserver. Zo n pakket bevat informatie zoals het aantal verloren pakketten, de fractie verloren pakketten, het hoogste ontvangen sequentienummer en de gedetecteerde jitter. 4.9 Applicatielaag: HTTP progressive downloading RTP heeft als grootste nadeel dat het geblokkeerd kan worden door firewalls. Indien UDP geblokkeerd wordt, kan RTP over TCP gebruikt worden. Helaas zijn er ook bepaalde firewalls die alleen HTTP-verkeer doorlaten. HTTP progressive downloading of HTTP progressive streaming is een simpele manier om dit probleem te omzeilen. Dit protocol downloadt gewoon de videostream naar de harde schijf over het HTTP protocol. De meeste mediaplayers kunnen deze stream al afspelen terwijl deze nog gedownload wordt. Het grootste nadeel aan dit protocol is niet het gebruik van TCP (4.2) maar wel dat er geen mogelijkheid is om door te spoelen zonder alle voorgaande frames te downloaden. Voor een Video On Demand service is dit onaanvaardbaar. Voor een live videostream is dit protocol wel bruikbaar. Door zijn eenvoud ondersteunen bijna alle mediaspelers dit protocol. In tegenstelling tot RTP is er bij dit protocol geen indicatie wanneer er een nieuwe frame begint. Daarom moeten JPEG-frames in een container verzonden worden. Zoals reeds aangegeven hoeft dit niet voor een zuivere H.264-videostream aangezien deze streams met startcodes werken om de verschillende frames te identificeren (3.3.2).

42 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN Applicatielaag: HTTP Live Streaming Het HTTP Live Streaming protocol (HLS)(Apple Inc., 2013) (Apple Inc., Geciteerd april 2014) is een protocol dat gebaseerd is op het HTTP progressive downloading protocol maar dat het seek probleem oplost. Dit protocol is dan ook veel gebruikt bij video on demand services. HLS is nog niet goedgekeurd als standaard maar wordt wel al massaal veel gebruikt. De voornaamste reden hiervoor is omdat veel Apple producten dit protocol ondersteunen. Het basisidee is om de video in verschillende stukken te delen en deze apart als downloadbare content te publiceren op een webserver. Er is dan een m3u8 bestand dat aangeeft in welke stukken de mediastream is geknipt met een bijhorende link. Hiernaast is het ook mogelijk om verschillende streams te omschrijven met hun benodigde bandbreedte. Dan kan de client zelf kiezen welke stream hij afspeelt aan de hand van de beschikbare bandbreedte. Alhoewel dit protocol gebruikt wordt om live streams te verzorgen, is dit protocol hiervoor ongeschikt! De videobeelden worden namelijk live verknipt in stukken maar in feite download iedereen op hetzelfde moment hetzelfde stuk. Dit is normaal aangezien de stukken uit de toekomst nog niet gemaakt zijn, en de stukken uit het verleden voor een delay zorgen. Er ligt wel al een link naar deze stukken in het m3u8 bestand. Nu moeten HLS clients minimaal één segment volledig gedownload hebben voordat ze deze mogen afspelen. Meestal is dit een stuk van 10 seconden. Dit resulteert in een constante delay van 10 seconden. Standaard wordt elk stuk in een mpeg-ts container geëncapsuleerd. Deze container wordt ondersteund door alle ios-apparaten. Als voorbeeld nemen we de live stream van deredactie.be. De m3u8-pagina ziet er als volgt uit: #EXTM3U #EXT-X-VERSION:3 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH= #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH= Deze pagina linkt naar twee onafhankelijke streams. Deze zullen dezelfde beelden tonen maar met een andere bitrate. De client kan aan de hand van de bandwidth parameter beslissen welke hij zal afspelen. De gelinkte pagina s zien er zo uit: #EXTM3U #EXT-X-VERSION:3 #EXT-X-ALLOW-CACHE:NO

43 HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 43 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:454 #EXTINF:10.0, media-b800000_454.ts?wowzasessionid= #EXTINF:10.0, media-b800000_455.ts?wowzasessionid= #EXTINF:10.0, media-b800000_456.ts?wowzasessionid= Hier is het duidelijk dat elke stuk 10 seconden duurt. Indien deze pagina opnieuw geladen wordt dan zullen de nummers aangepast worden zodat het laatst aangemaakte deel vanboven vermeld staat als eerste deel Native ondersteuning door mobile devices De markt van de mobiele besturingssystemen wordt gedomineerd door twee besturingssystemen: ios en Android. Deze twee besturingssystemen ondersteunen native enkele protocollen en media formaten. Android IOS (iphone 4) RTSP met RTP JA NEE HTTP Progressive download JA JA HLS Vanaf Android 3, MPEG-TS only JA H264 Baseline only Main 3.1 Voor dit project werd gekozen om met RTP en RTSP te werken aangezien dit formaat goed ondersteund wordt en met externe apps kan afgespeeld worden. Als videocodec is alleen H.264 baseline bruikbaar. De verdere gegevens over deze besturingssystemen kan gevonden worden op: android.com/guide/appendix/media-formats.html voor android en com/kb/sp587 voor IOS.

44 Hoofdstuk 5 GStreamer GStreamer is een multimedia framework. Aan de hand van verschillende componenten (encoders, decoders, I/O-componenten, multiplexers, filters,...) is het mogelijk om heel snel een werkende multimedia oplossing te ontwikkelen. GStreamer is cross platform en is beschikbaar onder de LPGL-licentie. Er zijn verschillende versies van GStreamer. Op moment van schrijven worden volop de versies 0.10 en 1.0 gebruikt. De nieuwste versie (1.2) is beschikbaar maar is nog niet verspreid onder de officiële repositories. Een groot nadeel is dat de versies onderling niet compatibel zijn. Zo worden er per versie plug-ins van naam veranderd en veranderen er eigenschappen van componenten. Een ander groot nadeel is de relatief slechte documentatie. Op moment van schrijven is versie 1.2 de laatste nieuwe release maar is de documentatie nog geschreven voor versie 1.0 en sommige delen zelfs voor versie Dit is één van de redenen waarom de developers gestart zijn met GStreamerSDK. Dit is de GStreamer 0.10 met een deftige documentatie. GStreamer kan op twee manieren worden aangesproken: via een programmeeromgeving of via de terminal. Zo kan je het compileren in een C++ programma of kan je snel een GStreamer server maken via de commandline. Dit heeft als grote voordeel dat je eerst een GStreamer tunnel kan proberen op de commandline en wanneer deze werkt deze kan omgezet worden naar een C++ programma. 5.1 Principe Zoals vermeld werkt GStreamer met een verzameling van plug-ins ( freedesktop.org/documentation/plugins.html ). De bedoeling is om een tunnel te maken met deze plug-ins. Een GStreamer-tunnel start altijd met een source-component(naam eindigt op src) die je dan piped naar verschillende andere componenten. Als laatste component word er altijd een sink geplaatst. 44

45 HOOFDSTUK 5. GSTREAMER 45 Elke component die geen sink of source element is, heeft dus één of meerdere in- en uitgangen. Een source element heeft geen ingangen en een sink element heeft geen uitgangen. In de opdrachtprompt kan je de tunnel oproepen door het gst-launch-1.0 (of gst-launch-0.10 voor versie 0.10 of de GStreamer SDK) commando uit te voeren met als enige argument de tekstuele omschrijving van een tunnel. Een tunnel is samengesteld door de namen van de gebruikte componenten gescheiden door een!. Indien een component meerdere output eigenschappen heeft (denk maar aan een webcam die meerdere resoluties ondersteunt) dan kan je expliciet vermelden welke eigenschap je wil gebruiken door het plaatsen van een caps. Indien er geen caps aanwezig is dan zal GStreamer zelf proberen een goede uitgang te kiezen. Dit kan hij weten door de invoer eigenschappen van de volgende component te bekijken. De invoer en uitvoer eigenschappen van een component kunnen teruggevonden worden in de documentatie of via het gst-inspect commando. De laatste methode geniet de voorkeur aangezien deze meestal meer up-to-date is dan de documentatie die online te vinden is. Een tunnel die vaak gebruikt werd voor dit project is de onderstaande: gst-launch-1.0 -v v4l2src device=/dev/video0! video/x-raw,width=1280,height=720,framerate=30/1! videorate! timeoverlay text="tijd:"! jpegenc! rtpjpegpay! udpsink host= port=1234 multicast-iface=eth0 force-ipv4=true Als eerste component staat een Video For Linux 2 source component (V4l2src). Deze kan een door linux erkende webcam aanspreken. De gebruikte webcam ondersteunt de mogelijkheid om, in plaats van ruwe pixels, de data reeds als JPEG-gecodeerde data aan te leveren. Ook zijn er verschillende resoluties mogelijk. Dit resulteert dus in meerdere mogelijkheden als uitvoer voor het V4l2src component. Daarom is er een caps geplaatst om de juiste stream te selecteren. Indien er in de caps een resolutie zou geplaatst worden die niet door de hardware ondersteund wordt, dan wordt er een foutmelding gegenereerd. De raw 720p beelden worden daarna doorgestuurd naar een videorate component. Deze weet dat de framerate is ingesteld op 30fps, en zal dan ook proberen per 33ms een frame als uitvoer te zenden. Indien hij geen nieuwe frame heeft ontvangen, dan zal hij de vorige frame opnieuw verzenden. Deze frameratestabilisator is nodig om de metingen onafhankelijk te maken van de gebruikte webcam. De enige reden waarom we de ingebouwde JPEG-encoder van de webcam niet gebruiken is omdat we willen gebruikmaken van de timeoverlay component. Deze plaatst op elke inkomende frame de timestamp van dit moment. Dit kan gebruikt worden om later de totale delay te meten van de transcoder. Dit component aanvaardt alleen raw data als invoer. De ruwe beelden, met timestamp, worden daarna door een JPEGenc component gecodeerd volgens de JPEG-methode. RTPJPEGPay zal deze frames encapsuleren in een RTP-pakket (4.5.1) en deze worden daarna door de udpsink verzonden naar een multicastadres.

46 HOOFDSTUK 5. GSTREAMER Voorbeelden Voor dit project worden er verschillende GStreamer programma s gebruikt. Deze zijn bijvoorbeeld verantwoordelijk om RTP-MJPEG-data aan te leveren aan de transcoder en de terugkerende stream af te spelen op het scherm GStreamer streamservers gst-launch-1.0 -v v4l2src device=/dev/video0! video/x-raw,width=1280,height=720,framerate=30/1! videorate! timeoverlay text="tijd:"! jpegenc! rtpjpegpay! udpsink host= port=1234 multicast-iface=eth0 force-ipv4=true Dit script wordt gebruikt om een timestamp (nauwkeurig tot op de milliseconde) te plaatsen op de live beelden die de webcam waarneemt. Deze worden dan geëncapsuleerd in een RTP-pakket en verzonden naar een multicastadres zodat alle transcoders deze kunnen ontvangen. gst-launch-1.0 -v filesrc location="big_buck_bunny_1080p_surround.avi"! decodebin! videoscale! videorate! video/x-raw,width=1280,height=720,framerate=30/1! timeoverlay text="tijd:"! videoconvert! jpegenc! queue! videorate! image/jpeg,framerate=30/1! queue! rtpjpegpay! udpsink host= port=1234 multicast-iface=eth0 force-ipv4=true Dit script doet quasi hetzelfde als het vorige maar gebruikt in plaats van webcambeelden, een film van op de harde schijf. Omdat deze beelden in een AVI-container zitten, en H.264 gecodeerd zijn, moet deze datastream eerst gedecodeerd worden. Dit kan via een avidemux! avdec h264 tunnel, maar gemakkelijker is om gebruik te maken van decodebin die dit automatisch detecteert. De uitgaande stream is een raw pixel video stream. Met het videoscale commando kan elke ruwe frame geresized worden tot de gewenste grootte die meegegeven is in de caps. In dit voorbeeld gebruiken we twee videorate componenten. Eén voor en één na de JPEG-encoder. Dit komt omdat het coderen in JPEG niet met een constante snelheid gebeurd indien de beelden erg variëren. Je kan dit zien als een dubbele stabilisator GStreamer cliënts Omdat we meer controle en mogelijkheden willen dan met de standaard VLC media player, zijn er ook een paar media players gemaakt om aan de client-zijde de inkomende stream op het scherm te tonen.

47 HOOFDSTUK 5. GSTREAMER 47 gst-launch-1.0 -v udpsrc multicast-group= port=1234 caps="application/x-rtp, media=(string)video,encoding-name=(string)jpeg" multicast-iface=eth0! rtpjpegdepay! jpegdec! videoconvert! videoscale! textoverlay text=srv valignment=top! fpsdisplaysink sync=false Dit script schrijft zich in op het multicast adres en ontvangt zo de JPEG over RTP-pakketten. Deze worden uit de RTP-pakketten gehaald en gedecodeerd. Daarna wordt er een tekst op de frames geplaatst ( SRV ) en worden deze via de fpsdisplaysink op het scherm getoond. Deze sink heeft als voordeel dat ook de gemiddelde framerate en de momentele framerate zichtbaar zijn. De eigenschap sync=false vertelt dat er geen rekening moet worden gehouden met de timestamp die meegegeven worden in de RTP-header. Aangezien de timestamps correct gegenereerd werden door de streamserver is deze eigenschap in feite overbodig. gst-launch-1.0 -v udpsrc port=3000! application/x-rtp, payload=96! rtph264depay! avdec_h264! fpsdisplaysink sync=false Indien er een videostream verzonden word naar een bepaald IP-adres en een poort, dan is het mogelijk om met bovenstaand script dit te tonen op het beeldscherm. Het enige verschil met het vorige programma is dat we nu avdec h264 moeten gebruiken i.p.v. jpegdec aangezien de uitgaande stream van onze transcoder een H.264-stream is. Ook hier kan eventueel een sync=false parameter geplaatst worden indien de timestamps van de uitgaande RTP-pakketten niet volledig accuraat zijn.

48 Hoofdstuk 6 Raspberry Pi Als SoC werd gekozen voor de Broadcom BCM2835. Deze processor werd beroemd als het systeem achter de Raspberry Pi. Specificaties van de CPU: Single core van 700 MHz ARM1176JZF-S ARM 11 type (dus ARMv6 architectuur) Opstartbaar via een SD kaart 512MB RAM (gedeeld met GPU) 100Mbps ethernet poort 700 ma (3.5 W) stroomverbruikt Twee USB poorten Aangezien de CPU een ARM-architectuur is, moeten alle programma s gecompileerd worden voor deze CPU familie. Momenteel zijn er al een paar linux distributies beschikbaar. De meest gebruikte zijn debian en ArchLinux. Er is 512 MB RAM aanwezig op deze SoC. De oudere RPI (voor 15/10/2012) hebben slechts 256 MB RAM. Dit geheugen is gedeeld met de GPU. Een kanttekening moet wel gemaakt worden bij de twee USB poorten. De ethernet en deze USB-poorten zitten namelijk op dezelfde bus. Dit wil zeggen dat ook hun bandbreedte verdeeld is (ppumkin, 2013). Specificaties van de GPU: 48

49 HOOFDSTUK 6. RASPBERRY PI 49 Dual Core VideoCore IV R Multimedia Co-Processor Ondersteuning voor OpenGL-ES R 1.1/2.0 HDMI uitgang Het belangrijkste voor dit project is de mogelijkheid om de ingebouwde encoders en decoders aan te spreken. Dit kan via OpenMAX (7). De volgende componenten worden ondersteund: Codec HW / SW Port IN Port OUT Licentie MPEG2 dec HW MPEG2 licentie (2.40 pound) H263 dec HW Meegeleverde licentie H264 dec HW Meegeleverde licentie Ogg Theora dec SW Meegeleverde licentie VP6 / VP8 dec SW License free JPEG dec SW License free VC1 dec HW VC-1 licentie (1.20 pound) H264 enc HW Meegeleverde licentie Resize Deze informatie is samengesteld uit verschillende bronnen aangezien er geen officiële documentatie hierover beschikbaar is. (Gstreamer OpenMax plug-in team, Geciteerd april 2014) (CNXSoft, 2013) Het verschil tussen HW en SW is waar de code exact wordt uitgevoerd. Sommige encoders zijn namelijk volledig geïntegreerd in de GPU. Andere codecs zijn in de software geprogrammeerd maar gebruiken de GPU om de zware berekeningen te doen. De poorten die vermeld staan zijn de OpenMAX poorten 7. Qua licentiekosten zijn de license free codecs gratis te gebruiken. De Raspberry Pi foundation heeft ervoor gekozen om de H.264 codec mee te leveren in de prijs van de Raspberry Pi. Er is ook de mogelijkheid om een VC1 of MPEG2 licentie te kopen zodat er bepaalde extra features beschikbaar worden. Deze sleutel is gebonden aan de serienummer van de SoC en is dus niet overdraagbaar.

50 Hoofdstuk 7 OpenMAX Net zoals OpenGL, WebGL en OpenCL wordt OpenMAX beheerd door de Khronos group. Deze non-profit organisatie is een samenwerking tussen verschillende bedrijven om open standaarden te creëren. Net zoals Adobe, canonical, EA en Google is broadcom ook lid van deze groep. Bij de ontwikkeling van de broadcom VideoCore IV is er dan ook voor geopteerd om deze standaard te gebruiken. Meer specifiek moet er gebruik worden gemaakt van de OpenMAX Integration Layer om te communiceren met de ingebouwde hardware componenten. Er is geen wijde ondersteuning voor systemen die OpenMAX ondersteunen. Op het moment van schrijven staan er slechts twee voorbeeldcodes online voor de Raspberry Pi: een H.264 encoder (hello encode) en een JPEG-decoder (hello jpeg). Hun code is beschikbaar op de github van het Raspberry Pi project. In het hoofdstuk Implementatie wordt hier dieper op ingegaan. Broadcom voorziet een ILClient library die een laag vormt tussen de applicatie en de OpenMAX core. Deze bibliotheek maakt het gemakkelijker om de OpenMAX-componenten aan te spreken door veel gebruikte sequenties van instructies te groeperen in één functie. Bijvoorbeeld het uitzetten van een poort kan in slechts één operatie in plaats van twee indien OpenMAX rechtstreeks gebruikt wordt. In dit hoofdstuk worden de algemene principes van OpenMAX IL uitgelegd zoals beschreven in hun specificatie. (The Khronos Group Inc, 2005) 7.1 Algemeen Elk component (decoders, encoders, resizers) die geïmplementeerd zijn in de driver kunnen worden aangesproken via OpenMAX IL. Elke component heeft een aantal in en uitgangen die geïdentificeerd worden aan de hand van een poortnummer. Dit nummer is te vinden in de 50

51 HOOFDSTUK 7. OPENMAX 51 documentatie van de gebruikte SoC. Voor de Raspberry Pi is deze informatie te vinden op Elke component is altijd in een zekere staat (zie figuur 7.1). Figure 7.1: OpenMAX states (The Khronos Group Inc, 2005) Elke component start unloaded. Nadat deze aangemaakt wordt, zal deze naar de loaded staat gaan. Onmiddellijk daarna kan de staat manueel op idle gezet worden. In de idle stand kunnen alle parameters van een component geconfigureerd worden. Uitzonderlijk zijn er ook eigenschappen die kunnen veranderd worden in de executing staat. Nadat alle eigenschappen aanvaard zijn, kan het component in de executing staat worden geplaatst. In deze staat kan er data aangeleverd worden aan de component. In de executing staat is het ook mogelijk dat er callbacks worden gegenereerd bij bepaalde gebeurtenissen. Elke poort van een component is standaard disabled. Ook deze moeten enabled worden! De exacte volgorde om een component aan te maken is dus als volgt: 1. Initialisatie van de library 2. Aanmaken van het component 3. Zet staat op IDLE 4. Instellen van alle parameters 5. Aanzetten van de poorten 6. Zet component in executing staat Aanzetten van de poorten kan alleen indien de component zich in de idle toestand bevindt. Eenmaal alle poorten aan staan en de component in de executing toestand bevindt, kan er data in de component gepompt worden. Dit gebeurt door eerst de buffer, die gelinkt is aan de invoer poort, te vullen met data. Daarna moet het EmptyThisBuffer commando verzonden