low cost multirate video transcoder met parallelle...

Academiejaar 2013–2014 Faculteit Ingenieurswetenschappen en Architectuur

Valentin Vaerwyckweg 1 – 9000 Gent

Low cost multirate video transcoder

met parallelle hardwareversnelling

Promotoren: ing. Wim VAN DEN BREEN

ir. Paul BECUE (Televic conference)

dr. ir. Pieter DEMUYTERE (Televic conference)

Wouter DERYCKERE

Masterproef voorgedragen tot het behalen van het diploma van

Master in de industriële wetenschappen: informatica

Powered by TCPDF (www.tcpdf.org)

Woord vooraf

Een masterproef is nooit het werk van een persoon alleen. Daarom zou ik graag verschillendemensen willen bedanken voor hun bijdrage aan dit project.

Ten eerste wil ik mijn stagebedrijf Televic en zijn medewerkers bedanken voor de kans die zemij hebben gegeven. Toen ik hen voor de eerste keer contacteerde werd ik met open armenontvangen. Persoonlijk kon ik mij geen betere stageplaats voorstellen. Alle communicatiewas perfect, het aangeboden projectvoorstel was uitdagend en nooit werd ik aanzien als eengratis werkkracht. Ook het feit dat ze speciaal materiaal hebben aangekocht is een blijk vangroot 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 expertzocht. 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 voorde 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 zemij de kans hebben gegeven om deze opleiding te volgen maar ook voor de morele steun inmindere tijden.

Als laatste heb ik ook nog een dankwoord voor mijn medestagiaires bij Televic die zorgdenvoor de goede sfeer op de werkvloer. Samen lachen, een babbeltje slaan maar ook het delenvan frustraties. Dankzij hen vertrok ik elke dag met plezier richting Televic.

4

Abstract

Deze scriptie is het naslagwerk van mijn masterproef over de implementatie van een videotranscoder 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 verschillendemobiele toestellen. Elke transcoder in de cluster gebruikt andere parameters zodat er uit hetsysteem 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 componentenin de GPU gebeurt via OpenMAX. De clusterlogica gebruikt een master-slave structuur encommuniceert via TCP-berichten.

Dit project concludeert dat het mogelijk is om met een kleine investering toch een clusterte bouwen die diverse hoge kwaliteit videostreams kan aanbieden. Dit met een minimalevertraging.

5

Inhoudsopgave

Woord vooraf 4

Abstract 5

Lijst met figuren 9

1 Inleiding 10

2 Het concept 11

3 Van bits tot videostream 133.1 Kleurruimte: RGB en YUV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Resolutie en framerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Videocodecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1 MJPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1.1 JPEG-codec . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1.2 JIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2 H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2.1 H.264 frames . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2.2 H.264 profielen en levels . . . . . . . . . . . . . . . . . . . . . 183.3.2.3 H.264 levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.2.4 SODB, RBSP en NAL units . . . . . . . . . . . . . . . . . . 203.3.2.5 SPS en PPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Bestandsformaten en media containers . . . . . . . . . . . . . . . . . . . . . . 25

4 Netwerk en stream protocollen 264.1 Netwerklaag: IP multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Transportlaag: TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Transportlaag: UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Transportlaag: UDP jumbograms . . . . . . . . . . . . . . . . . . . . . . . . . 274.5 Applicatielaag: RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5.1 RFC 2435: JPEG over RTP . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1.1 RTP-JPEG-header . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1.2 Restart header . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.1.3 Quantization Table header . . . . . . . . . . . . . . . . . . . 314.5.1.4 C++: RTP-JPEG-Decoder . . . . . . . . . . . . . . . . . . . 32

4.5.2 RFC 3984: H.264 over RTP . . . . . . . . . . . . . . . . . . . . . . . . 34

6

INHOUDSOPGAVE 7

4.5.2.1 RTP H.264 header . . . . . . . . . . . . . . . . . . . . . . . . 344.5.2.2 FU header . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.2.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.2.4 C++: RTP H264 encoder . . . . . . . . . . . . . . . . . . . . 36

4.6 Applicatielaag: RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7 Session description protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8 Applicatielaag: RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.9 Applicatielaag: HTTP progressive downloading . . . . . . . . . . . . . . . . . 424.10 Applicatielaag: HTTP Live Streaming . . . . . . . . . . . . . . . . . . . . . . 434.11 Native ondersteuning door mobile devices . . . . . . . . . . . . . . . . . . . . 44

5 GStreamer 455.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Voorbeelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.1 GStreamer streamservers . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2 GStreamer cliënts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Raspberry Pi 49

7 OpenMAX 517.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.4 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.5 ILclient vs native OpenMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.5.1 Implementatie in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.5.1.1 Opstarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5.1.2 Ophalen en wijzigen van eigenschappen . . . . . . . . . . . . 567.5.1.3 Opzetten tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 57

8 Implementatie van de transcoder 598.1 Algemene structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598.2 Parameters video encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618.3 Fase 1: RTPToFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628.4 Fase 2: Implementatie van de transcoder . . . . . . . . . . . . . . . . . . . . 62

8.4.1 Implementatie 1: Frame per frame . . . . . . . . . . . . . . . . . . . 638.5 Implementatie 2: Frame per frame met timeout . . . . . . . . . . . . . . . . 658.6 Implementatie 3: Meerdere frames . . . . . . . . . . . . . . . . . . . . . . . 658.7 Implementatie 3: Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.7.1 Performantie: delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.7.1.1 Meten van delay . . . . . . . . . . . . . . . . . . . . . . . . 698.7.1.2 Meetresultaten . . . . . . . . . . . . . . . . . . . . . . . . . . 708.7.1.3 Oplopende delay bij andere resolutie . . . . . . . . . . . . . . 708.7.1.4 Oplopende delay: het Resize component . . . . . . . . . . . . 708.7.1.5 Encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.7.1.6 Oplopende delay: het probleem . . . . . . . . . . . . . . . . . 71

8.8 Implementatie 4: Events zonder oplopende delay . . . . . . . . . . . . . . . . 75

INHOUDSOPGAVE 8

8.8.1 Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758.9 Implementatie 5: Performantie update RTSP sink . . . . . . . . . . . . . . . 77

9 GStreamer en OpenMAX 789.1 Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10 Clustering 8110.1 Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8110.2 Opstelling adaptive bitrate streaming . . . . . . . . . . . . . . . . . . . . . . . 8110.3 Implementatie adaptive bitrate streaming . . . . . . . . . . . . . . . . . . . . 8210.4 Javascript bandwidth sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8310.5 Implementatie protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

11 Beoordeling van het systeem 8611.1 Delay van het netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8611.2 Bottleneck 1: ethernet poort van de Raspberry Pi . . . . . . . . . . . . . . . 8611.3 Bottleneck 2: CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

12 Conclusie 89

Bibliografie 90

Lijst met figuren

2.1 Schematische voorstelling van het concept . . . . . . . . . . . . . . . . . . . . 12

