
Fra de første dage, hvor vi arbejdede på et cloud-videoovervågningssystem, stod vi over for et problem, uden en løsning, som vi kunne give op på Ivideon - dette var vores Everest-bestigning, som tog en masse energi, men nu har vi endelig stak en isøkse ind i toppen af cross-platform puslespillet.
Systemet til at overføre lyd og video over internettet bør ikke afhænge af udstyr, webklienter og de standarder, de understøtter, og fungerer også korrekt i nærværelse af netværksadresseoversættere og firewalls. En cloud-videoovervågningsbruger ønsker at få adgang til tjenesten, selvom han bruger analoge kameraer, og foretrækker at se live videoudsendelse på den mest moderne enhed.
Det er meget vigtigt, at brugeren ønsker at se videoer med minimal forsinkelse. Næsten den eneste måde at vise video med lav latency i en browser er at bruge WebRTC (web-realtidskommunikation). WebRTC er et sæt teknologier til peer-to-peer transmission af video og lyd i browsere, oprindeligt designet til transmission og afspilning af videostreams med lav latens. Til dette formål anvendes blandt andet UDP-protokollen.
Før vi fortæller dig, hvad den nye motor giver brugeren, vil vi minde dig om, hvorfor og hvorfor vi understøtter HLS-teknologier, og hvorfor vi besluttede at gå videre.
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å Apple-enheder. I dag understøttes HLS-video også af stort set alle set-top-bokse og mange enheder, der kører operativsystemet. Android.
HLS-motoren bruger det velkendte H264-video-codec i kombination med AAC- eller MP3-lydstreams til at streame videodata. Hele lyd- og videodatastrømmen er pakket ind i en MPEG-TS transportbeholder. Til transmission via HTTP-protokollen er informationen i strømmen opdelt i fragmenter beskrevet i m3u8-afspilningslister. Og først derefter overføres disse fragmenter sammen med afspilningslister via HTTP. Chunking betyder automatisk en forsinkelse i sekunder. Dette er en funktion af MPEG-TS-beholderen.
HLS-motoren understøtter også multibitrate-streams, Live/VOD.
De vigtigste fordele ved HLS:
- indbygget support i alle større browsere;
- let implementering (sammenlignet med WebRTC);
- Det er meget bekvemt og effektivt at organisere alle former for udsendelser til et stort publikum på grund af det faktum, at segmenter kan uploades til et CDN én gang.
På trods af motorens enkelhed er alt ikke så glat, som det ser ud til. Hovedproblemet er, at tredjeparts-afspillerudviklere har bevæget sig væk fra Apples anbefalinger, for eksempel med hensyn til understøttede lydformater. Især begyndte mange udviklere at tilføje muligheden for at arbejde med populære lydstreams: mpeg2-video, mpeg2-lyd osv. Som et resultat var de nødt til at oprette forskellige spillelisteformater til forskellige afspillere.
Men et af de største problemer med HLS-motoren er den høje latens i dataoverførsel.
Oprindelsen af "bremser"
Hovedårsagen til den høje latenstid af HLS ligger i, at programmører skabte motoren til at opnå billeder af højeste kvalitet. Derfor er parametrene for det anvendte billedinterval og størrelsen af afspilningsbufferen simpelthen ikke egnede til live videoudsendelser. På grund af dette er der en ret stor forsinkelse i transmissionen af videooptagelser, som kan være 5-7 sekunder.
På den ene side er det ikke meget, for eksempel for dem, der ser en film fra en videohostingserver. Men for videoovervågningssystemer kan forsinkelsen i transmissionen af videooptagelser være meget vigtig.
Hvis du holder øje med et kontor, hvor medarbejdere kigger op fra deres skærme en gang i timen, så betyder en forsinkelse på 5 sekunder slet ikke noget. Men folk begyndte at brokke sig over, at de for eksempel, når de sendte en fodboldkamp, allerede skrev GOOOOL i chatten, men det er endnu ikke på videoen :). Vi har allerede en række brugersager, hvor Ivideon praktisk talt burde erstatte Skype.
Er det muligt at slå latens i HLS? Svaret på dette spørgsmål lyder som talen fra en erfaren rotteudrydder ved et foredrag for uerfarne skadedyrsbekæmpere: "Rotter kan ikke udryddes, men deres antal kan reduceres til et rimeligt minimum." Samme med forsinkelsen i HLS vil det ikke være muligt at reducere den til nul, men der findes løsninger på markedet, der kan reducere forsinkelsen markant.
Fine snit
En anden ulempe ved motoren er brugen af små filer til dataoverførsel. Det ser ud til, at hvad er der galt med dette?
Enhver, 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 en stor fil af samme størrelse. Og intensiteten af adgangen til harddisken øges markant, hvilket generelt påvirker hele computerens ydeevne negativt. Derfor bidrager overførsel af videodata i små 10 sekunders bidder også til øget motorforsinkelse.
Lad os kort opsummere alle fordele og ulemper ved HLS-teknologi.
Fordele ved HLS:
- Evne til at arbejde med enhver enhed. Du kan se videoer på enhver moderne enhed, hvad enten det er en smartphone, tablet, bærbar eller stationær pc. Det vigtigste er, at webbrowseren er up-to-date og kompatibel med HTML5 og Media Source Extensions.
- Fremragende billedkvalitet. Den anvendte adaptive datatransmissionsfunktion giver dig mulighed for dynamisk at ændre kvaliteten af den transmitterede video afhængigt af internetforbindelsens båndbredde, mens algoritmen stræber efter at opretholde maksimal kvalitet.
- Der er ikke behov for kompleks konfiguration af brugerens udstyr.
Ulemper:
- Begrænset support til at arbejde med motoren på nogle enheder.
- Store forsinkelser i billedtransmission.
- Betydelig stigning i overhead og kompleksitet af optimering på grund af brugen af små filer. På grund af containerens beskaffenhed vil vi aldrig kunne få en forsinkelse, der er lavere end segmentstørrelsen.
Ulemperne ved HLS opvejede dets fordele for os og tvang os til at lede efter alternative muligheder.
Hvad er WebRTC

