Fra de første dage af arbejdet med det cloud-baserede videoovervågningssystem stødte vi på et problem, hvis løsning ville have kostet os alt - det var vores Everest, hvis bestigning tog utallige kræfter, men nu, endelig, har vi plantet issøen i toppen af den multiplatformede gåde.
Systemet til at transmittere lyd og video over internettet må ikke afhænge af hardware, web-klienter og de standarder, de understøtter, og skal fungere korrekt, selv når der er Network Address Translators og firewalls. Brugeren af cloud-videoovervågning ønsker at få adgang til tjenesten, selvom han bruger analoge kameraer, mens han helst ser live video på de mest moderne enheder.
Det er meget vigtigt, at brugeren ønsker at se video med minimal forsinkelse. Den praktisk talt eneste mulighed for at vise video med lav forsinkelse i en browser er at bruge WebRTC (web real-time communications). WebRTC er et sæt teknologier til peer-to-peer transmission af video og lyd i browsere, designet til at sende og afspille videostrømme med lav forsinkelse. Dette sker blandt andet ved hjælp af protokollen UDP.
Før vi fortæller dig, hvad den nye motor giver brugeren, vil vi minde dig om, hvorfor vi understøtter HLS-teknologier, og hvad vi har besluttet at bevæge os videre mod.
HLS-motor: fordele og ulemper
()
HLS-teknologien (HTTP Live Streaming) blev udviklet af Apple, så det er ikke overraskende, at den først blev understøttet på enheder fra dette brand. I dag kan de fleste TV-bokse og mange enheder, der kører på Android, også afspille video i HLS-format.
HLS-motoren bruger den velkendte videokodek H264 til videooverførsel i kombination med AAC- eller MP3-lydstrømme. Hele strømmen af audio- og videodata pakkes ind i transportbeholderen MPEG-TS. For at overføre via HTTP opdeles informationen i strømmen i fragmenter, der beskrives i m3u8-playlister. Først derefter overføres disse fragmenter sammen med playlisterne via HTTP. Opdelingen i fragmenter medfører automatisk en forsinkelse i sekunder. Denne egenskab ved MPEG-TS-beholderen.
HLS-motoren understøtter også multi-bitrate streams, Live/VOD.
De vigtigste fordele ved HLS:
- indbygget support i alle store browsere;
- nem at implementere (sammenlignet med WebRTC);
- det er meget bekvemt og effektivt at organisere forskellige streams til et stort publikum, da man kan indlæse segmenter én gang på CDN.
På trods af motorens enkelhed er der ikke alt så glat som det ser ud. Hovedproblemet er, at udviklerne af tredjeparts-afspillere er afveget fra Apples anbefalinger, især med hensyn til understøttede lydformater. Især er mange udviklere begyndt at tilføje support for populære lydbaser som mpeg2 video, mpeg2 audio osv. Som følge heraf måtte der oprettes forskellige formattyper af playlister til forskellige afspillere.
Men et af de største problemer med HLS-motoren er den høje forsinkelse i datatransmission.
Oprindelserne til "forsinkelserne"
Hovedårsagen til den høje forsinkelse i HLS ligger i, at programmørerne skabte motoren for at opnå det maksimale billedkvalitet. Derfor er parametrene for den anvendte frame-interval og bufferstørrelse til afspilning ikke egnet til live videotransmissioner. Dette fører til en relativt høj forsinkelse i videofeedet, som kan være 5-7 sekunder.
På den ene side er det lidt, eksempelvis for dem, der ser en film fra en video-hostingserver. Men i videoovervågningssystemer kan forsinkelsen i videofeedet være af stor betydning.
Hvis du overvåger et kontor, hvor medarbejderne løsner sig fra skærmene en gang i timen, betyder en forsinkelse på 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å videoen :). Vi har allerede nogle bruger-cases, hvor Ivideon næsten skal erstatte Skype.
Kan man overvinde forsinkelsen i HLS? Svaret på dette spørgsmål lyder som en erfarens rottebekæmper, der holder en forelæsning for nybegyndere i skadedyrsbekæmpelse: "Rottterne kan ikke udraderes, men deres antal kan reduceres til et rimeligt minimum." Sådan er det også med forsinkelsen i HLS, det er ikke muligt at fjerne det helt, men der er løsninger på markedet, der væsentligt kan reducere forsinkelsen.
Fin segmentering
En anden ulempe ved motoren er brugen af små filer til dataoverførsel. Hvad er der egentlig galt med det?
Alle, der har forsøgt at kopiere et stort antal små filer fra et medie til et andet, har sikkert bemærket, at skrivehastigheden for et sådant sæt er meget lavere end for en stor fil af samme størrelse. Intensiteten af adgangen til harddisken stiger også betydeligt, hvilket generelt påvirker computerens ydeevne negativt. Derfor bidrager overførslen af videodata i form af små 10 sekunder lange fragmenter også til en øget latens i motoren.
Lad os kort opsummere alle fordele og ulemper ved HLS-teknologien.
Fordele ved HLS:
- Mulighed for at arbejde med alle enheder. Du kan se video på 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.
- Fremragende billedkvalitet. Den anvendte funktion til adaptiv dataoverførsel muliggør dynamisk ændring af kvaliteten på det transmitterede videobillede baseret på båndbredden af internetforbindelsen, samtidig med at algoritmen stræber efter at bevare kvaliteten maksimal.
- Der er ikke behov for kompliceret opsætning af brugerens udstyr.
Ulemper:
- Begrænset støtte til drift af motoren på nogle enheder.
- Høj latens ved overførsel af billede.
- Betydelig stigning i overhead og kompleksitet i optimeringen på grund af brugen af små filer. På grund af containerens egenskaber vil vi aldrig kunne opnå en latens under størrelsen af segmentet.
Ulemperne ved HLS overskygger for os dens fordele og har fået os til at lede efter alternative løsninger.
Hvad er WebRTC
()
WebRTC-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øttes og udvikles af Google.
WebRTC er et sæt teknologier til peer-to-peer transmission af video og lyd. Det betyder, at brugernes browsere med WebRTC kan overføre data direkte til hinanden uden at bruge eksterne servere til opbevaring og behandling af data. Al information behandles også af browserne og mobilapplikationerne for slutbrugerne.
Brugervenligheden og de store muligheder ved denne teknologi er blevet værdsat af udviklerne af alle populære browsere. I dag er WebRTC understøttet i Mozilla Firefox, Opera, Google Chrome (og alle browsere baseret på Chromium), samt i mobilapplikationer til Android og iOS.
På trods af sine ubestridelige fordele har WebRTC flere væsentlige ulemper.
Vanskeligheder ved valg
WebRTC-teknologien er meget mere kompleks i forhold til netværksinteraktioner, da den er baseret på P2P. Den er svær at fejlsøge, teste, og den kan opføre sig uforudsigeligt. Desuden skal vi overvinde NAT- og firewallproblemer og sikre drift i netværk, hvor UDP er blokeret.
Google's implementering af WebRTC er meget svær 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å vi ikke skulle re-kode alt video.
Vi har længe ønsket at give brugerne mulighed for at arbejde med et fuldt ‘live’ videoindhold og minimere forsinkelsen i billedet på skærmen i forhold til selve begivenhederne. Desuden ville vi gøre det mere komfortabelt at bruge PTZ-kameraer, hvor forsinkelser har kritisk betydning.
Under hensyntagen til, at andre implementeringer til at bekæmpe lag stadig har begrænsede funktioner og fungerer betydeligt dårligere, besluttede vi at bruge WebRTC.
Hvad vi har gjort
At implementere WebRTC-platformen korrekt er en udfordrende opgave. Enhver fejl eller unøjagtighed kan føre til, at forsinkelsen i videotransmission ikke kun ikke reduceres sammenlignet med andre platforme, men også kan øges.
For at WebRTC skal fungere korrekt, er det først og fremmest nødvendigt at gennemføre en teknologisk modernisering af stakken til web-video. Det var det, vi gjorde.
Vi implementerede først WebRTC signaleringsprotokol over Websocket og satte også en WebRTC peer-server op i skyen baseret på SDK fra webrtc.org. Dens opgave er at distribuere videostrømme til klientens WebRTC peer i H.264 + Opus/G.711 format uden at omkode videoen.
Vi valgte Websocket som signaleringsprotokol, fordi den allerede har solid understøttelse i alle populære webbrowsere. Dette gør det muligt at reducere ikke kun udviklingsomkostningerne, men også at spare tid og ressourcer på gentagne TCP og TLS handshake i forhold til AJAX.
Problemet er, at WebRTC som standard ikke giver en signaleringsprotokol, som er nødvendig for korrekt opsætning, vedligeholdelse og afbrydelse af realtids videokommunikation mellem kilde- og klientapplikationer.
Og for at implementere signaleringsteknologien selv, var vi nødt til at udvikle vores egen signalserver med støtte for flere webprotokoller (Websocket, WebRTC). Samt med muligheden for sikker styring af sessioner og notifikationer i realtid, videostyring og mange andre parametre.
Vi har overvundet P2P-begrænsningerne ved at reducere latency, ikke gennem P2P, men ved at bruge UDP og flowkontrol rettet mod at minimere forsinkelsen. Dette er også indbygget i WebRTC, da det primære use-case er P2P samtaler gennem browseren.
I den mobile klient implementerede vi en spiller ved hjælp 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å vigtigt, at SDK webrtc.org aktivt udvikles af Google.
Hvad er resultatet af implementeringen af WebRTC?
For at se live video fra kameraer har vi tilføjet en ny optimeret spiller baseret på WebRTC til brugerens konto. Den sikrer høj videoloadningshastighed og eliminerer fuldstændigt problemet med forsinkelsesmængde over tid ved visningen.
Efter implementeringen af WebRTC-support i Ivideons cloudservice kan vi med fuld sikkerhed sige, at vores kunder nu har adgang til at se fuldt live-video. I øjeblikket er forsinkelsen ved streaming af video ikke mere end ét sekund! Til sammenligning gav den tidligere HLS-motor video med en forsinkelse på 5-7 sekunder. Forskellen i hastighed på videoafspilningen er meget væsentlig, og brugeren vil straks bemærke den efter at have begyndt at bruge vores videoservice.
Som vi forudsagde, har implementeringen af den nye afspiller forbedret responsen fra PTZ og stemmesamtalen med kameraet.
Der er kun ét fint punkt, som vi ønsker at påpege. Den nye WebRTC-afspiller fungerer stadig i testmode. Derfor aktiverer vi den ikke som standard for alle vores kunder. Men du kan aktivere den selv ved at tænde for den relevante indstilling i kamerainstillingerne (for at gøre dette skal du gå til ).
Funktioner ved implementeringen af WebRTC i Ivideon-service
WebRTC er i øjeblikket stadig en eksperimentel teknologi. Dens support er stadig ikke korrekt implementeret i alle browsere og brugerudstyr samt ikke i alle kameraer.
Dette er netop grunden til, at vi endnu ikke har gjort WebRTC-afspilleren til standard for alle brugere.
Indtil videre anbefaler vi at bruge WebRTC kun i Google Chrome-browsere. De seneste versioner af Firefox og Safari understøtter også denne teknologi, men desværre er de stadig ustabile.
Vi har endnu ikke implementeret WebRTC-support til browsere på mobile enheder. I øjeblikket, hvis du logger ind fra en mobile enhed og aktiverer WebRTC, vil denne tilstand ikke fungere. Men WebRTC er tilgængeligt i vores mobile applikationer til og .
Og for at afslutte fortællingen om funktionerne ved implementeringen af WebRTC i vores service, lad os fremhæve yderligere to fine punkter.
For det første er teknologien designet til at streame netop live-video i realtid. Derfor, hvis båndbredden på din kanal er utilstrækkelig til at overføre video, vil du bemærke, at der falder billedeudfald (med HLS vil du bemærke video-stillinger og øget forsinkelse, men billederne vil ikke falde ud), men videoen vil stadig blive streamet i realtid.
For det andet, da teknologien er designet til at arbejde med live video i realtid, bruger vi den ikke til at arbejde med arkiverede videodata.
Andre ændringer i tjenesten
I øjeblikket deltager Flash ikke længere i mekanismen for automatisk valg af motoren. Du kan stadig bruge sådan en afspiller, men du skal vælge den manuelt i indstillingerne for din konto eller kameraet. Dette er ikke en modefænomen, men ifølge vores service-statistik er der næsten ikke brugere tilbage, der arbejder med Flash. Og ved at forsøge at bestemme, om brugerens browser understøtter det, mister vi omkring 2 sekunder af værdifuld tid.
Her er en kort oversigt over de ændringer, du kan forvente i vores cloud-videosystem og din konto. Bliv hos os og følg med i nyhederne!
Kilde: habr.com