3.1 JPEG coding (HCL Technologies Ltd, Geciteerd april 2014) . . . . . . . . . . 163.2 H.264 profielen (Ozer, 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 RBSP (Raw Byte Sequence Payload) (codesequoia, Geciteerd april 2014) . . 213.4 NAL Unit (codesequoia, Geciteerd april 2014) . . . . . . . . . . . . . . . . . . 233.5 NALByteStream (codesequoia, Geciteerd april 2014) . . . . . . . . . . . . . . 233.6 Sequence parameter set (International telecomunication union, 2010, Tabel

7.3.2.1.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.1 OpenMAX states (The Khronos Group Inc, 2005) . . . . . . . . . . . . . . . 52

8.1 Structuur applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.2 Quantization Parameter (Pixeltool, Geciteerd april 2014) . . . . . . . . . . . 618.3 Rate controller (Pixeltool, Geciteerd april 2014) . . . . . . . . . . . . . . . . . 628.4 Delay afhankelijk van de uitvoerresolutie . . . . . . . . . . . . . . . . . . . . . 718.5 CPU idle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.6 Oplopende delay bij de crop of resize functie . . . . . . . . . . . . . . . . . . . 738.7 Delay van de encoder bij verschillende bitrates . . . . . . . . . . . . . . . . . 748.8 Delay van de encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.1 OpenMAX: Delay van de transcoder . . . . . . . . . . . . . . . . . . . . . . . 799.2 OpenMAX: Framerate van de transcoder . . . . . . . . . . . . . . . . . . . . . 80

11.1 CPU idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

9

Hoofdstuk 1

Inleiding

Mobile devices, zoals een smartphone of tablet, zijn de dag van vandaag niet meer weg tedenken uit onze maatschappij. Omwille van hun beperkte schermresolutie en rekenkrachtis een livestream verzorgen voor zo’n toestel niet eenvoudig. Ten eerste is er de beperktebandbreedte van draadloze communicatie kanalen zoals 3G en WIFI. Daarnaast is er ookde beperkte rekenkracht om bijvoorbeeld videobeelden te decomprimeren. Een bijkomendprobleem is de beperkte native ondersteuning van protocollen en media codecs. Om eengoede live ervaring te garanderen voor elk mobiel toestel moet een streamserver dus meerderestreams aanbieden met verschillende parameters zoals kwaliteit en beeldresolutie. Dit isbijvoorbeeld mogelijk bij youtube waar alle filmpjes op voorhand gecodeerd werden metverschillende resoluties. Voor live beelden is het vooraf coderen niet mogelijk omdat er slechtseen minimale vertraging getolereerd wordt tussen de realiteit en de getoonde videobeelden.

Televic conference NV is expert in het ontwikkelen van verschillende conferentiesystemen. Ditgaat van draadloze microfonen tot volledige conferentiesystemen met live video streaming,stemmodule en de mogelijkheid om documenten onderling te delen. Omdat ook televic zoektnaar een oplossing om de ideale live ervaring naar mobiele toestellen te brengen, werd dezemasterproef voorgesteld. Het project zelf is een Proof Of Concept, dus er wordt niet verwachtdat er een marktklaar product wordt ontwikkeld, maar wel om aan te tonen dat het projectin praktijk te implementeren is. De beste manier om dit aan te tonen is het zelf ontwikkelenvan een prototype.

De eerste hoofdstukken van deze scriptie leggen de verschillende concepten, protocollen enmedia frameworks uit die gebruikt werden in dit project. Daarna volgt de uitleg over deeffectieve implementatie waar zowel de code om te transcoderen als de clusterlogica zullenworden uitgelegd. Als laatste volgt de conclusie over de haalbaarheid van dit concept.

10

Hoofdstuk 2

Het concept

Momenteel zijn er geen mogelijkheden om de live videobeelden uit het conferentiesysteem vanTelevic on the fly te coderen en te verzenden naar meerdere clients. Het coderen van deze livevideostream 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 éé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 één zware transcoding server omdat ermeerdere processoren gebruikt worden die een veel lager verbruik hebben.

Elke System on a Chip (SoC) zal onafhankelijk van de andere SoCs de inkomende streamcoderen. 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 benodigdebandbreedte. Daarna zal elk mobiel toestel die live wil meekijken onderzocht worden doorhet systeem. Deze zal de best mogelijke stream voor het toestel selecteren en die zenden naarde client.

Een ideale stream wordt ervaren indien het beeld vloeiend afspeelt en de vertraging tussen derealiteit 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 wilzeggen dat de wiskundige berekeningen die nodig zijn voor te (de)coderen niet door de trageCPU maar door de snellere GPU worden gedaan.

Als SoC werd de Raspberry Pi voorgesteld. Deze SoC heeft naast een CPU ook een zwareGPU met ingebouwde hardware encoders en decoders.

11

HOOFDSTUK 2. HET CONCEPT 12

Figure 2.1: Schematische voorstelling van het concept

Hoofdstuk 3

Van bits tot videostream

In dit hoofdstuk gaan we dieper in op de algemene technieken die gebruikt worden bijeen digitale progressive videostream. Al deze technieken kunnen onderverdeeld worden inverschillende lagen. Onderaan vinden we de colorspace of kleurruimte, dit is de methode diebeschrijft hoe elke pixelkleur gedefinieerd wordt in het geheugen. In de volgende fase kaner optioneel een codec gebruikt worden die de frames comprimeert. Eenmaal we een stroomvan 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 schijfworden 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, Geciteerdapril 2014) (Microsoft, 2011). Elk frame dat uit een videostream komt is een onafhankelijkeafbeelding. Een afbeelding bestaat uit een bepaalde resolutie van pixels. Er bestaan verschillendemethodes om dat pixel om te zetten naar een bitwaarde. Om het kleur te definiëren moet depixel gelokaliseerd worden in een bepaalde kleurruimte.

Al deze kleurruimtes kan je verdelen onder meerdere categorieën, de twee bekendste zijn:RGB en YUV. Bij RGB wordt er een rood(R), groen(G) en blauw(B) kanaal uit de pixelgefilterd. 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 paarbits gereserveerd die overeenkomen met de waarde van een van de drie kleurkanalen. Soms iser ook een alpha kanaal die de doorzichtigheid van de pixel bevat. Deze wordt aangeduid alsalpha (A). Een paar bekende kleurruimtes zijn:

• ”RGB 24” bevat 24 bits per pixel, namelijk 1 byte per kleurkanaal

13

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 deY-, U- en V-waarden na elkaar. Dit is vergelijkbaar met wat RGB doet. Bij een planarformaat zijn er 3 onafhankelijke kanalen met waarden. Eén voor alle Y-waarden, één vooralle U-waarden en één voor alle V-waarden. Meestal worden deze 3 kanalen daarna gewoon naelkaar geplaatst in een buffer. In OpenMAX (7) bestaan er ook semiplanar formaten. Dezehebben een rij voor alle Y-waarden, en één voor de U- en V-waarden. (Maemo, Geciteerdapril 2014)

Bij RGB wordt de pixelkleur gemaakt door 3 kleuren te mengen. Hoe groter de waarde, hoegroter dit kanaal zijn aanwezigheid mag tonen. Bij YUV is dit anders. Daar wordt de kleuraangeduid door de combinatie van de U- en V-waarden. Daarna wordt aan de hand van deY-waarde de kleur lichter of donkerder gemaakt.

YUV wordt vaak gecombineerd met downsampling. Dit is een eenvoudige manier van beeldcompressie. Aangezien het menselijk oog minder gevoelig is aan chrominantieverschil, wordener voor de U- en V-waarden minder bits gebruikt dan voor de Y-waarde. Bij subsamplingwordt niet voor elke individuele pixel een chrominatie waarde berekend. Een subsamplingvan twee betekend dat alleen de chrominantie waarden van de even pixels zullen gestockeerdworden. 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 VerticaalY Sample periode 1 1V Sample periode 2 2U Sample periode 2 2

Deze tabel toont aan dat bij I420 alle Y-pixelwaarden gebruikt worden. Alleen indien de rijen kolom index even zijn dan zullen de U en V waarden ook gebruikt worden. Dit is eeneenvoudige manier om het datagebruik te minimaliseren zonder aan groot kwaliteitsverlies telijden.

Als je weet dat het aantal pixels (de resolutie) in een afbeelding gelijk is aan de hoogte maalde 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 hoogte2 ∗

breedte2 . Als je veronderstelt dat elke waarde

exact 1 byte inneemt dan is het aantal bits per pixel gemakkelijk te berekenen. Namelijk:resolutie+ resolutie

4+ resolutie

4resolutie , 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 dereferentiewaarde waar de andere waarden zullen aan gestaafd worden, meestal is dit 4. A is hetaantal chrominantiewaarden in een even rij van J-pixels. B is het aantal chrominantiewaarden


in een oneven rij van J pixels lang. In ons voorbeeld zijn er in een even rij van vier pixelslang twee chrominantiewaarden. Een oneven rij van vier pixels lang bevat er geen. Dus kandit 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 http://www.fourcc.org/yuv.php.

3.2 Resolutie en framerate

De framerate van een videostream is het aantal frames die per seconde getoond worden. Ditis uitgedrukt in Frames Per Second (FPS).

De resolutie is de breedte en de hoogte van het frame. In de onderstaande tabel staat eenlijst van standaard resoluties met hun bijhorende aspect ratio.

Naam Resolutie Aspect ratioVGA 640*480 4:3HD 720 1280*720 16:9HD 1080 1920*1080 16:94K UHDTV 3840*2160 16:98K UHDTV 7680*4320 16:9

3.3 Videocodecs

Een codec is een manier om data te comprimeren of te decomprimeren. Compressie wordtbijna altijd gebruikt om minder bandbreedte of schijfruimte te verbruiken. Zo heeft een raw720p videobeeld dat een framerate van 30 FPS heeft en I420 als colorspace gebruikt, eenbandbreedte nodig van 316Mbps. Deze waarde kan je bekomen door de bits per pixel tevermenigvuldigen met de resolutie en de framerate. Het dus onmogelijk om raw 720p testreamen over een normaal 100Mbps ethernet netwerk.

Voor dit project maken we gebruik van 2 videocodecs: MJPEG en H.264. Aangezien hetcoderen en decoderen door externe bibliotheken of door de hardware wordt gedaan, zullen weniet dieper ingaan op de wiskundige bewerkingen van deze codecs. Toch is het nodig om dealgemene methodes te begrijpen.

http://www.fourcc.org/yuv.phphttp://www.fourcc.org/yuv.php


3.3.1 MJPEG

De gemakkelijkste codec om te gebruiken is Motion JPEG (MJPEG), niet te verwarren metMPEG. Deze methode houdt in dat elk frame onafhankelijk van de andere frames gecodeerdwordt via de JPEG-codeer methode.

JPEG zelf is een goede compressie codec om te gebruiken bij afbeeldingen. Toch is MJPEG eenslechte codec voor video’s. De belangrijkste reden hiervoor is dat de compressie onafhankelijkis van de veranderingen tussen opeenvolgende frames. Zo zal de compressie van een filmmet altijd dezelfde frame enorm slecht zijn in vergelijking met bv MPEG1, MPEG2 of H.264die wel rekening houden met variaties tussen opeenvolgende frames. Toch wordt deze codecvaak gebruikt. Het grootste voordeel aan MJPEG is zijn eenvoud. Zo moeten er geen vorigeframes 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 debandbreedte 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 100Mbpsnetwerk. Aangezien JPEG geen vaste minimum compressiefactor aanbiedt, is het dan ookniet zeker dat de benodigde bandbreedte onder de 100Mbps blijft.

3.3.1.1 JPEG-codec

JPEG gebruikt twee methodes om data te comprimeren. De belangrijkste is de mogelijkheidom 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


lossy compressiemethode.

De volgende fase is de quantization fase. Elke waarde uit de matrix wordt gedeeld dooreen waarde uit de quantization matrix. Door gebruik te maken van een andere quantizationtabel kan de kwaliteit van de afbeelding verlaagd worden. Dit resulteert in veel nullen in derechteronderhoek van de matrix.

Daarna worden er nog een paar andere compressietechnieken toegepast. De belangrijkste isde huffman codering. Deze compressiemethode stelt een frequentietabel op van alle mogelijkewaarden die in de data voorkomen. Uit deze frequentietabel wordt dan een boomstructuuropgebouwd. De waarde die het meest voorkomt krijgt de kortste bitwaarde (0 of 1). Hoeminder frequent een waarde voorkomt, hoe langer de bitwaarde die gebruikt zal worden omde waarde voor te stellen.

3.3.1.2 JIF

Uit de vorige afbeelding (3.1) is af te leiden dat een JPEG-bestand een samenraapsel is vande effectieve data, headers, quantization matrixen en huffman tabellen. Dit bestandsformaatwordt omschreven als de JPEG Interchange Format (JIF). Ook voor dit project moeten weonze data encapsuleren volgens het JIF-formaat.

Het JIF-formaat wordt beschreven in de ”ISO/IEC 10918-1: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 aande startwaarde ”FF D8”. Daarna volgen er verschillende blokken met data. De eerste tweebytes van elk blok bevatten altijd een marker om aan te duiden wat de volgende data preciesinhoudt. Zo heb je een marker voor een quantization tabel (FF DB), een huffman tabel (FFC4), enz. Alle mogelijke markers kan je terugvinden in de JPEG-standaard.

Er zijn varianten op dit bestandsformaat zoals JFIF (ISO/IEC 10918-5 - JPEG Part 5) enEXIF (JEITA CP-3451).

3.3.2 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 uitverschillende 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


Al deze standaarden kan je terugvinden onder de ISO/IEC-norm nummer 14496. Voorsommige 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 14496-10:2012” of ”T-REC-H.264-201003-I”(International telecomunication union, 2010).

3.3.2.1 H.264 frames

Er bestaan 3 types van frames. Het type is afhankelijk van welke informatie er nodig is omhet 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. MJPEGdaarentegen 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 hetbij sommige H.264 profielen (zie afbeelding 3.2) mogelijk om per deel van een frame (een slicegenaamd) in te stellen wat zijn afhankelijkheid is met andere slicen. Dan spreken we van SIen SP slicen.

3.3.2.2 H.264 profielen en levels

H.264 ondersteunt verschillende profielen. Een profiel is een verzameling van verschillendecompressiemethodes die ondersteund worden. Hoe hoger het profiel, hoe meer compressietechniekener 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)