()
WebRTC-platformen blev udviklet af Google i 2011 til at overføre streaming af video- og lyddata mellem browsere og mobilapplikationer med minimal latenstid. Til dette bruges standard UDP-protokollen og specielle flowkontrolalgoritmer. I dag er det et open source-projekt, det vedligeholdes aktivt af Google og er under udvikling.
WebRTC er et sæt teknologier til peer-to-peer video- og lydtransmission. Det vil sige, at brugerbrowsere, der bruger WebRTC, for eksempel kan overføre data til hinanden direkte, uden at bruge fjernservere til lagring og behandling af data. Alle oplysninger behandles også af slutbrugeres browsere og mobilapplikationer.
Denne teknologis bekvemmelighed og omfattende muligheder er blevet værdsat af udviklere af alle populære browsere. WebRTC-understøttelse er i øjeblikket tilgængelig i Mozilla Firefox, Opera, Google Chrome (og alle Chromium-baserede browsere) samt i mobilapps, der kører Android og iOS.
På trods af alle sine utvivlsomme fordele har WebRTC flere væsentlige ulemper.
Vanskeligheder ved at vælge
WebRTC-teknologi er meget mere kompleks med hensyn til netværksinteraktioner på grund af det faktum, at det handler om P2P. Det er svært at fejlsøge, teste og kan opføre sig uforudsigeligt. Samtidig skal vi overvinde NAT og firewall, vi skal sikre drift i netværk, hvor UDP er blokeret.
Googles WebRTC-implementering er meget vanskelig at bruge. Der er endda et helt firma, der leverer SDK-montagetjenester. Desuden var Googles implementering meget vanskelig at integrere med vores system uden at omkode hele videoen.
Vi har dog længe ønsket at give brugerne mulighed for at arbejde med fuldgyldig "live" video og minimere forsinkelsen mellem billedet på skærmen og selve begivenhederne. Derudover havde vi et ønske om at gøre brugen af PTZ-kameraer, hvor forsinkelser er kritiske, mere behagelig.
I betragtning af at andre anti-lag-implementeringer stadig har begrænset funktionalitet og virker mærkbart dårligere, besluttede vi at bruge WebRTC.
Hvad har vi gjort

