Fra de første dagene vi jobbet med skybasert videoovervåkingssystem, møtte vi på et problem uten en løsning som Ivideon kunne ha blitt avskrevet på – det var vår Everest, som bestigningen krevde mye innsats, men nå har vi endelig stukket en isøks i toppen av kryssplattformpuslespillet.
Systemet for overføring av lyd og video via Internett bør ikke avhenge av utstyr, webklienter og standardene de støtter, og bør også fungere korrekt i nærvær av nettverksadresseoversettere og brannmurer. Brukeren av skybasert videoovervåking ønsker å få tilgang til tjenesten selv om vedkommende bruker analoge kameraer, og foretrekker å se direktesendte videosendinger på den mest moderne enheten.
Det er svært viktig at brukeren ønsker å se video med minimal forsinkelse. Nesten den eneste måten å vise video med lav forsinkelse i nettleseren er å bruke WebRTC (web real-time communications). WebRTC er et sett med teknologier for peer-to-peer-overføring av video og lyd i nettlesere, opprinnelig designet for overføring og avspilling av videostrømmer med lav forsinkelse. Til dette brukes blant annet UDP-protokollen.
Før vi forteller deg hva den nye motoren gir brukeren, vil vi minne deg på hvorfor og hvordan vi støtter HLS-teknologier, og hvorfor vi bestemte oss for å gå videre.
HLS-motor: Fordeler og ulemper
()
HLS-teknologien (HTTP Live Streaming) ble utviklet av Apple, så det er ingen overraskelse at den først ble støttet på Apple-enheter. I dag støttes HLS-video også av så godt som alle dekodere og mange enheter som kjører operativsystemet. Android.
HLS-motoren bruker den velkjente H264-videokodeken i kombinasjon med AAC- eller MP3-lydstrømmer for strømming av videodata. Hele lyd- og videodatastrømmen pakkes inn i en MPEG-TS-transportcontainer. For overføring via HTTP-protokollen deles informasjonen i strømmen inn i fragmenter beskrevet i m3u8-spillelister. Og først da overføres disse fragmentene, sammen med spillelistene, via HTTP. Inndeling i fragmenter betyr automatisk en forsinkelse på sekunder. Dette er en funksjon i MPEG-TS-containeren.
HLS-motoren støtter også strømmer med flere bithastigheter, Live/VOD.
De viktigste fordelene med HLS:
- innebygd støtte i alle større nettlesere;
- enkel implementering (sammenlignet med WebRTC);
- Det er veldig praktisk og effektivt å organisere alle slags sendinger til et stort publikum fordi segmenter kan lastes opp til CDN-et én gang.
Til tross for motorens enkelhet, er ikke alt så knirkefritt som det ser ut til. Hovedproblemet er at utviklere av tredjepartsspillere har avveket fra Apples anbefalinger, for eksempel når det gjelder støttede lydformater. Spesielt begynte mange utviklere å legge til muligheten til å jobbe med populære lydstrømmer: mpeg2-video, mpeg2-lyd, osv. Som et resultat var det nødvendig å lage forskjellige spillelisteformater for forskjellige spillere.
Men et av de største problemene med HLS-motoren er den høye latensen i dataoverføringen.
Opprinnelsen til «bremser»
Hovedårsaken til den høye latensen til HLS er at programmerere har laget motoren for å oppnå bildekvalitet av høyeste kvalitet. Derfor er parametrene for bildeintervallet som brukes og volumet på avspillingsbufferen rett og slett ikke egnet for direktesendinger. På grunn av dette er det en ganske høy forsinkelse i overføringen av videosekvensen, som kan være 5–7 sekunder.
På den ene siden er ikke dette mye, for eksempel for de som ser en film fra en videovertserver. Men for videoovervåkingssystemer kan forsinkelsen i videooverføringen være svært viktig.
Hvis du observerer et kontor der ansatte river seg løs fra skjermene sine én gang i timen, spiller en 5-sekunders forsinkelse ingen rolle i det hele tatt. Men folk begynte å klage over at de for eksempel allerede skrev GOOOAL i chatten når de sendte en fotballkamp, men det er ikke på videoen ennå :). Vi har allerede en rekke brukertilfeller der Ivideon praktisk talt burde erstatte Skype.
Er det mulig å overvinne forsinkelsen i HLS? Svaret på dette spørsmålet høres ut som en erfaren rotteutrydder som gir et foredrag til nybegynnere innen rotteutryddelse: «Rotter kan ikke utryddes, men bestanden deres kan reduseres til et rimelig minimum.» Det samme gjelder forsinkelsen i HLS, det vil ikke være mulig å eliminere den til null, men det finnes løsninger på markedet som kan redusere forsinkelsen betydelig.
Finhakket
En annen ulempe med motoren er bruken av små filer for dataoverføring. Hva er galt med det, lurer du kanskje på?
Alle som har prøvd å kopiere et stort antall små filer fra ett lagringsmedium til et annet, har sannsynligvis lagt merke til at opptakshastigheten til et slikt sett er mye lavere enn for én stor fil av samme størrelse. Og intensiteten på tilgangen til harddisken øker betydelig, noe som generelt har en negativ effekt på ytelsen til hele datamaskinen. Derfor bidrar overføringen av videodata i form av små 10-sekunders fragmenter også til den økte forsinkelsen til motoren.
La oss kort oppsummere alle fordeler og ulemper med HLS-teknologi.
Fordeler med HLS:
- Mulighet for å jobbe med alle enheter. Du kan se videoer på alle moderne enheter, enten det er en smarttelefon, nettbrett, bærbar PC eller stasjonær PC. Det viktigste er at nettleseren er en moderne versjon og kompatibel med HTML5 og mediekildeutvidelser.
- Utmerket bildekvalitet. Den adaptive dataoverføringsfunksjonen som brukes, tillater dynamisk endring av kvaliteten på den overførte videosekvensen avhengig av båndbredden til internettforbindelsen, mens algoritmen streber etter å opprettholde kvaliteten så høy som mulig.
- Det er ikke behov for kompleks konfigurasjon av brukerutstyr.
Ulemper:
- Begrenset støtte for å jobbe med motoren på enkelte enheter.
- Store forsinkelser i bildeoverføringen.
- Sterk økning i overhead og vanskeligheter med optimalisering på grunn av bruk av små filer. På grunn av containerens natur kan vi aldri få en latens som er mindre enn segmentstørrelsen.
Ulempene med HLS oppveide fordelene for oss og tvang oss til å se etter alternative alternativer.
Hva er WebRTC
()
WebRTC-plattformen ble utviklet av Google i 2011 for å overføre strømming av video og lyddata mellom nettlesere og mobilapplikasjoner med minimal forsinkelse. Den bruker standard UDP-protokoll og spesielle flytkontrollalgoritmer. I dag er det et åpen kildekode-prosjekt, aktivt støttet og utviklet av Google.
WebRTC er et sett med teknologier for peer-to-peer-overføring av video og lyd. Det vil si at for eksempel brukernes nettlesere som bruker WebRTC kan overføre data direkte til hverandre, uten å bruke eksterne servere til å lagre og behandle data. All informasjon behandles også av sluttbrukernes nettlesere og mobilapplikasjoner.
Bekvemmeligheten og de omfattende funksjonene til denne teknologien har blitt verdsatt av utviklere av alle populære nettlesere. WebRTC-støtte er for øyeblikket tilgjengelig i Mozilla Firefox, Opera, Google Chrome (og alle Chromium-baserte nettlesere), samt i mobilapper som kjører Android og iOS.
Til tross for alle sine utvilsomme fordeler, har WebRTC flere betydelige ulemper.
Vanskeligheter med valg
WebRTC-teknologi er mye mer kompleks når det gjelder nettverksinteraksjoner fordi den handler om P2P. Den er vanskelig å feilsøke og teste, og den kan oppføre seg uforutsigbart. Samtidig må vi overvinne NAT og brannmur, og vi må sikre drift i nettverk der UDP er blokkert.
Googles WebRTC-implementering er svært vanskelig å bruke. Det finnes til og med et helt selskap som tilbyr SDK-assemblingstjenester. I tillegg var Googles implementering svært vanskelig å integrere med systemet vårt uten å kode hele videoen på nytt.
Vi har imidlertid lenge ønsket å gi brukerne muligheten til å jobbe med en fullverdig «live» videosekvens og minimere forsinkelsen i bildet på skjermen fra selve hendelsene. I tillegg ønsket vi å gjøre det mer praktisk å bruke PTZ-kameraer, der forsinkelser er kritiske.
Med tanke på at andre anti-lag-implementeringer fortsatt har begrenset funksjonalitet og fungerer merkbart dårligere, bestemte vi oss for å bruke WebRTC.
Hva har vi gjort
Det er ikke lett å implementere WebRTC-plattformen riktig. Enhver feilberegning eller unøyaktighet kan føre til at forsinkelser i videooverføring ikke bare ikke vil reduseres sammenlignet med andre plattformer, men også øke.
For at WebRTC skal fungere riktig, er det først og fremst nødvendig å gjennomføre en teknologisk modernisering av stakken for å jobbe med webvideo. Det var det vi gjorde.
Først implementerte vi en WebRTC-signalprotokollserver over Websocket, og distribuerte også en WebRTC-peer-server i skyen basert på webrtc.org SDK. Dens oppgave er å distribuere videostrømmer til klientens WebRTC-peer i H.264 + Opus/G.711-format uten videoomkoding.
Vi valgte Websocket som signalprotokoll fordi den allerede har støtte av høy kvalitet i alle populære nettlesere. På grunn av dette er det mulig å redusere ikke bare de faste utviklingskostnadene betydelig, men også å ikke kaste bort tid og ressurser på gjentatte TCP- og TLS-håndtrykk sammenlignet med AJAX.
Poenget er at WebRTC som standard ikke tilbyr signalprotokollen som er nødvendig for å sette opp, vedlikeholde og rive ned en sanntidsvideoforbindelse mellom kilden og klientapplikasjonene.
Og for å kunne implementere signalteknologien uavhengig, måtte vi utvikle vår egen signalserver med støtte for flere webprotokoller (Websocet, WebRTC). Og også med muligheten til å administrere økter og varsler sikkert i sanntid, videohåndtering og mange andre parametere.
Vi overvant P2P-begrensningene ved å redusere latens, ikke gjennom P2P, men gjennom UDP og flytkontroll som har som mål å redusere latens. Dette er også innebygd i WebRTC, siden hovedbruksscenariet er P2P-samtaler via en nettleser.
I mobilklienten implementerte vi spilleren ved hjelp av webrtc.org SDK, siden bare den har korrekt implementert flytkontroll, alle kjente Forward Error Correction (FEC)-ordninger og en korrekt implementert mekanisme for å sende pakker på nytt for alle nettlesere. Det er også viktig at webrtc.org SDK aktivt utvikles av Google.
Hva er resultatet av å implementere WebRTC?
For å se direktesendt video fra kameraer har vi lagt til en ny optimalisert spiller basert på WebRTC til din personlige konto. Den gir rask lasting av videosekvenser og eliminerer fullstendig problemet med akkumulert forsinkelse etter hvert som seertiden øker.
Etter å ha implementert WebRTC-støtte i Ivideon-skytjenesten, kan vi med full sikkerhet si at kundene våre nå kan se fullverdig livevideo. Nå overstiger ikke forsinkelsen i kringkastingen av videosekvensen ett sekund! Til sammenligning ga den forrige HLS-motoren videolevering med en forsinkelse på 5–7 sekunder. Forskjellen i hastigheten på videodemonstrasjonen er svært betydelig, og brukeren vil merke det umiddelbart etter at de har begynt å bruke videotjenesten vår.
Som vi forventet, har implementeringen av den nye spilleren forbedret responsen til PTZ og talekommunikasjon med kameraet.
Det er bare ett lite poeng vi vil gjøre deg oppmerksom på. Den nye WebRTC-spilleren er for øyeblikket i testmodus. Det er derfor vi ikke kobler den til alle klientene våre som standard. Men du kan aktivere den selv ved å aktivere det tilsvarende elementet i kamerainnstillingene (for å gjøre dette, gå til ).
Funksjoner ved WebRTC-implementering i Ivideon-tjenesten
WebRTC er fortsatt en eksperimentell teknologi for øyeblikket. Støtten er ennå ikke riktig implementert i alle nettlesere og brukerenheter, og heller ikke i alle kameraer.
Det er nettopp derfor vi ennå ikke har gjort WebRTC-spilleren til standard for alle brukere.
Foreløpig anbefaler vi å kun bruke WebRTC i Google Chrome-nettlesere. De nyeste versjonene av Firefox og Safari støtter også denne teknologien, men dessverre er den fortsatt ustabil.
Vi har ennå ikke implementert WebRTC-støtte for nettlesere på mobile enheter. For øyeblikket, hvis du logger inn fra en mobil enhet og aktiverer WebRTC, vil ikke denne modusen fungere. WebRTC er imidlertid tilgjengelig i våre mobilapplikasjoner for и .
Og som avslutning på historien om funksjonene til WebRTC-implementeringen i tjenesten vår, vil vi legge merke til to mer subtile punkter.
For det første er teknologien fokusert på å kringkaste livevideo i sanntid. Derfor, hvis kanalbåndbredden din ikke er nok til å overføre videosekvensen, vil du legge merke til tapte bilder (med HLS vil du legge merke til at videoen fryser og økt latens, men bilder vil ikke bli tapt), men videoen vil fortsatt bli sendt i sanntid.
For det andre, siden teknologien er utviklet for å fungere spesifikt med livevideo i sanntid, bruker vi den ikke til å jobbe med arkiverte videodata.
Andre endringer i tjenesten
Flash er for øyeblikket ikke lenger en del av den automatiske motorvalgmekanismen. Du kan fortsatt bruke en slik spiller, men du må velge den manuelt i kontoen eller kamerainnstillingene dine. Dette er ikke en hyllest til mote, men ifølge statistikken til tjenesten vår er det praktisk talt ingen brukere igjen som jobber med Flash. Og når vi prøver å finne ut om brukerens nettleser støtter det, mister vi omtrent 2 sekunder dyrebar tid.
Her er en kort oversikt over endringene som venter deg i vårt skybaserte videoovervåkingssystem og din personlige konto. Følg med oss og følg nyhetene!
Kilde: www.habr.com