• 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 wevoor het baseline profiel. Indien men zeker is dat alle clients een hoger profiel accepteren, dankan er geopteerd worden om een hoger profiel te gebruiken. Deze zal immers een veel beterecompressieratio behalen.

In de tabel 3.2 staat een overzicht van alle mogelijke compressie methodes en welke profielenwelke methoden ondersteunen.

Figure 3.2: H.264 profielen (Ozer, 2009)

Het is nuttig om sommige methodes en eigenschappen onder te loep te nemen aangezien dezede uitvoer kunnen bëınvloeden.

1. De bitdepth en het chromaformaat vertellen welke colorspace als uitvoer uit de decoderzal komen.

2. Een H.264 encoder kan in plaats van een volledig frame ook stukken van een frame ofslices teruggeven. Indien de optie ”SI en SP” ondersteund wordt, dan is het mogelijkom 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.


3.3.2.3 H.264 levels

Naast het H.264 profiel moet er ook nog een H.264 level (International telecomunicationunion, 2010, P291) (Ozer, 2009) gekozen worden. Een level is een reeks van afspraken die hetmaximum bepalen van bepaalde parameters. Deze parameters zijn bijvoorbeeld de maximumvideo 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 levelondersteunen. De specifieke waarden voor elk level kunnen teruggevonden worden in deofficiële documentatie (International telecomunication union, 2010, P291).

3.3.2.4 SODB, RBSP en NAL units

Een H.264 stream kan worden afgespeeld door de frames te concateneren. Dit komt omdateen raw H.264 frame niet bestaat. Er worden namelijk altijd extra velden toegevoegd aan dedata.

De zuivere H.264 data noemt men een SODB (String Of Data Bits). Zoals de naam doetvermoeden is dit een bitstream wat minder praktisch is als een bytestream. Daarom wordtdeze bitstream geconverteerd tot een bytestream. Eerst wordt de SODB aangevuld met éénstop bit (1), daarna volgen er verschillende nul bits tot de lengte van de SODB een veelvoudis van 8. Indien de SODB met stopbit exact een aantal bytes lang is, dan worden er geenextra 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 eenencapsulatie van een RBSP-pakket voorgegaan door een NAL unit type. Dit is praktischomdat de decoder zo kan weten welk soort data er in de NAL-unit zit: een I frame, een Pframe, SPS, PPS, enzovoort.

In de onderstaande tabel (International telecomunication union, 2010, tbl 7.1) staan alleNAL-types. De belangrijkste zijn in het vet gemarkeerd.


