det er meget bekvemt og effektivt at organisere forskellige streams til et stort publikum, da man kan indl\u00e6se segmenter \u00e9n gang p\u00e5 CDN.<\/li>\n<\/ul>\n\nP\u00e5 trods af motorens enkelhed er der ikke alt s\u00e5 glat som det ser ud. Hovedproblemet er, at udviklerne af tredjeparts-afspillere er afveget fra Apples anbefalinger, is\u00e6r med hensyn til underst\u00f8ttede lydformater. Is\u00e6r er mange udviklere begyndt at tilf\u00f8je support for popul\u00e6re lydbaser som mpeg2 video, mpeg2 audio osv. Som f\u00f8lge heraf m\u00e5tte der oprettes forskellige formattyper af playlister til forskellige afspillere.<\/p>\n
Men et af de st\u00f8rste problemer med HLS-motoren er den h\u00f8je forsinkelse i datatransmission.<\/p>\n
Oprindelserne til \"forsinkelserne\"<\/h2>\n \nHoved\u00e5rsagen til den h\u00f8je forsinkelse i HLS ligger i, at programm\u00f8rerne skabte motoren for at opn\u00e5 det maksimale billedkvalitet. Derfor er parametrene for den anvendte frame-interval og bufferst\u00f8rrelse til afspilning ikke egnet til live videotransmissioner. Dette f\u00f8rer til en relativt h\u00f8j forsinkelse i videofeedet, som kan v\u00e6re 5-7 sekunder.<\/p>\n
P\u00e5 den ene side er det lidt, eksempelvis for dem, der ser en film fra en video-hostingserver. Men i videooverv\u00e5gningssystemer kan forsinkelsen i videofeedet v\u00e6re af stor betydning.<\/p>\n
Hvis du overv\u00e5ger et kontor, hvor medarbejderne l\u00f8sner sig fra sk\u00e6rmene en gang i timen, betyder en forsinkelse p\u00e5 5 sekunder ingen betydning. Men folk er begyndt at klage over, at for eksempel ved transmissionen af en fodboldkamp allerede er blevet skrevet GOOOOL i chatten, men det er stadig ikke p\u00e5 videoen :). Vi har allerede nogle bruger-cases, hvor Ivideon n\u00e6sten skal erstatte Skype.<\/p>\n
Kan man overvinde forsinkelsen i HLS? Svaret p\u00e5 dette sp\u00f8rgsm\u00e5l lyder som en erfarens rottebek\u00e6mper, der holder en forel\u00e6sning for nybegyndere i skadedyrsbek\u00e6mpelse: \"Rottterne kan ikke udraderes, men deres antal kan reduceres til et rimeligt minimum.\" S\u00e5dan er det ogs\u00e5 med forsinkelsen i HLS, det er ikke muligt at fjerne det helt, men der er l\u00f8sninger p\u00e5 markedet, der v\u00e6sentligt kan reducere forsinkelsen.<\/p>\n
Fin segmentering<\/h2>\n \nEn anden ulempe ved motoren er brugen af sm\u00e5 filer til dataoverf\u00f8rsel. Hvad er der egentlig galt med det?<\/p>\n
Alle, der har fors\u00f8gt at kopiere et stort antal sm\u00e5 filer fra et medie til et andet, har sikkert bem\u00e6rket, at skrivehastigheden for et s\u00e5dant s\u00e6t er meget lavere end for en stor fil af samme st\u00f8rrelse. Intensiteten af adgangen til harddisken stiger ogs\u00e5 betydeligt, hvilket generelt p\u00e5virker computerens ydeevne negativt. Derfor bidrager overf\u00f8rslen af videodata i form af sm\u00e5 10 sekunder lange fragmenter ogs\u00e5 til en \u00f8get latens i motoren.<\/p>\n
Lad os kort opsummere alle fordele og ulemper ved HLS-teknologien.<\/p>\n
Fordele ved HLS:<\/b><\/p>\n\nMulighed for at arbejde med alle enheder. Du kan se video p\u00e5 enhver moderne enhed, hvad enten det er en smartphone, tablet, laptop eller desktop-PC. Det vigtigste er, at webbrowseren er af en moderne version og kompatibel med HTML5 og Media Source Extensions.<\/li>\n Fremragende billedkvalitet. Den anvendte funktion til adaptiv dataoverf\u00f8rsel muligg\u00f8r dynamisk \u00e6ndring af kvaliteten p\u00e5 det transmitterede videobillede baseret p\u00e5 b\u00e5ndbredden af internetforbindelsen, samtidig med at algoritmen str\u00e6ber efter at bevare kvaliteten maksimal.<\/li>\n Der er ikke behov for kompliceret ops\u00e6tning af brugerens udstyr.<\/li>\n<\/ol>\n\nUlemper:<\/b><\/p>\n\nBegr\u00e6nset st\u00f8tte til drift af motoren p\u00e5 nogle enheder.<\/li>\n H\u00f8j latens ved overf\u00f8rsel af billede.<\/li>\n Betydelig stigning i overhead og kompleksitet i optimeringen p\u00e5 grund af brugen af sm\u00e5 filer. P\u00e5 grund af containerens egenskaber vil vi aldrig kunne opn\u00e5 en latens under st\u00f8rrelsen af segmentet.<\/li>\n<\/ol>\n\nUlemperne ved HLS overskygger for os dens fordele og har f\u00e5et os til at lede efter alternative l\u00f8sninger.<\/p>\n
Hvad er WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nWebRTC-platformen blev udviklet af Google i 2011 til transmission af streaming video- og lyddata mellem browsere og mobile applikationer med minimal latens. Dette anvender standardprotokollen UDP og specielle algoritmer til flowkontrol. I dag er det et open source-projekt, der aktivt underst\u00f8ttes og udvikles af Google.<\/p>\n
WebRTC er et s\u00e6t teknologier til peer-to-peer transmission af video og lyd. Det betyder, at brugernes browsere med WebRTC kan overf\u00f8re data direkte til hinanden uden at bruge eksterne servere til opbevaring og behandling af data. Al information behandles ogs\u00e5 af browserne og mobilapplikationerne for slutbrugerne.<\/p>\n
Brugervenligheden og de store muligheder ved denne teknologi er blevet v\u00e6rdsat af udviklerne af alle popul\u00e6re browsere. I dag er WebRTC underst\u00f8ttet i Mozilla Firefox, Opera, Google Chrome (og alle browsere baseret p\u00e5 Chromium), samt i mobilapplikationer til Android og iOS.<\/p>\n
P\u00e5 trods af sine ubestridelige fordele har WebRTC flere v\u00e6sentlige ulemper. <\/p>\n
Vanskeligheder ved valg<\/h2>\n \nWebRTC-teknologien er meget mere kompleks i forhold til netv\u00e6rksinteraktioner, da den er baseret p\u00e5 P2P. Den er sv\u00e6r at fejls\u00f8ge, teste, og den kan opf\u00f8re sig uforudsigeligt. Desuden skal vi overvinde NAT- og firewallproblemer og sikre drift i netv\u00e6rk, hvor UDP er blokeret.<\/p>\n
Google's implementering af WebRTC er meget sv\u00e6r at bruge. Der er endda et helt firma, der tilbyder tjenester til opbygning af SDK. Derudover var det meget vanskeligt at integrere Googles implementering med vores system, s\u00e5 vi ikke skulle re-kode alt video.<\/p>\n
Vi har l\u00e6nge \u00f8nsket at give brugerne mulighed for at arbejde med et fuldt \u2018live\u2019 videoindhold og minimere forsinkelsen i billedet p\u00e5 sk\u00e6rmen i forhold til selve begivenhederne. Desuden ville vi g\u00f8re det mere komfortabelt at bruge PTZ-kameraer, hvor forsinkelser har kritisk betydning.<\/p>\n
Under hensyntagen til, at andre implementeringer til at bek\u00e6mpe lag stadig har begr\u00e6nsede funktioner og fungerer betydeligt d\u00e5rligere, besluttede vi at bruge WebRTC. <\/p>\n
Hvad vi har gjort<\/h2>\n \n
For at WebRTC skal fungere korrekt, er det f\u00f8rst og fremmest n\u00f8dvendigt at gennemf\u00f8re en teknologisk modernisering af stakken til web-video. Det var det, vi gjorde.<\/p>\n
Vi implementerede f\u00f8rst WebRTC signaleringsprotokol over Websocket og satte ogs\u00e5 en WebRTC peer-server op i skyen baseret p\u00e5 SDK fra webrtc.org. Dens opgave er at distribuere videostr\u00f8mme til klientens WebRTC peer i H.264 + Opus\/G.711 format uden at omkode videoen.<\/p>\n
Vi valgte Websocket som signaleringsprotokol, fordi den allerede har solid underst\u00f8ttelse i alle popul\u00e6re webbrowsere. Dette g\u00f8r det muligt at reducere ikke kun udviklingsomkostningerne, men ogs\u00e5 at spare tid og ressourcer p\u00e5 gentagne TCP og TLS handshake i forhold til AJAX.<\/p>\n
Problemet er, at WebRTC som standard ikke giver en signaleringsprotokol, som er n\u00f8dvendig for korrekt ops\u00e6tning, vedligeholdelse og afbrydelse af realtids videokommunikation mellem kilde- og klientapplikationer.<\/p>\n
Og for at implementere signaleringsteknologien selv, var vi n\u00f8dt til at udvikle vores egen signalserver med st\u00f8tte for flere webprotokoller (Websocket, WebRTC). Samt med muligheden for sikker styring af sessioner og notifikationer i realtid, videostyring og mange andre parametre.<\/p>\n
Vi har overvundet P2P-begr\u00e6nsningerne ved at reducere latency, ikke gennem P2P, men ved at bruge UDP og flowkontrol rettet mod at minimere forsinkelsen. Dette er ogs\u00e5 indbygget i WebRTC, da det prim\u00e6re use-case er P2P samtaler gennem browseren.<\/p>\n
I den mobile klient implementerede vi en spiller ved hj\u00e6lp af SDK fra webrtc.org, da kun den har en korrekt implementering af flowkontrol, alle kendte Forward Error Correction (FEC) skemaer, og en ordentlig mekanisme til genudsendelse af pakker for alle browsere. Det er ogs\u00e5 vigtigt, at SDK webrtc.org aktivt udvikles af Google.<\/p>\n
Hvad er resultatet af implementeringen af WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")