Korrekt implementering af WebRTC-platformen er ikke en let opgave. Enhver fejlberegning eller unøjagtighed kan føre til, at forsinkelser i videotransmission ikke blot ikke falder sammenlignet med andre platforme, men endda stiger.
For at WebRTC skal fungere korrekt, er det først og fremmest nødvendigt at udføre en teknologisk opgradering af stakken for at arbejde med webvideo. Det var, hvad vi gjorde.
Først implementerede vi en WebRTC-signalprotokolserver over Websocket og implementerede også en WebRTC-peer-server i skyen baseret på webrtc.org SDK. Dens opgave er at distribuere videostreams til klient WebRTC-peers i H.264 + Opus/G.711-format uden videoomkodning.
Vi valgte Websocket som signaleringsprotokollen, fordi den allerede har højkvalitetsunderstøttelse i alle populære webbrowsere. På grund af dette kan du reducere ikke kun udviklingsomkostninger markant, men også undgå at spilde tid og ressourcer på gentagne TCP- og TLS-håndtryk sammenlignet med AJAX.
Faktum er, at WebRTC som standard ikke leverer den signaleringsprotokol, der er nødvendig for korrekt at konfigurere, vedligeholde og afslutte videokommunikation i realtid mellem kilden og klientapplikationerne.
Og for selvstændigt at implementere signalteknologi, var vi nødt til at udvikle vores egen signalserver med understøttelse af flere webprotokoller (Websocet, WebRTC). Og med muligheden for sikkert at administrere sessioner og notifikationer i realtid, videostyring og meget mere.
Vi overvandt begrænsningerne ved P2P ved at reducere latens, ikke gennem P2P, men gennem UDP og flowkontrol for at reducere latens. Dette er også indbygget i WebRTC, da den primære use-case er p2p-samtaler via en browser.
I mobilklienten implementerede vi afspilleren ved hjælp af webrtc.org SDK, da kun den implementerer flowkontrol korrekt, har alle de kendte Forward Error Correction (FEC)-skemaer og implementerer korrekt mekanismen til at gensende pakker til alle browsere. Det er også vigtigt, at webrtc.org SDK aktivt udvikles af Google.
Hvad er resultatet af implementering af WebRTC?
For at se live video fra kameraer har vi tilføjet en ny optimeret afspiller baseret på WebRTC til din personlige konto. Det giver hurtige videoindlæsningshastigheder og eliminerer fuldstændigt problemet med latenstid, der akkumuleres efterhånden som visningstiden stiger.
Efter at have introduceret WebRTC-support i Ivideon-skytjenesten, kan vi med fuld tillid sige, at vores kunder nu kan se fuldgyldig live-video. Nu overstiger forsinkelsen ved udsendelse af videosekvenser ikke et sekund! Til sammenligning leverede den tidligere HLS-motor videolevering med en forsinkelse på 5-7 sekunder. Forskellen i videodemonstrationshastighed er meget betydelig, og brugeren vil bemærke det umiddelbart efter, at de er begyndt at arbejde med vores videotjeneste.
Som vi forventede, har implementeringen af den nye afspiller forbedret reaktionsevnen af PTZ og stemmekommunikation med kameraet.

Der er kun én subtil pointe, som vi ønsker at henlede opmærksomheden på. Den nye WebRTC-afspiller arbejder i øjeblikket i testtilstand. Og det er derfor, vi som standard ikke aktiverer det for alle vores kunder. Men du kan selv aktivere det ved at aktivere det tilsvarende element i kameraindstillingerne (for at gøre dette skal du gå til ).
Funktioner ved implementeringen af WebRTC i Ivideon-tjenesten

WebRTC er stadig en eksperimentel teknologi i øjeblikket. Dens support er endnu ikke korrekt implementeret i alle browsere og brugerenheder, og heller ikke i alle kameraer.
Det er netop derfor, vi endnu ikke har gjort WebRTC-afspilleren til standard for alle brugere.
Indtil videre anbefaler vi kun at bruge WebRTC i Google Chrome-browsere. De nyeste versioner af Firefox og Safari understøtter også denne teknologi, men den er desværre stadig ustabil.
Vi har endnu ikke implementeret WebRTC-understøttelse af browsere på mobile enheder. I øjeblikket, hvis du logger ind fra en mobilenhed og aktiverer WebRTC, vil denne tilstand ikke fungere. WebRTC er dog tilgængelig i vores mobilapplikationer til и .
Og for at afslutte historien om funktionerne i WebRTC-implementeringen i vores tjeneste, lad os bemærke to mere subtile punkter.
For det første er teknologien fokuseret på at udsende live video i realtid. Derfor, hvis din kanal ikke har nok båndbredde til at transmittere videoen, vil du bemærke frame drops (med HLS vil du bemærke videofading og øget latens, men der vil ikke være nogen frame drop), men videoen vil stadig blive udsendt i realtid tid.
For det andet, da teknologien er designet til at arbejde specifikt med live video i realtid, bruger vi den ikke til at arbejde med arkiverede videodata.
Andre ændringer i tjenesten
På nuværende tidspunkt er Flash ikke længere involveret i den automatiske motorvalgsmekanisme. Du kan stadig bruge sådan en afspiller, men for at gøre dette skal du vælge den manuelt i konto- eller kameraindstillingerne. Dette er ikke en hyldest til mode, det er bare, at ifølge statistikkerne for vores tjeneste er der praktisk talt ingen brugere tilbage, der arbejder med Flash. Og ved at prøve at afgøre, om brugerens browser understøtter det, mister vi omkring 2 sekunder af kostbar tid.
Her er en kort oversigt over de ændringer, der venter dig i vores cloud-videoovervågningssystem og personlige konto. Bliv hos os og følg nyhederne!
Kilde: www.habr.com