nal unit type NAL unit0 Unspecified1 Coded slice of a non-IDR picture2 Coded slice data partition A3 Coded slice data partition B4 Coded slice data partition C5 Coded slice of an IDR picture6 Supplemental enhancement information (SEI)7 Sequence parameter set8 Picture parameter set9 Access unit delimiter10 End of sequence11 End of stream12 Filler data13 Sequence parameter set extension14 Prefix NAL unit15 Subset sequence parameter set16..18 Reserved19 Coded slice of an auxiliary coded picture without partitioning20 Coded slice extension21..23 Reserved non-VCL non-VCL24..31 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 deverboden bytes. Indien de RBSP een bepaald bytepatroon bevat dat verboden is, dan zullendeze veranderd worden naar een gelijkaardig patroon die wel toegelaten is. De verbodenbytepatronen worden gebruikt om te synchroniseren en mogen dus niet aanwezig zijn in deRBSP-data. De volgende bytepatronen zijn verboden en worden gewijzigd:

- 0x000000 wordt 0x00000300

- 0x000001 wordt 0x00000301

- 0x000002 wordt 0x00000302

- 0x000003 wordt 0x00000303

Alhoewel 0x000003 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 zientussen een ’verbeterd’ byte patroon en een origineel omdat deze beiden zouden starten met0x000003.


Figure 3.4: NAL Unit (codesequoia, Geciteerd april 2014)

De laatste fase is het toevoegen van een startcode aan de NAL-units. Deze synchronisatiebyte wordt gebruikt om het begin van de volgende NAL-unit aan te duiden. Dit bytepatroonis 0x000001 of 0x00000001. Aangezien dit startpatroon een verboden bytepatroon is, zal dezedus ook nooit voorkomen in de data zelf. (International telecomunication union, 2010, p66).

Figure 3.5: NALByteStream (codesequoia, Geciteerd april 2014)

3.3.2.5 SPS en PPS

In het overzicht van de NAL-unit types staan twee speciale NAL-units, namelijk de Sequenceparameter set (SPS) en de Picture parameter set (PPS). Deze twee pakketten bevattenalle algemene informatie over de H.264 video stream en worden meestal eenmaal verzondenin het begin van de stream.

De SODB van de SPS bevat de volgende velden: zie tabel 3.6. Merk op dat de SPS eenvariabele lengte heeft. Het ontleden van deze bitstream zou ons te ver afleiden maar het istoch 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: Gevende YUV-colorspace terug.

pic width in mbs minus1 en pic height in map units minus1: Geven de resolutie vande frames terug.

Naast de SPS-informatie is er ook nog de PPS-informatie. Deze bitstream bevat meerinformatie over de coderingseigenschappen van de stream. Meer informatie over de exactevelden kunnen teruggevonden worden in (International telecomunication union, 2010, Tabel7.3.2.2).


Het is belangrijk om te weten wat de SPS en PPS informatie inhoudt. Zonder deze pakketten ishet onmogelijk om een stream te decoderen. Gelukkig worden deze twee pakketten automatischdoor 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 metadatamoeten al deze kanalen gemultiplexd worden tot één bestand. Dit is slechts optioneel. Zo kanje met VLC player perfect een H.264 videostream afspelen zonder dat deze in een containerzit. Ook bieden streamprotocollen zoals RTP de functie aan om deze streams naast elkaar teverzenden. Dan is de client verantwoordelijk om deze onafhankelijke streams samen te voegendoor hun timestamps te vergelijken.

Een van de bekendste bestandsformaat is de MP4 container. Deze is net zoals H.264 een deelvan de MPEG-4 standaard. Andere bekende zijn Quicktime File Format (.mov), Matroska(.mkv) en MPEG-TS (.ts). Elk bestandsformaat biedt ondersteuning voor een beperkt aantalcodecs. Een overzicht is te vinden op http://en.wikipedia.org/wiki/Comparison_of_container_formats.

http://en.wikipedia.org/wiki/Comparison_of_container_formatshttp://en.wikipedia.org/wiki/Comparison_of_container_formats


Figure 3.6: Sequence parameter set (International telecomunication union, 2010, Tabel7.3.2.1.1)

Hoofdstuk 4

Netwerk en stream protocollen

Er bestaan verschillende protocollen om een mediastream te verzenden naar de verschillendeclients. We overlopen laag per laag het TCP/IP model.

4.1 Netwerklaag: IP multicast

De meeste communicatie gaat van één server naar één client, maar soms zijn er meerdereclients die dezelfde data willen ontvangen. Een mogelijke oplossing is dan om de pakketten teverzenden naar het broadcast adres, dit is het laatste IP-adres van een netwerk. Dit berichtzal 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 datelk pakket slechts eenmaal moet verzonden worden. Het grootste nadeel is dan weer dat erverschillende 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-multicastingwordt als ontvanger IP een klasse D adres ingevuld (eerste 4 bits zijn 1110). Elke client diedeze berichten wil ontvangen zend eerst een inschrijving over het netwerk. De routers in ditnetwerk zijn verantwoordelijk dat elke ingeschreven client een kopie van de multicast berichtenontvangt. Multicasting is alleen mogelijk over een LAN-netwerk waarbij alle interne routersmulticasting 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 moetomdat de clients via het internet zijn verbonden.

25

HOOFDSTUK 4. NETWERK EN STREAM PROTOCOLLEN 26

4.2 Transportlaag: TCP

Omdat we moeten kunnen streamen over het internet, zijn er slechts twee mogelijke protocollendie 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 encoderkomt encapsuleren en verzenden in een TCP-stream. TCP werkt met het principe vanhandshaking. Dit wil zeggen dat een verbinding tussen 2 apparaten wordt opgezet en wordtonderhouden. Hierdoor ondersteunt TCP retransmitting van verloren pakketten. Bij livestreaming is deze techniek niet aan te raden aangezien er moet gewacht worden op een framedat toch te laat zal arriveren. Bij een H.264 stream zou dit wel handig zijn omdat het droppenvan 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 vanverloren pakketten en de handshaking zorgen ervoor dat er tijd en bandbreedte verspildwordt. 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 vanelkaar verzonden. Dit wil zeggen dat er geen mogelijkheid is tot fragmentatie van een frameover meerdere UDP-pakketten. Dus is het verplicht om exact één frame in één UDP-pakkette verzenden.

Het ’lenght’ veld in de UDP-header is 16 bit lang. Dus de payload van een UDP-pakketkan maximaal 64KB zijn inclusief de UDP-header. Als je weet dat een raw 720p frame zo’n921 600 bytes inneemt, dan kan je concluderen dat er een verplichte constante minimalecompressiefactor 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 bovenliggendeRTP-protocol.

4.4 Transportlaag: UDP jumbograms

Zoals omschreven in de vorige paragraaf is de maximale payload van een UDP-pakket gelimiteerddoor de beperkte lengte van het ’lenght’ field in de UDP-header. De maximale payload is:216 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-headerheeft ook een ’lenght’ veld van 16 bit lang. De maximale payload van een IPV4-pakket kandus maximaal 216 − lenght(IPV 4header) zijn. Een IPV4-header is minimaal 20 bytes indien


er geen extra headers aanwezig zijn. Met deze informatie is het mogelijk om exact te berekenhoeveel payload een UDP-pakket kan bevatten indien deze over IPV4 wordt verzonden. 216−lenght(IPV 4header) − lenght(UDPheader) = 65536 − 20 − 8 = 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. Nuheeft ook IPV6 een lengte veld van 16 bit lang. Bij jumbograms wordt dit veld op 0 gezet enwordt er een extra jumbogram IPV6-header toegevoegd. Deze extra header bestaat uit een32 bit ’lenght’ veld waarin de correcte lengte te vinden is. Dit laat toe om een IP-payload van232 i.p.v. 216 bytes te verzenden. Het UDP lenght field wordt op 0 gezet. Dit veroorzaaktgeen problemen aangezien de exacte lengte van het UDP-pakket kan berekend worden metde data uit de IPV6-header.

Helaas is dit protocol niet bruikbaar voor dit project omdat niet alle routers en besturingssystemendit ondersteunen.

4.5 Applicatielaag: RTP

