Produkten uppfyller de krav som sattes upp som högsta prioritet och som skulle vara uppfyllda för att produkten skulle räknas som leveransfärdig. Produkten kan därmed utföra sin huvudsakliga uppgift och bygger en stabil grund för det system kunden vill ha. Med detta har projektets syfte därför uppnåtts.
A
WebRTC, RTMP och HLS, en
jämförelse av Mattias Ljung
A.1
Inledning
Att kunna skicka videoströmmar är ett relativt nytt fenomen som har växt fram sedan början av 2000-talet. I ett tidigt skede användes det mest i underhållningssyfte men det har kommit att bli en viktig del inom områden där det ställs hårdare krav på prestandan. För att uppnå dessa krav behövs stor förståelse för de protokoll och standarder som kan användas. Detta avsnitt har för avsikt att jämföra WebRTC med andra standarder och ta reda på vilken som lämpar sig bäst beroende på ett projekts syfte.
A.1.1
Syfte
Syftet med denna rapport är att undersöka hur WebRTC jämför sig mot andra standarder. Detta för att ta reda på vilka standarder som lämpar sig bäst för vilka typer av projekt. Syftet är också att undersöka om WebRTC skulle kunna användas inom områden som i dagsläget använder en äldre standard.
A.1.2
Frågeställningar
I avsnittet ska följande frågeställningar undersökas och besvaras:
1. Hur jämför sig WebRTC mot andra standarder i ett projekt som detta?
2. Kan (och bör) WebRTC appliceras på andra områden där det idag används andra standarder?
A.2
Bakgrund
Projektets mål var att skapa ett system för att kunna skicka videoströmmar från drönare, via en server, till ett användargränssnitt. Ett krav på låg latens ledde till att vissa protokoll och standarder helt enkelt skulle vara för långsamma. En av de standarder som skulle klara av detta krav var WebRTC. Ingen i projektgruppen var tidigare bekant med WebRTC och det är en relativt ny kommunikationstandard. Bland de mer kända produkterna på marknaden är WebRTC dessutom relativt ovanligt. Det är därför lätt att komma fram till frågan om
A.3. Teori
huruvida det finns en anledning till detta utöver att det är en ny standard, och om WebRTC har några direkta nackdelar.
A.3
Teori
I detta avsnitt förklaras de kommunikationsstandarder och dess underliggande protokoll som är relevanta för jämförelsen.
A.3.1
WebRTC
WebRTC (Web Real-Time Communication) är en kommunikationsstandard som skapar en peer-to-peer-uppkoppling mellan två klienter i ett nätverk [26]. För att göra detta måste en signaling server användas. En signaling server är en web-server som de två klienterna kommunicerar med via en valfri metod, vanligtvis HTTPS. Klienterna använder signaling servern genom att de skickar sin information till den. Denna information innehåller det som krävs för att klienterna ska kunna hitta varandra över internet, däribland IP-address. Om begäran om att starta en kommunikation mellan klienterna accepteras skickar servern klienternas information vidare till den andra. När de har varandras information kan de kommunicera, vilket med WebRTC sker via protokollet UDP. All data som skickas kommer dessutom krypteras automatiskt. Eftersom data som skickas går direkt till mottagaren, utan att först gå via en server kommer uppkopplingen bli snabbare. I figur A.1 visualiseras kommunikation med WebRTC. WebRTC finns implementerat i de flesta stora webbläsare och
Figur A.1: Simpel visualising av WebRTC
kan användas med hjälp av Javascript-API:s. Det finns även självständiga implementationer av WebRTC, där alltså inte en webbläsare behöver användas.
A.3.1.1 UDP (User Datagram Protocol)
UDP använder så kallad ”connectionless communication” vilket innebär att varje dataenhet som skickas innehåller information om vart den ska. På så sätt krävs det ingen inledande dialog mellan de inblandade noderna för att sätta upp kommunikationen. Det sker heller ingen kontroll av att data som skickats har kommit fram, vilket gör protokollet opålitligt men snabbt. Det lämpar sig därför bra för områden där det inte spelar så stor roll om lite data inte kommer fram. Videoströmning är ett att dessa områden, eftersom det är väldigt mycket data som skickas och det innebär inga större konsekvenser om en bildruta går förlorad.
A.3. Teori
A.3.2
RTMP
RTMP (Real-Time Messaging Protocol) är ett protokoll som används för att strömma data mellan en flash player och en server [27]. Flash player är en bit mjukvara som kan köras från en webbläsare. Flash playern kan skicka och ta emot en ström från eller till en Adobe Media Server. Data skickas över TCP, och en videoström mellan två enheter måste alltså gå via en server, som visas i figur A.2.
Figur A.2: RTMP översikt
Först efter att en TCP-anslutning startats mellan en klient och en server kan en RTMP- anslutning startas genom att en speciell handskakning genomförs. Handskakning och all annan data som överförs skickas i så kallade RMTP-paket. Dessa paket innehåller en body och en header. Bodyn innehåller ett Action Message Format-meddelande (AMF-meddelande) och förklaras närmare senare i texten. Headern kan ha varierande storlek och innehåller metadata som beskriver bland annat headerns storlek, paketets storlek och vilken typ av data som skickas. En översikt för en header med storleken 12 bytes visas i figur A.3.
Figur A.3: Header-struktur
• Byte 1: Headerns typ. Bit 1-2 definierar headerns storlek och bit 3-8 definierar Chunk Stream ID.
• Byte 2-4: Timestamp delta. • Byte 5-7: Paketets storlek.
A.3. Teori
• Byte 9-12: Message Stream ID.
Efter handskakningen är genomförd kan anslutningen påbörjas genom att en klient skickar AMF-meddelanden till en server. Figur A.4 visar ett exempel på hur ett AMF-meddelande kan se ut.
Figur A.4: Exempel på AMF-meddelande
AMF-meddelandet skickas i en seriell representation i RTMP-paket. Invoke-fältet bestämmer vilken typ av anrop som ska genomföras. I exemplet används ”connect” vilket skickas från klienten som vill påbörja anslutningen. Servern skickar därefter ett AMF- meddelande tillbaka som svar som innehåller information om huruvida anslutningen lyckats eller inte. Efter att anslutningen lyckats kan en klient ta emot en ström från servern genom att skicka ett AMF-meddelande med inoke-fältet ”createStream” följt av ett med invoke-fältet ”play”. Därefter skickas videodatan i RTMP-paket.
A.3.2.1 TCP (Transmission Control Protocol)
TCP möjliggör pålitlig och felkontrollerad leverans av data. TCP är ”connection-oriented” vilket innebär att en anslutning måste etableras mellan noderna som ska kommunicera innan data kan skickas. Detta görs genom en trestegshandskakning. Detta leder till att protokollet är pålitligt men långsammare än UDP.
A.3.3
HTTP Live Streaming
HTTP Live Streaming (eller HLS) är ett protokoll baserat på HTTP som används för att skicka dataströmmar [28]. HLS-arkitekturen består huvudsakligen av tre komponenter: en serverkomponent, en distributionskomponent och en klientmjukvara.
‚Serverkomponent - Ansvarar för att ta videoinmatningen, göra om den till videokompressionsformatet H.264 och paketera den i MPEG-TS containrar. Därefter delar den upp MPEG-TS-filen i lika stora segment. Den måste också skapa en index-fil som håller koll på hur segmenten ska sättas ihop.
‚Distributionskomponent - Hanterar begäran från klienter och skickar de uppdelade videosegmenten tillsammans med index-filen till klienten med HTTP.
‚Klientmjukvara - Skickar eventuella begäran till distributionskomponenten, tar emot videosegmenten och sätter ihop dem till en kontinuerlig video.
En översikt av detta visas i figur A.5. Arkitekturen innehåller alltså en segmenterare som delar upp mediafilen i segment. Segmentens längd kommer påverka latensen eftersom serverkomponenten inte kan börja skicka data innan åtminstone det första segmentet är färdigt.
A.4. Metod
Figur A.5: Översikt av HLS-arkitekturen
A.4
Metod
Rapporten jämför mediaströmningsstandarden WebRTC med RTMP och HLS. Den åstadkommer detta dels med hjälp av en literaturstudie och dels med en jämförelse till gruppens egna implementation av ett WebRTC-system. De egenskaperna som jämförelsen fokuserar på är latens, pålitlighet och skalbarhet.
A.4.1
Litteraturstudie
För att göra teoretiska jämförelser och för att lägga grunden för den egna implementationen gjordes en litteraturstudie. Detta gjordes genom att använda Google Scholar med sökord som “WebRTC”, “RTMP”, och “HLS”. Artiklarna valdes ut baserat på antalet citeringar de hade.
A.4.2
Implementation
Projektgruppen utvecklade ett system för videoströmning med hjälp av WebRTC. Videoströmmen gick från en Raspberry Pi till ett användargränssnitt via en Google Cloud server (se avsnitt 1). Systemet gick igenom ett antal tester för att undersöka latens, pålitlighet och antal användare som kan ta emot strömmen samtidigt. Resultatet av dessa tester används tillsammans med literaturstudien för att göra jämförelser.
A.5
Resultat
I detta avsnitt presenteras resultaten från literaturstudien och testerna av kandidatgruppens implementation.
A.5.1
Litteraturstudie
A.5.1.1 HLS
HLS har problemet att latensen kommer vara minst lika lång som längden på ett videosegment [29]. Det finns möjlighet att göra segmenten väldigt korta, ner till 200 millisekunder. Med segment i den storleken blir latensen mellan 1 och 5 sekunder för en videoström mellan två enheter på olika nätverk. Pålitligheten och skalbarheten bestäms direkt av serverkomponenten och distributionskomponenten. Serverkomponenten kan skapa flera kopior av videofilen i olika upplösningar. Detta gör det möjligt att anpassa videokvaliteten efter hur bra uppkopplingen är, vilket gör strömmen väldigt pålitlig. Det finns produkter (exempelvis Youtube) som implementerat HLS i stor skala.
A.6. Diskussion
A.5.1.2 RTMP
Ett videströmningssystem som använder RTMP mellan två Flash Players ger en latens på mellan 1 och 2 sekunder [30]. Eftersom strömmen skickas i RTMP-paket som är väldigt små kan data skickas kontinuerligt till skillnad från HLS som måste vänta på att långa videosegment blivit klara. RTMP är beroende av Flash Player och Adobe Media Server. Detta är det som avgör ett RTMP-systems pålitlighet och skalbarhet. RTMP har precis som HLS stöd för anpassningsbar videokvalitet, vilket gör strömmen väldigt pålitlig. Det finns produkter (exempelvis Twitch) som implementerat RTMP i stor skala.
A.5.1.3 WebRTC
WebRTC möjliggör ett videoströmssystem med en latens på under 1 sekund mellan två enheter på olika nätverk [31]. Eftersom ingen server är inblandad i kommunikationen ligger ansvaret för anpassningsbar videokvalitet hos avsändaren. Det blir därför svårare att skapa ett lika pålitligt system som med HLS eller RTMP. Det finns produkter (exempelvis Google Hangouts) som implementerat WebRTC i stor skala.
A.5.2
Implementation
Projektgruppens implementation genomgick tester för att mäta latens, pålitlighet och kapacitet för antal samtidiga användare. Latensen mellan drönare och dator var mellan 0,3 och 0,4 sekunder. För att testa pålitligheten genomfördes ett test där videoströmmen pågick i 6 timmar, vilket den klarade utan problem. Systemet klarade även av fler än 22 användare samtidigt som tog emot strömmen.
A.6
Diskussion
Denna jämförelse baserades endast på en implementation, och använde denna för att jämföra mot resultatet av literaturstudien. Detta medförde problemet att de system som egentligen jämfördes var ganska olika. Det gav fortfarande en överblick av ungefär hur de tre kommunikationsstandarderna presterade i förhållande till varandra, men endast på en ganska oprecis nivå. För att göra en mer ordentlig jämförelse hade det varit intressant att ha tre separata implementationer för att lätt kunna isolera variabler. Om den enda skillnaden mellan dem varit kommunikationsstandarden skulle latensen kunnat jämföras mycket mer exakt. När det kommer till pålitlighet och skalbarhet var det svårt att göra en kvantitativ jämförelse. Alla tre standarder verkade inte ha några problem alls med dessa egenskaper, vilket kanske tyder på att frågan kunde formulerats bättre för att komma fram till något mer användbart. Pålitligheten kanske borde ha jämförts för olika hastigheter på uppkopplingen för att få ett mer intressant resultat. Om denna undersökning ska tas vidare bör mer fokus läggas på implementation.
När det kommer till frågan om huruvida WebRTC bör appliceras på andra områden är det viktigt att ifrågasätta om fördelarna med WebRTC är relevanta för området i fråga. Produkter som har nytta av låg latens är främst de som tillhandahåller någon form utav direktsändning av data. Det måste sedan finnas något i produktens användningsområde som gör denna låga latens viktig, som till exempel hantering av kritiska situationer eller bara bekvämlighet. Detta innebär att antalet områden som skulle kunna förändras märkbart av WebRTC är ganska begränsat.
A.7
Slutsatser
A.7. Slutsatser
Hur jämför sig WebRTC mot andra standarder i ett projekt som detta?
WebRTC ger en betydligt lägre latens än både HLS och RTMP. Det är den enda av de tre som ger en latens på under en sekund. I projektgruppens implementation var den lägre än 0,5 sekunder vilket de andra standarderna inte kommer i närheten av. Vad gäller pålitlighet ligger de alla tre på ungefär samma nivå. Ansvaret för anpassningsbar videokvalitet ligger hos avsändaren vilket kan vara ett problem om internetuppkopplingen är dålig.
Kan (och bör) man applicera WebRTC på andra områden där det idag används andra standarder?
WebRTC har lägre latens än de andra och bör därför användas inom områden där detta är viktigt. När det kommer till att strömma video har det dock inte lika mycket inbyggt stöd för anpassningsbar videokvalitet. Många av de stora videoströmningstjänsterna som använder andra standarder (Youtube, Netflix, Twitch, etc.) har inte något behov av låg latens och det vore därför onödigt för dessa produkter att använda WebRTC. Det kan däremot vara användbart inom områden som övervakning och videosamtal.
B
En jämförelse mellan videokodek
H.264 och VP8 av Robert Almgren
B.1
Inledning
Video konsumeras i stora mängder på alla möjliga plattformar, ofta över nätverk. Med begränsad bandbredd och lagring krävs därför god komprimeringsteknik för att upprätthålla hög kvalitet och prestanda. Idag finns ett flertal olika videokodekar som möjliggör detta. Två populära är H.264 och VP8 som används i de flesta stora webbläsare [32]. Den här rapporten jämför prestanda mellan dessa videokodekar.
B.1.1
Syfte
Syftet med denna utredning är att undersöka hur videokodek H.264 och VP8 jämför sig i prestanda. Den syftar också till att utreda hur en sådan jämförelse kan utföras och vilka fakotorer som kan påverka resultatet.
B.1.2
Frågeställning
Denna utredning behandlar följande frågeställningar: 1. På vilka sätt kan prestanda hos en videokodek mätas? 2. Hur jämför sig H.264 och VP8 i prestanda?
3. Vilka faktorer påverkar en jämförelse i prestanda mellan videokodekar?
B.2
Bakgrund
I projektet användes WebRTC för att strömma video mellan det utvecklade användargränssnittet och Janus-servern. WebRTC har stöd för både videokodek H.264 och VP8. Eftersom kunden ställde krav på videoströmmarnas prestanda fanns därför en anledning att undersöka prestanda hos båda videokodekarna för att se hur de skiljer sig åt.
B.3
Teori
B.3. Teori
B.3.1
Videokodek
Okomprimerad video uppnår snabbt en storlek som blir otymplig att lagra och skicka över nätverk [32]. Detta eftersom varje bildruta består av många pixlar, där varje pixel kan lagra några bytes information om färg. En video innehåller normalt flera bildrutor i sekunden vilket resulterar i stora mängder data. Därför används videokodekar som möjliggör komprimering, kodning och avkodning av video så att inte lika mycket data behövs. Videokodning utnyttjar likheter som förekommer i en bild och mellan bilder i en sekvens för att minska mängden data [33]. För att koda en enskild bild grupperas den in i block av pixlar. Blocken jämförs med närliggande block, som redan har kodats, för att förutspå deras innehåll. För att utnyttja likheter mellan bilder försöker videokodaren förutspå den nuvarande bildens innehåll genom att använda de tidigare kodade bilderna i sekvensen. Detta görs med hjälp av rörelsekompensation som utgår från den första kodade bilden i sekvensen och sparar endast information om skillnaderna i nästkommande bilder.
En videokodek är en standard för kodning och avkodning av video som kan implementeras i mjukvara eller hårdvara [34] [35]. I standarden specificeras bitströmmens syntax som kodaren genererar och hur den bitströmmen ska behandlas i avkodaren [36]. Hur kodaren ska komprimera och koda videon till rätt syntax är inte skrivet i standarden utan det är upp till den som implementerar standarden att bestämma hur det ska göras [37]. Processen för avkodning av bitströmmen är specificerad i standarden och det är därför vanligt att kodningen baseras på den processen fast omvänd.
B.3.2
H.264
H.264 är en videokodningsstandard som används i många olika applikationer som exempelvis DVD/Blu-Ray, TV, videor på Internet och videoströmning [37]. Exempel på mjukvara för kodare och avkodare, vilken implementerar H.264, är x264, JM och FFmpeg [33]. H.264 grupperar in olika inställningar och funktionaliteter i profiler som är lämpliga att använda i olika sammanhang, vilket gör H.264 flexibel [32] [38]. Dessa inställningar och funktionaliteter påverkar komplexitet hos den kodade bitströmmen och påverkar därmed kvaliteten på videon, vilket gör valet av profil viktigt. Utöver en avvägning i komplexitet och kvalitet kan det också vara så att vissa profiler inte stöds i avkodaren. Några exempel på vanliga profiler är Baseline, Main och High, där skillnaderna är kvalitet och komplexitet. Till exempel har Baseline-profilen, på grund av lägre komplexitet, en lägre kvalitet än Main och High. Den lämpar sig bättre för exempelvis applikationer i mobilen, då den ställer mindre krav på avkodaren.
B.3.3
VP8
VP8 är en videokodek som har stor användning i webbläsaren [32]. Det är en öppen och royaltyfri standard som idag ägs idag av Google. Exempel på mjukvara för kodare och avkodare, vilken implementerar VP8, är ffvp8, vpx och FFmpeg [39] [33] [40]. Ett exempel på tekniska detaljer som skiljer VP8 och H.264 åt är hur innehållet i den nuvarande bilden kodas [33]. Till exempel har H.264 och VP8 olika sätt att jämföra närliggande block. VP8 och H.264 skiljer sig också åt i hur många referensbilder som stöds när bilder istället förutspås med hjälp av tidigare kodade bilder i sekvensen.
B.3.4
Mäta prestanda
För att mäta prestanda hos videokodekar finns ett antal olika egenskaper som kan mätas [33] [39]. Exempel på dessa är kodnings- och avkodningshastighet, uppnåd bittakt och storlek på komprimerade formatet. När prestanda ska mätas är det också viktigt att bedömma videokvaliteten. Till hjälp finns både subjektiva och objektiva bedömningar som används för att få fram värden på videokvaliteten [40]. Subjektiva bedömningar är en ofta använd
B.4. Metod
metod som går ut på att videokvaliteten betygsätts av personer. De är dock inte lika vanliga som objektiva bedömningar är eftersom de är svårare att genomföra. Dels kräver de kräver flera testpersoner, dels går det åt mer tid till att genomföra testerna. Objektiva bedömningar är beräkningar som utförs och har fördelen att de kan köras flera gånger. Nedan presenteras några vanliga objektiva bedömningar av videokvalitet.
B.3.4.1 PSNR
Peak Signal-to-Noise Ratio (PSNR) är, för bilder, förhållandet mellan medelkvadratfelet och det största värdet på pixlarnas datatyp i orginalbilden [41] [42]. Medelkvadratfelet beräknar det genomsnittliga felet mellan orginalbilden och den komprimerade bilden. Resultatet ges i decibel där ett högre värde tyder på en högre bildkvalitet. Detta värde på kvalitet kan skilja sig en del från de subjektiva mätningarna eftersom PSNR inte tar hänsyn till visuell perception.
B.3.4.2 SSIM
Structural Similarity Index (SSIM) tar till skillnad från PSNR hänsyn till visuell perception och stämmer bättre överens med de subjektiva bedömningarna [40] [42]. Formeln för SSIM består av funktioner för att beräkna likheter i bildens ljusstyrka, konstrast och struktur. Människor är bra på att upptäcka mönster men inte lika bra på att upptäcka fel [43]. SSIM baseras därför på skillnader i struktur istället för på ett fel mellan bilder, som PSNR gör [40].
B.3.4.3 VQM
Video Quality Metric (VQM) ger ett mått på hur mycket den komprimerade videon är förvrängd genom att mäta på visuella bieffekter från kompressionen [40] [43]. VQM stämmer också bättre överens med de subjektiva mätningarna jämfört med PSNR.
B.3.5
BD-rate
Bjøntegaard delta rate (BD-rate) kan användas för att jämföra effektiviteten på kodningen mellan videokodekar [44]. Jämförelsen görs på ett intervall av kvalitetsvärden, ofta PSNR, för att kunna jämföra bittakten mellan videokodekarna vid samma kvalitetsvärden. BD-rate ger ett mått, i decibel eller procent, på hur mycket bittakt som i genomsnitt går förlorad efter komprimering jämfört med den andra videokodeken [40].
B.4
Metod
Metoden som utfördes var en litteraturstudie. Google Scholar användes som sökmotor för att hitta artiklar och Googles vanliga sökmotor användes för att hitta texten från Internet