Het Real Time Protocol (RTP) werkt bovenop UDP en is ontworpen voor live streaming. Hetgrootste nadeel van UDP, namelijk de gelimiteerde frame size, lost RTP op door één framete fragmenteren over verschillende UDP-pakketten. RTP laat verschillende soorten payloadstoe. 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 metRTP niet nodig is. Indien er een film wordt verzonden over RTP dan zijn er twee of meerdereonafhankelijke RTP-streams die elk verantwoordelijk zijn voor een kanaal (audio, video, ...).Deze streams worden dan naast elkaar verzonden naar de client. Zolang de ontvanger ditondersteunt en de timestamps van de pakketten in orde zijn, zal de client een vloeiende filmmet beeld en geluid afspelen.

Wanneer er meerdere paden zijn tussen de server en de client, dan is het mogelijk dat devolgorde van de fragmenten verstoord wordt. Daarom is het aan te raden om de pakkettente ordenen wanneer deze aankomen aan de client zijde. Ongeacht zijn payload heeft elkRTP-pakket altijd dezelfde header:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(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 hetonderliggende payload type.

PT Payload Type: 7bit: Type van de payload. Een overzicht van de mogelijke payloadtypes kan teruggevonden worden op http://tools.ietf.org/html/rfc3551#section-6.De meeste protocollen kiezen voor een dynamische payload type. Dit wil zeggen dat alleinformatie over de payload gekend is door zowel de client als de server. Dit kan gebeurendoor 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 sequencenumber incrementeert altijd met 1.

Timestamp Timestamp: 32bit: Het aantal ticks van een klok. De snelheid van de klok isgekend door zowel de client als de server. Voor H.264 video signalen is dit bijna altijd een 90KHz klok. Alle pakketten die data bevatten van hetzelfde frame hebben dezelfde timestamp.

SSRC synchronization source identifier: 32bit: Een random waarde om de RTP-stream teidentificeren. Dit is nodig indien er meerdere RTP-streams aankomen op één machine (bveen 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 SSRCsdie samen horen met deze stream.

In de meeste gevallen is padding false, extensions false en zijn er geen CSRSs en dus is CCgelijk aan 0.

Na de algemene RTP-header volgt de payload specifieke header. In dit project worden er tweetypes gebruikt: JPEG over RTP en H.264 over RTP.

http://tools.ietf.org/html/rfc3551#section-6


4.5.1 RFC 2435: JPEG over RTP

RFC 2435 bespreekt het protocol om JPEG-gecodeerde frames te verzenden over RTP. Opeenvolgendbevat 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 dezeinformatie is te vinden in de RFC (1998b).

4.5.1.1 RTP-JPEG-header

Elk RTP pakket met JPEG-data begint met een RTP-JPEG-header. Deze bevat de algemeneinformatie 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 specifiekhet JPEG-type terug.

Fragment offset Fragment offset: 24 bits: De offset van de JPEG-data. Wanneer defragment 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. Types64 tot en met 127 zijn identiek dezelfde types maar met restart headers. JPEG-types 128 toten met 255 zijn dynamisch toe te wijzen.

Q Q: 8 bits: Definitie van de quantization table. Een waarde tussen 0 en 127 wil zeggen dateen algoritme is gebruikt om de quantization tabel te berekenen. Welk algoritme er exact isgebruikt is afhankelijk van het JPEG-type. Een waarde tussen 128 en 255 betekent dat dequantization tabel wordt meegezonden na de RTP-JPEG-header. zie 4.5.1.3.


Width Width: 8 bits: De breedte van de JPEG-frame.

Height Height: 8 bits: De hoogte van de JPEG-frame.

4.5.1.2 Restart header

Indien de JPEG-type tussen 64 en 127 ligt, dan is de JPEG-data gecodeerd met restartmarkers. Deze markers zijn nuttig voor wanneer de JPEG-decoder een fout tegenkomt. Dankan 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 dieperop in.

De restart header ziet er als volgt uit:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Restart Interval |F|L| Restart Count |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5.1.3 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 handvan het JPEG-type de quantization tabel worden berekend. Indien de waarde tussen 128 en255 ligt, dan moeten de quantization tabellen meegegeven worden in een Quantization TableHeader.

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.


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 meestrechtse bit enz.

Indien deze bit op 0 is ingesteld, dan is de coëfficiënt van de tabel te vinden in de laatste 8bit van de 64 byte tabel. Indien de bit op ’1’ is gezet, dan zijn het de laatste 16 bit van de128 byte tabel.

4.5.1.4 C++: RTP-JPEG-Decoder

Voor dit project moet er een 720p beeld verzonden worden over een 100Mbps netwerk. Daaromis er geopteerd om de beelden te verzenden met JPEG over RTP. In plaats van een bestaandebibliotheek te gebruiken, is er beslist om alles volledig zelf te schrijven. De belangrijkste redenhiervoor is dat zelf geschreven code veel minder resources gebruikt. Dit is belangrijk indiendeze beperkt zijn zoals bij een SoC.

De implementatie zelf ondersteunt niet alle opties die de RFC beschrijft. Alleen de nodigeheaders zijn gëımplementeerd:

1. Aangezien er slechts één weg is tussen de camera en de cluster is het onmogelijk dat devolgorde van de pakketten gewijzigd wordt. Er is toch een controle gëımplementeerdindien pakketten niet in de juiste volgorde zouden aankomen, maar herordening gebeurtniet. Indien er toch iets mis is gegaan, dan zal de JPEG-decoder het volledige framedroppen.

2. Er worden twee quantization tables meegegeven.

3. Om de JPEG-data in een JIF-formaat te capsuleren wordt er gebruikgemaakt van devoorbeeldcode 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]


if (((rawUDP[2] pBuffer+jpegFrame->nFilledLen, rawUDP+offset, pakketSize-offset);

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;

}


4.5.2 RFC 3984: H.264 over RTP

Ook voor een H.264-payload is er een RTP-standaard voorzien. Dit protocol biedt veel meerfuncties aan dan de JPEG over RTP standaard. Al deze informatie kan teruggevonden wordenop https://www.ietf.org/rfc/rfc3984.txt en https://tools.ietf.org/html/rfc6184.De RFC 6184 (RFC, 2011) is een herwerking van de RFC 3984 standaard. Onderliggend zijner 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.

4.5.2.1 RTP H.264 header

+---------------+

|0|1|2|3|4|5|6|7|

+-+-+-+-+-+-+-+-+

|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 hetRTP-pakket aanduidt. Waarde 00 zegt het systeem dat de data onbelangrijk zijn voor dereconstructie van de H.264-stream. Elke waarde groter dan 00 eist dat het frame moet gelezenworden. In ons voorbeeld zijn alle NRI gelijk aan 01. De NRI moet gelijk zijn aan 00 indienhet 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. Inonderstaande tabel staat een overzicht van alle NAL-Types:

NAL Type Packet Type name Section

---------------------------------------------------------

0 undefined -

1-23 NAL unit Single NAL unit packet per H.264 5.6

24 STAP-A Single-time aggregation packet 5.7.1

25 STAP-B Single-time aggregation packet 5.7.1

26 MTAP16 Multi-time aggregation packet 5.7.2

27 MTAP24 Multi-time aggregation packet 5.7.2

28 FU-A Fragmentation unit 5.8

29 FU-B Fragmentation unit 5.8

30-31 undefined -

De NAL types van 0-23 zijn reeds uitgelegd in het paragraaf 3.3.2.4.

https://www.ietf.org/rfc/rfc3984.txthttps://tools.ietf.org/html/rfc6184


Voor dit project gebruiken we twee NAL-types: ”Single NAL unit packet” en ”FU-A”. Indienons H.264 frame in één RTP pakket kan, dus moet het niet gefragmenteerd worden, dan nemenwe het type van de oorspronkelijke frame (die altijd tussen 0 en 24 ligt). Deze wordt dangeplaatst in het type-veld. Daarna plaatsen we de H.264 data met optionele padding. Dit iseen ”Single NAL unit packet”.

Indien onze data te groot is om in één RTP pakket geplaatst te worden, dan wordt dezegefragmenteerd en wordt het type op FU-A (28) geplaatst. Dan volgt er een FU header endaarna pas de gefragmenteerde data.

Een FU-B pakket heeft ook een FU header met daarna nog een extra DON (decoding ordernumber) veld. Dit nummer kan gebruikt worden door gateways en routers die een RTP-pakketverder willen opsplitsen in twee pakketten zonder de volledige RTP-sequentienummer aan temoeten passen van het RTP-pakket en al de daaropvolgende RTP-pakketten. Een client moetdan gewoon de waarde van het RTP sequence nummer field en het DON field concatenerenom het exacte sequentienummer te weten. De FU-A pakketten kunnen eventueel door eenrouter omgezet worden naar FU-B pakketten indien de MTU van het ene netwerk groter isdan de MTU van het andere netwerk.

STAP-A, STAP-B, MTAP16 en MTAP24 zijn types die toelaten om verschillende H.264 delenvan opvolgende frames in één RTP-pakket te stoppen. Voor dit project worden deze typesniet gebruikt.

4.5.2.2 FU header

Deze header is alleen nodig indien het NAL-type ingesteld is op 28 (FU-A).

De FU-header bestaat uit:

+---------------+

|0|1|2|3|4|5|6|7|

+-+-+-+-+-+-+-+-+

|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. Dezebit is dus altijd identiek aan de RTP marker bit die ook aan staat indien de payload de laatstescan 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.


4.5.2.3 Samenvatting

Indien we een H.264 frame moeten fragmenteren, dan encapsuleren we de data in een FU-A-pakketdie er als volgt uitziet:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|F|NRI| 28 (type) | S|E|R| Type | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

| |

| FU payload |

| :.OPTIONAL RTP padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Indien het H.264 frame in één pakket kan, dan kan deze geplaatst worden in single NAL unitframe die er als volgt uit ziet:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|F|NRI| Type | |

+---------------+ |

| FU payload |

| :.OPTIONAL RTP padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5.2.4 C++: RTP H264 encoder

Voor we kunnen beslissen of we het H.264 frame moeten fragmenteren, moeten we eerst demaximale grootte van een UDP-pakket kennen.

Een NAL-UNIT mag nooit de MTU overschrijven van zijn protocol. Een ethernetpakket heeftals MTU 1500 bytes. Gevolgd door de volgende headers:


• 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. Dedata die aangeleverd wordt kan een volledig H.264 frame zijn, of een deel ervan. Het eersteprobleem is het verwijderen van de H.264 startcode. Indien de lengte kleiner is dan 3 dan ishet 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 uitde startcode heeft gehaald, als argument. Indien er geen startcode aanwezig was dan wordthet 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


//No H264 startcode, is part of the previous slice, use previous type.

processRTPPacket(RTP, timeStamp,databuffer,datalen, 0, startbit, endbit,RTPClients,vorigeTyp, sock,aantalClients);

}

}

}

De ’processRTPPacket’ functie fragmenteert (indien nodig) het frame en encapsuleert de datain 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,RTPClients, type, sock, aantalClients);

startbit=0;

i++;

}

processRTPPakket(RTP,timeStamp,databuffer+(i*1394) , datalen-(i*1394), 0, 0, endbit,RTPClients,type, sock, aantalClients);

return;

}else{

Indien de grootte kleiner is dan de limiet dan moet deze gecapsuleerd worden in een RTP-pakket:

RTP[0]=128; //10000000, Version=10 , Padding=0, Extension=0, CC=0000

RTP[1]=96|endbit8;

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;


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


RTSP/1.0 200 OK

Supported: play.basic, con.persistent

Cseq: 1

Server: Wowza Media Server 3.6.2.18 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 doorde statuscode. Merk op dat de statuscodes en de berichtindeling dezelfde zijn als bij hetHTTP-protocol. Daarna volgen opnieuw een aantal ”sleutel: waarde” regels. Belangrijk is dater altijd een CSeq-waarde wordt meegegeven. Deze waarde is dezelfde als de CSeq-parameterdie werd meegezonden met de request. Na deze headers kan er nog data volgen. Dit kanindien er een ”content-lenght”-waarde aanwezig is. De delimiter tussen de headers en de datazijn twee newlines karakters.

Nu we weten hoe het protocol algemeen zijn berichten opstelt kunnen we dieper ingaan opde verschillende commando’s en hun antwoord. Nadat de client een TCP-connectie heeftopgezet met de server via poort 554 (standaard) zendt deze zijn eerste bericht. De meestemediaplayers volgen een vaste sequentie om dat te verzenden.

Options: Dit commando vraagt welke RTSP-commando’s er ondersteund worden door deserver. Deze stap kan eventueel overgeslagen worden indien de client veronderstelt dat deserver alle mogelijke commando’s ondersteunt.

Het describe commando vraagt de RTP-informatie op aan de server. De reactie bevat deomschrijving 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 zendtde server ook een ”session”-waarde mee in de header. Alle volgende antwoorden zullen vanafnu ook deze session-waarde vermelden.

Daarna volgt de setup instructie. Deze zet de RTP-verbinding op tussen de client en deserver. De client heeft de SDP informatie aanvaard en geeft informatie van zijn kant terug inde ”Transport”-parameter. Een voorbeeld hiervan is:

Transport: RTP/AVP;unicast;client_port=53838-53839

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 wordtondersteund 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 moetenworden 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 wordtmet nog een paar extra velden.


Transport: RTP/AVP;unicast;client_port=7008-7009;source=184.72.239.149;

server_port=7512-7513;ssrc=0DCAB11F

Deze extra velden zijn het bron IP-adres en de server poorten. De eerste ’server port’ is debron poort vanwaar de RTP-pakketten zullen worden verzonden. De tweede is de RTCP-poortop de server naar waar RTCP-informatie kan worden verzonden. Ook volgt er nadien eenSSRC-waarde. Zoals uitgelegd in het hoofdstuk RTP (4.5) is dit de identificatie van een RTPstream.

Na een setup request zijn alle gegevens gekend om een RTP-stream te beginnen. Om dezestream 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 totde server een teardown commando ontvangt. Bij live streaming is het pause commandoredelijk nutteloos, maar deze kan wel praktisch zijn bij een Video On Demand service. Erbestaan nog andere commando’s maar met deze selectie is de basis gelegd van een werkendeRTSP-server.

4.7 Session description protocol

Het session description protocol wordt gebruikt om meer informatie over één of meerderestreams 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=- 4064783057 1502438752 IN IP4 192.168.2.200

s=Televic RTSP\r\n"

c=IN IP4 0.0.0.0

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 eendynamisch type. In ons geval omschrijft de SDP het dynamische type nummer 96. Dezegebruikt een klok van 90KHz om de timestamp te bepalen. Ook de framerate en de resolutie


worden vastgezet op respectievelijk 30FPS en 1280*720. De belangrijkste H.264-informatie isterug te vinden in het ’profile-level-id’ en de ’sprop-parameter-sets’ waarden. Het profile-level-idbevat de eerste, tweede en de derde byte van de SPS (zonder startcode of type) in hexadecimalenotatie. De ’sprop-parameters-set’ bevatten de SPS en de PPS in base64 encodering (zonderstartcode 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 synchronisatieproblemengerapporteerd worden door ’Receiver reports’ te zenden naar de server. Net zoals alle andereprotocollen 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 eenmedia player naar een streamserver. Zo’n pakket bevat informatie zoals het aantal verlorenpakketten, de fractie verloren pakketten, het hoogste ontvangen sequentienummer en degedetecteerde jitter.

4.9 Applicatielaag: HTTP progressive downloading

RTP heeft als grootste nadeel dat het geblokkeerd kan worden door firewalls. Indien UDPgeblokkeerd wordt, kan RTP over TCP gebruikt worden. Helaas zijn er ook bepaalde firewallsdie alleen HTTP-verkeer doorlaten.

HTTP progressive downloading of HTTP progressive streaming is een simpele manier om ditprobleem te omzeilen. Dit protocol downloadt gewoon de videostream naar de harde schijfover het HTTP protocol. De meeste mediaplayers kunnen deze stream al afspelen terwijl dezenog gedownload wordt.

Het grootste nadeel aan dit protocol is niet het gebruik van TCP (4.2) maar wel dat er geenmogelijkheid is om door te spoelen zonder alle voorgaande frames te downloaden. Voor eenVideo On Demand service is dit onaanvaardbaar. Voor een live videostream is dit protocolwel 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 framebegint. Daarom moeten JPEG-frames in een container verzonden worden. Zoals reedsaangegeven hoeft dit niet voor een zuivere H.264-videostream aangezien deze streams metstartcodes werken om de verschillende frames te identificeren (3.3.2).


4.10 Applicatielaag: HTTP Live Streaming

Het HTTP Live Streaming protocol (HLS)(Apple Inc., 2013) (Apple Inc. , Geciteerd april2014) is een protocol dat gebaseerd is op het HTTP progressive downloading protocol maardat het seek probleem oplost. Dit protocol is dan ook veel gebruikt bij video on demandservices. 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 downloadbarecontent te publiceren op een webserver. Er is dan een m3u8 bestand dat aangeeft in welkestukken de mediastream is geknipt met een bijhorende link. Hiernaast is het ook mogelijkom verschillende streams te omschrijven met hun benodigde bandbreedte. Dan kan de clientzelf 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 hiervoorongeschikt! De videobeelden worden namelijk ’live’ verknipt in stukken maar in feite downloadiedereen op hetzelfde moment hetzelfde stuk. Dit is normaal aangezien de stukken uit detoekomst nog niet gemaakt zijn, en de stukken uit het verleden voor een delay zorgen. Er ligtwel al een ’link’ naar deze stukken in het m3u8 bestand. Nu moeten HLS clients minimaaléén segment volledig gedownload hebben voordat ze deze mogen afspelen. Meestal is dit eenstuk van 10 seconden. Dit resulteert in een constante delay van 10 seconden.

Standaard wordt elk stuk in een mpeg-ts container geëncapsuleerd. Deze container wordtondersteund door alle iOS-apparaten.

Als voorbeeld nemen we de live stream van deredactie.be. De m3u8-pagina ziet er als volgtuit:

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=800000

http://live.stream.vrt.be/.../vrt_nieuws_live_ios.smil/chunklist-b800000.m3u8?wowzasessionid=195777128

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=400000

http://live.stream.vrt.be/.../vrt_nieuws_live_ios.smil/chunklist-b400000.m3u8?wowzasessionid=195777128

Deze pagina linkt naar twee onafhankelijke streams. Deze zullen dezelfde beelden tonen maarmet een andere bitrate. De client kan aan de hand van de bandwidth parameter beslissenwelke hij zal afspelen.

De gelinkte pagina’s zien er zo uit:

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-ALLOW-CACHE:NO


#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:454

#EXTINF:10.0,

media-b800000_454.ts?wowzasessionid=1308022554

#EXTINF:10.0,


#EXTINF:10.0,


...

...

Hier is het duidelijk dat elke stuk 10 seconden duurt. Indien deze pagina opnieuw geladenwordt dan zullen de nummers aangepast worden zodat het laatst aangemaakte deel vanbovenvermeld staat als eerste deel.

4.11 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 enmedia formaten.

Android IOS (iphone 4)RTSP met RTP JA NEEHTTP Progressive download JA JAHLS Vanaf Android 3, MPEG-TS only JAH264 Baseline only Main 3.1

Voor dit project werd gekozen om met RTP en RTSP te werken aangezien dit formaat goedondersteund wordt en met externe apps kan afgespeeld worden. Als videocodec is alleen H.264baseline bruikbaar.

De verdere gegevens over deze besturingssystemen kan gevonden worden op: http://developer.android.com/guide/appendix/media-formats.html voor android en http://support.apple.com/kb/SP587 voor IOS.

http://developer.android.com/guide/appendix/media-formats.htmlhttp://developer.android.com/guide/appendix/media-formats.htmlhttp://support.apple.com/kb/SP587http://support.apple.com/kb/SP587

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 werkendemultimedia oplossing te ontwikkelen.

GStreamer is cross platform en is beschikbaar onder de LPGL-licentie. Er zijn verschillendeversies 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 officiële repositories.Een groot nadeel is dat de versies onderling niet compatibel zijn. Zo worden er per versieplug-ins van naam veranderd en veranderen er eigenschappen van componenten. Een andergroot nadeel is de relatief slechte documentatie. Op moment van schrijven is versie 1.2 delaatste nieuwe release maar is de documentatie nog geschreven voor versie 1.0 en sommigedelen zelfs voor versie 0.10. Dit is één van de redenen waarom de developers gestart zijn metGStreamerSDK. Dit is de GStreamer 0.10 met een deftige documentatie.

GStreamer kan op twee manieren worden aangesproken: via een programmeeromgeving of viade terminal. Zo kan je het compileren in een C++ programma of kan je snel een GStreamerserver 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 wordennaar een C++ programma.

5.1 Principe

Zoals vermeld werkt GStreamer met een verzameling van plug-ins ( http://GStreamer.freedesktop.org/documentation/plugins.html ). De bedoeling is om een tunnel te makenmet deze plug-ins. Een GStreamer-tunnel start altijd met een source-component(naam eindigtop src) die je dan piped naar verschillende andere componenten. Als laatste component worder altijd een sink geplaatst.

44

http://GStreamer.freedesktop.org/documentation/plugins.htmlhttp://GStreamer.freedesktop.org/documentation/plugins.html

HOOFDSTUK 5. GSTREAMER 45

Elke component die geen sink of source element is, heeft dus éé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.10voor versie 0.10 of de GStreamer SDK) commando uit te voeren met als enige argumentde tekstuele omschrijving van een tunnel. Een tunnel is samengesteld door de namen vande gebruikte componenten gescheiden door een ”!”. Indien een component meerdere outputeigenschappen heeft (denk maar aan een webcam die meerdere resoluties ondersteunt) dankan 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 inde documentatie of via het ’gst-inspect’ commando. De laatste methode geniet de voorkeuraangezien 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=224.0.1.12 port=1234 multicast-iface=eth0 force-ipv4=true

Als eerste component staat een Video For Linux 2 source component (V4l2src). Dezekan een door linux erkende webcam aanspreken. De gebruikte webcam ondersteunt demogelijkheid om, in plaats van ruwe pixels, de data reeds als JPEG-gecodeerde data aante leveren. Ook zijn er verschillende resoluties mogelijk. Dit resulteert dus in meerderemogelijkheden als uitvoer voor het V4l2src component. Daarom is er een caps geplaatst omde juiste stream te selecteren. Indien er in de caps een resolutie zou geplaatst worden die nietdoor de hardware ondersteund wordt, dan wordt er een foutmelding gegenereerd.

De raw 720p beelden worden daarna doorgestuurd naar een videorate component. Dezeweet dat de framerate is ingesteld op 30fps, en zal dan ook proberen per 33ms een frameals uitvoer te zenden. Indien hij geen nieuwe frame heeft ontvangen, dan zal hij de vorigeframe opnieuw verzenden. Deze frameratestabilisator is nodig om de metingen onafhankelijkte maken van de gebruikte webcam.De enige reden waarom we de ingebouwde JPEG-encoder van de webcam niet gebruikenis omdat we willen gebruikmaken van de timeoverlay component. Deze plaatst op elkeinkomende frame de timestamp van dit moment. Dit kan gebruikt worden om later de totaledelay te meten van de transcoder. Dit component aanvaardt alleen raw data als invoer.De ruwe beelden, met timestamp, worden daarna door een JPEGenc component gecodeerdvolgens 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.


5.2 Voorbeelden

Voor dit project worden er verschillende GStreamer programma’s gebruikt. Deze zijnbijvoorbeeld verantwoordelijk om RTP-MJPEG-data aan te leveren aan de transcoder en deterugkerende stream af te spelen op het scherm.

5.2.1 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=224.0.1.12 port=1234 multicast-iface=eth0 force-ipv4=true

Dit script wordt gebruikt om een timestamp (nauwkeurig tot op de milliseconde) te plaatsenop de live beelden die de webcam waarneemt. Deze worden dan geëncapsuleerd in eenRTP-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=224.0.1.12 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.264gecodeerd 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 ditautomatisch detecteert. De uitgaande stream is een raw pixel video stream.

Met het videoscale commando kan elke ruwe frame geresized worden tot de gewenste groottedie meegegeven is in de caps.

In dit voorbeeld gebruiken we twee videorate componenten. Eén voor en één na de JPEG-encoder.Dit komt omdat het coderen in JPEG niet met een constante snelheid gebeurd indien debeelden erg variëren. Je kan dit zien als een dubbele stabilisator.

5.2.2 GStreamer clië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 ophet scherm te tonen.


gst-launch-1.0 -v udpsrc multicast-group=224.0.1.12 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 deframes geplaatst (”SRV”) en worden deze via de fpsdisplaysink op het scherm getoond. Dezesink heeft als voordeel dat ook de gemiddelde framerate en de momentele framerate zichtbaarzijn. De eigenschap ”sync=false” vertelt dat er geen rekening moet worden gehouden metde timestamp die meegegeven worden in de RTP-header. Aangezien de timestamps correctgegenereerd 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 hetmogelijk om met bovenstaand script dit te tonen op het beeldscherm. Het enige verschil methet vorige programma is dat we nu avdec h264 moeten gebruiken i.p.v. jpegdec aangeziende 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-pakkettenniet volledig accuraat zijn.

Hoofdstuk 6

Raspberry Pi

Als SoC werd gekozen voor de Broadcom BCM2835. Deze processor werd beroemd als hetsysteem 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 wordenvoor deze CPU familie. Momenteel zijn er al een paar linux distributies beschikbaar. Demeest gebruikte zijn debian en ArchLinux. Er is 512 MB RAM aanwezig op deze SoC. Deoudere RPI (voor 15/10/2012) hebben slechts 256 MB RAM. Dit geheugen is gedeeld met deGPU.

Een kanttekening moet wel gemaakt worden bij de twee USB poorten. De ethernet en dezeUSB-poorten zitten namelijk op dezelfde bus. Dit wil zeggen dat ook hun bandbreedteverdeeld is (ppumkin, 2013).

Specificaties van de GPU:

48

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 decodersaan te spreken. Dit kan via OpenMAX (7).

De volgende componenten worden ondersteund:

Codec HW / SW Port IN Port OUT LicentieMPEG2 dec HW 130 131 MPEG2 licentie (2.40 pound)H263 dec HW 130 131 Meegeleverde licentieH264 dec HW 130 131 Meegeleverde licentieOgg Theora dec SW 130 131 Meegeleverde licentieVP6 / VP8 dec SW 130 131 License freeJPEG dec SW 130 131 License freeVC1 dec HW 130 131 VC-1 licentie (1.20 pound)H264 enc HW 200 201 Meegeleverde licentieResize 60 61

Deze informatie is samengesteld uit verschillende bronnen aangezien er geen officiële documentatiehierover 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. Sommigeencoders zijn namelijk volledig gëıntegreerd in de GPU. Andere codecs zijn in de softwaregeprogrammeerd maar gebruiken de GPU om de zware berekeningen te doen. De poorten dievermeld staan zijn de OpenMAX poorten 7.

Qua licentiekosten zijn de ”license free codecs” gratis te gebruiken. De Raspberry Pi foundationheeft ervoor gekozen om de H.264 codec mee te leveren in de prijs van de Raspberry Pi. Er isook de mogelijkheid om een VC1 of MPEG2 licentie te kopen zodat er bepaalde extra featuresbeschikbaar worden. Deze sleutel is gebonden aan de serienummer van de SoC en is dus nietoverdraagbaar.

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 openstandaarden te creëren. Net zoals Adobe, canonical, EA en Google is broadcom ook lidvan deze groep. Bij de ontwikkeling van de broadcom VideoCore IV is er dan ook voorgeopteerd om deze standaard te gebruiken. Meer specifiek moet er gebruik worden gemaaktvan de OpenMAX Integration Layer om te communiceren met de ingebouwde hardwarecomponenten.

Er is geen wijde ondersteuning voor systemen die OpenMAX ondersteunen. Op het momentvan schrijven staan er slechts twee voorbeeldcodes online voor de Raspberry Pi: een H.264encoder (hello encode) en een JPEG-decoder (hello jpeg). Hun code is beschikbaar op degithub van het Raspberry Pi project. In het hoofdstuk ”Implementatie” wordt hier dieper opingegaan.

Broadcom voorziet een ”ILClient” library die een laag vormt tussen de applicatie en deOpenMAX core. Deze bibliotheek maakt het gemakkelijker om de OpenMAX-componentenaan te spreken door veel gebruikte sequenties van instructies te groeperen in één functie.Bijvoorbeeld het uitzetten van een poort kan in slechts één operatie in plaats van twee indienOpenMAX rechtstreeks gebruikt wordt.

In dit hoofdstuk worden de algemene principes van OpenMAX IL uitgelegd zoals beschrevenin hun specificatie. (The Khronos Group Inc, 2005)

7.1 Algemeen

Elk component (decoders, encoders, resizers) die gëımplementeerd zijn in de driver kunnenworden aangesproken via OpenMAX IL. Elke component heeft een aantal in en uitgangen diegëıdentificeerd worden aan de hand van een poortnummer. Dit nummer is te vinden in de

50

HOOFDSTUK 7. OPENMAX 51

documentatie van de gebruikte SoC. Voor de Raspberry Pi is deze informatie te vinden ophttps://github.com/raspberrypi/firmware/tree/master/documentation/ilcomponents

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 loadedstaat gaan. Onmiddellijk daarna kan de staat manueel op idle gezet worden. In de idle standkunnen alle parameters van een component geconfigureerd worden. Uitzonderlijk zijn er ookeigenschappen die kunnen veranderd worden in de executing staat. Nadat alle eigenschappenaanvaard zijn, kan het component in de executing staat worden geplaatst. In deze staat kaner data aangeleverd worden aan de component. In de executing staat is het ook mogelijk dater 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 erdata in de component gepompt worden. Dit gebeurt door eerst de buffer, die gelinkt is aan deinvoer poort, te vullen met data. Daarna moet het ’EmptyThisBuffer’ commando verzonden

https://github.com/raspberrypi/firmware/tree/master/documentation/ilcomponents

HOOFDSTUK 7. OPENMAX 52

worden naar de GPU. Deze zal de invoerbuffer in de GPU inladen. Eenmaal dit vollediggedaan is, is de nFilledLen (de gevulde lengte) van deze buffer 0 geworden. Er zal ook eenEmptyBufferDone callback opgeroepen worden.

Daarna moet de uitvoer opgehaald worden. Dit gebeurt door het ”FillThisBuffer” commandote verzenden samen met een link naar een uitvoerbuffer. Dit commando zal de data die klaaris kopiëren naar de buffer. Indien dit correct gebeurt dan zal het nFilledLenght veld van deuitvoerbuffer geen nul meer zijn en zullen de flags van deze buffer aangevuld worden door dehardware. Ook zal er een FillThisBufferDone callback gegenereerd worden.

7.2 Flags

Elke buffer is van het type OMX BUFFERHEADERTYPE. Deze bezit naast een buffer ookeen veld voor flags. Dit kunnen zowel flags zijn die manueel gezet worden op een invoerbuffer,als flags die door de hardware gezet worden op een uitvoerbuffer.

Er zijn verschillende flags die een in- of uitvoerbuffer kunnen meekrijgen:

OMX BUFFERFLAG EOS 0x00000001 Er is geen verdere data beschikbaar

OMX BUFFERFLAG STARTTIME 0x00000002 Wordt gezet indien de buffer de starttimebevat

OMX BUFFERFLAG DECODEONLY 0x00000004 Decodeer de meegegeven data maarzend deze niet door als uitvoer. Dit kan gebruikt worden indien je I en P frame

low cost multirate video transcoder met parallelle...

Documents