Vanaf die eerste dae wat ons aan 'n wolk-videobewakingstelsel gewerk het, het ons 'n probleem in die gesig gestaar, sonder om dit op te los wat dit moontlik was om 'n einde aan Ivideon te maak - dit was ons Everest, klim wat baie krag geverg het, maar nou het ons uiteindelik vasgesteek 'n ysbyl in die bokant van die kruisplatform-rebus.
Die stelsel vir die oordrag van oudio en video oor die internet behoort nie afhanklik te wees van die toerusting, webkliënte en die standaarde wat hulle ondersteun nie, en werk ook korrek in die teenwoordigheid van netwerkadresvertalers en brandmure. ’n Wolkvideo-toesiggebruiker wil toegang tot die diens hê, selfs al gebruik hy analoogkameras, en verkies om regstreekse video-uitsending op die modernste toestel te kyk.
Dit is baie belangrik dat die gebruiker video met minimale vertraging wil kyk. Byna die enigste manier om video met 'n lae latensie in 'n blaaier te wys, is om WebRTC (intydse webkommunikasie) te gebruik. WebRTC is 'n stel tegnologieë vir eweknie-oordrag van video en oudio in blaaiers, oorspronklik ontwerp vir die oordrag en terugspeel van 'n videostroom met 'n lae latensie. Hiervoor word onder meer die UDP-protokol gebruik.
Voordat ons jou vertel wat die nuwe enjin die gebruiker gee, sal ons jou herinner hoekom en hoekom ons HLS-tegnologie ondersteun, en hoekom ons besluit het om aan te gaan.
HLS-enjin: voor- en nadele
()
HLS (HTTP Live Streaming) tegnologie is deur Apple ontwikkel, so dit is geen verrassing dat dit aanvanklik op Apple-toestelle ondersteun is nie. Vandag word HLS-video ook deur feitlik alle dekodeerders en baie toestelle wat die bedryfstelsel gebruik, ondersteun. Android.
Die HLS-enjin gebruik die bekende H264-videokodek in kombinasie met AAC- of MP3-oudiostrome om videodata te stroom. Die hele stroom van oudio- en videodata word in 'n MPEG-TS-vervoerhouer verpak. Vir oordrag oor die HTTP-protokol, word die inligting wat in die stroom vervat is, verdeel in fragmente wat in m3u8-snitlyste beskryf word. En eers dan word hierdie fragmente, saam met snitlyste, via HTTP oorgedra. Verdeling in fragmente beteken outomaties 'n vertraging in sekondes. So 'n kenmerk van die MPEG-TS-houer.
Die HLS-enjin ondersteun ook multibitrate-strome, Live/VOD.
Die belangrikste voordele van HLS:
- ingeboude ondersteuning in alle groot blaaiers;
- gemak van implementering (in vergelyking met WebRTC);
- dit is baie gerieflik en doeltreffend om allerhande uitsendings vir 'n groot gehoor te organiseer as gevolg van die feit dat segmente een keer na 'n CDN opgelaai kan word.
Ten spyte van die eenvoud van die enjin is alles nie so glad soos dit lyk nie. Die grootste probleem is dat die ontwikkelaars van derdeparty-spelers van Apple se aanbevelings afgewyk het, byvoorbeeld in terme van ondersteunde oudioformate. In die besonder het baie ontwikkelaars die vermoë begin byvoeg om met gewilde klankstrome te werk: mpeg2-video, mpeg2-klank, ens. As gevolg hiervan moes ons verskillende snitlysformate vir verskillende spelers skep.
Maar een van die grootste probleme met die HLS-enjin is die hoë latensie in data-oordrag.
Die oorsprong van die "remme"
Die hoofrede vir die hoë latensie van HLS lê in die feit dat die programmeerders die enjin geskep het om die hoogste kwaliteit prentjie te kry. Daarom is die parameters van die raaminterval wat gebruik word en die grootte van die terugspeelbuffer eenvoudig nie geskik vir regstreekse video-uitsendings nie. As gevolg hiervan is daar 'n taamlike hoë vertraging in die oordrag van die videoreeks, wat 5-7 sekondes kan wees.
Aan die een kant is dit nie veel nie, byvoorbeeld vir diegene wat 'n fliek vanaf 'n video-gasheerbediener kyk. Maar vir video-toesigstelsels kan die vertraging in die oordrag van die videoreeks baie belangrik wees.
As jy 'n kantoor dophou waar werknemers een keer per uur hul oë van die monitors afhaal, maak 'n vertraging van 5 sekondes nie saak nie. Maar mense het begin kla dat hulle byvoorbeeld tydens die uitsending van 'n sokkerwedstryd reeds GOOOOL in die chat geskryf het, maar dit is nog nie op die video nie :). Ons het reeds 'n aantal gebruikersgevalle waar Ivideon prakties skype moet vervang.
Is dit moontlik om latency in HLS te klop? Die antwoord op hierdie vraag klink soos 'n toespraak deur 'n ervare rotverdelger by 'n lesing aan beginner-uitroeiers: "Rotte kan nie uitgeroei word nie, maar hul bevolking kan tot 'n redelike minimum verminder word." So met die vertraging in HLS sal dit nie werk om dit na nul te verwyder nie, maar daar is oplossings op die mark wat die vertraging aansienlik kan verminder.
Fyn sny
Nog 'n nadeel van die enjin is die gebruik van klein lêers vir data-oordrag. Dit wil voorkom asof dit sleg is?
Enigiemand wat probeer het om 'n groot aantal klein lêers van een medium na 'n ander te kopieer, moes opgemerk het dat die skryfspoed van so 'n stel baie laer is as een groot lêer van dieselfde grootte. Ja, en die intensiteit van toegang tot die hardeskyf neem aansienlik toe, wat oor die algemeen die werkverrigting van die hele rekenaar negatief beïnvloed. Daarom dra die oordrag van videodata in die vorm van klein 10 sekondes fragmente ook by tot die verhoogde vertraging van die enjin.
Kom ons som al die voor- en nadele van HLS-tegnologie kortliks op.
Voordele van HLS:
- Vermoë om met enige toestel te werk. Jy kan video's op enige moderne toestel kyk, of dit nou 'n slimfoon, tablet, skootrekenaar of rekenaar is. Die belangrikste ding is dat die webblaaier op datum is en versoenbaar is met HTML5 en Media Source Extensions.
- Uitstekende beeldkwaliteit. Die aanpasbare data-oordragfunksie wat gebruik word, laat jou toe om die kwaliteit van die uitgestuurde videovolgorde dinamies te verander na gelang van die bandwydte van die internetverbinding, terwyl die algoritme daarna streef om die kwaliteit so hoog as moontlik te hou.
- Daar is geen behoefte aan komplekse gebruikerstoerustingopstelling nie.
Nadele:
- Beperkte ondersteuning vir die werk met die enjin op sommige toestelle.
- Hoë latensie in beeldoordrag.
- Sterk toename in bokoste en kompleksiteit van optimalisering as gevolg van die gebruik van klein lêers. Weens die aard van die houer kan ons nooit 'n vertraging minder as die segmentgrootte kry nie.
Die nadele van HLS het die voordele vir ons oortref en ons gedwing om na alternatiewe te soek.
Wat is WebRTC
()
Die WebRTC-platform is in 2011 deur Google ontwikkel om stromende video- en oudiodata met minimale vertraging tussen blaaiers en mobiele toepassings oor te dra. Hiervoor word die standaard UDP-protokol en spesiale vloeibeheeralgoritmes gebruik. Vandag is dit 'n oopbronprojek, aktief ondersteun deur Google en ontwikkel.
WebRTC is 'n stel tegnologieë vir eweknie-video- en oudio-oordrag. Dit wil sê dat gebruikers se blaaiers wat WebRTC gebruik, data direk na mekaar kan oordra, sonder om afgeleë bedieners te gebruik vir die stoor en verwerking van data. Alle inligting word ook deur eindgebruikers se blaaiers en mobiele toepassings verwerk.
Die gerief en uitgebreide vermoëns van hierdie tegnologie is waardeer deur ontwikkelaars van alle gewilde blaaiers. WebRTC-ondersteuning is tans beskikbaar in Mozilla Firefox, Opera, Google Chrome (en alle Chromium-gebaseerde blaaiers), sowel as in mobiele toepassings wat ... Android en iOS.
Met al sy onmiskenbare voordele, het WebRTC verskeie beduidende nadele.
Moeilikhede van keuse
WebRTC-tegnologie is baie meer kompleks in terme van netwerkinteraksies as gevolg van die feit dat dit oor P2P gaan. Dit is moeilik om te ontfout, te toets, dit kan onvoorspelbaar optree. Terselfdertyd moet ons NAT en firewall oorkom, ons moet verseker werk in netwerke waar UDP geblokkeer is.
Google se WebRTC-implementering is baie moeilik om te gebruik. Daar is selfs 'n hele maatskappy wat SDK-boudienste verskaf. Boonop was Google se implementering baie moeilik om met ons stelsel te integreer sonder om die hele video te herkodeer.
Ons wil egter lankal vir gebruikers die geleentheid gee om met 'n volwaardige "regstreekse" videoreeks te werk en die vertraging van die beeld op die skerm van die gebeure self te minimaliseer. Boonop het ons 'n begeerte gehad om die gebruik van PTZ-kameras gemakliker te maak, waar vertragings kritiek is.
Aangesien ander anti-lag-implementerings steeds beperkte funksionaliteit het en merkbaar slegter werk, het ons besluit om WebRTC te gebruik.
Wat het ons gedoen
Om die WebRTC-platform behoorlik te implementeer is nie 'n maklike taak nie. Enige verkeerde berekening of onakkuraatheid kan daartoe lei dat die vertragings in die oordrag van die videoreeks nie net nie sal afneem in vergelyking met ander platforms nie, maar selfs sal toeneem.
Vir WebRTC om korrek te werk, is dit eerstens nodig om 'n tegnologiese opgradering van die stapel uit te voer om met webvideo te werk. Dit is wat ons gedoen het.
Eerstens het ons 'n WebRTC-seinprotokolbediener oor Websocket geïmplementeer, en ook 'n WebRTC-ewekniebediener in die wolk ontplooi gebaseer op die webrtc.org SDK. Sy taak is om videostrome te versprei na kliënt WebRTC eweknieë in H.264 + Opus/G.711 formaat sonder video transkodering.
Ons het Websocket as die seinprotokol gekies omdat dit reeds goeie ondersteuning in alle gewilde webblaaiers het. As gevolg hiervan kan u nie net ontwikkelingsbokoste aansienlik verminder nie, maar ook nie tyd en hulpbronne mors op herhaalde TCP- en TLS-handdruk in vergelyking met AJAX nie.
Die punt is dat WebRTC by verstek nie die seinprotokol verskaf wat nodig is om intydse videokommunikasie tussen bron- en kliënttoepassings behoorlik op te stel, in stand te hou en te beëindig nie.
En om die seintegnologie onafhanklik te implementeer, moes ons ons eie seinbediener ontwikkel met ondersteuning vir verskeie webprotokolle (Websocet, WebRTC). En met die vermoë om sessies en intydse kennisgewings veilig te bestuur, video te bestuur en meer.
Ons het die beperkings van P2P oorkom deur latency nie deur P2P te verminder nie, maar deur UDP en vloeibeheer om latensie te verminder. Dit is ook in WebRTC ingebou, aangesien die hoofgebruiksgeval p2p-gesprekke deur die blaaier is.
In die mobiele kliënt het ons die speler geïmplementeer deur die webrtc.org SDK te gebruik, aangesien dit die enigste een is wat vloeibeheer korrek implementeer, alle bekende Forward Error Correction (FEC) skemas het, en die meganisme vir die herstuur van pakkies vir alle blaaiers korrek implementeer . Dit is ook belangrik dat die webrtc.org SDK aktief deur Google ontwikkel word.
Wat is die resultaat van die implementering van WebRTC?
Om regstreekse video vanaf kameras te sien, het ons 'n nuwe geoptimaliseerde speler gebaseer op WebRTC by jou persoonlike rekening gevoeg. Dit bied hoëspoed video-laai en skakel die probleem van latensie-akkumulasie heeltemal uit namate die kyktyd toeneem.
Nadat ons WebRTC-ondersteuning in die Ivideon-wolkdiens geïmplementeer het, kan ons met volle vertroue sê dat ons kliënte nou volwaardige regstreekse video kan kyk. Nou is die vertraging in die uitsaai van die video-reeks nie meer as een sekonde nie! Ter vergelyking het die vorige HLS-enjin video-aflewering met 'n vertraging van 5-7 sekondes verskaf. Die verskil in die spoed van video-demonstrasie is baie betekenisvol, en die gebruiker sal dit dadelik agterkom nadat hy met ons videodiens begin werk het.
Soos ons verwag het, het die implementering van die nuwe speler dit moontlik gemaak om die responsiwiteit van PTZ en stemkommunikasie met die kamera te verhoog.
Daar is net een subtiele punt waarop ons die aandag wil vestig. Die nuwe WebRTC-speler werk steeds in toetsmodus. En dit is hoekom ons dit nie by verstek vir al ons kliënte aktiveer nie. Maar jy kan dit self aktiveer deur die ooreenstemmende item in die kamera-instellings te aktiveer (om dit te doen, gaan na ).
Kenmerke van die implementering van WebRTC in die Ivideon-diens
WebRTC is tans nog 'n eksperimentele tegnologie. Die ondersteuning daarvan is nog nie korrek in alle blaaiers en gebruikerstoestelle geïmplementeer nie, en nie in alle kameras nie.
Dit is presies wat die feit verklaar dat ons nog nie die WebRTC-speler die hoof verstek vir alle gebruikers gemaak het nie.
Vir eers beveel ons aan om WebRTC slegs in Google Chrome-blaaiers te gebruik. Die nuutste weergawes van Firefox en Safari ondersteun ook hierdie tegnologie, maar dit is ongelukkig nog nie stabiel nie.
Ons het nog nie WebRTC-ondersteuning vir blaaiers op mobiele toestelle geïmplementeer nie. As jy nou vanaf 'n mobiele toestel aanmeld en WebRTC aktiveer, sal hierdie modus nie werk nie. WebRTC is egter beskikbaar in ons mobiele toepassings vir и .
En as ons die storie oor die kenmerke van die implementering van WebRTC in ons diens voltooi, let ons op nog twee subtiele punte.
Eerstens is die tegnologie daarop gefokus om regstreekse video in reële tyd uit te saai. As jou bandwydte dus nie genoeg is om die video-volgorde oor te dra nie, sal jy raamdalings opmerk (met HLS sal jy video vervaag en 'n toename in latensie opmerk, terwyl geen rame laat val word nie), maar die video sal steeds in werklikheid uitgesaai word tyd.
Tweedens, aangesien die tegnologie ontwerp is om intyds met lewendige video te werk, gebruik ons dit nie om met argiefvideodata te werk nie.
Ander diensveranderinge
Op die oomblik neem Flash nie meer deel aan die outomatiese enjinkeusemeganisme nie. Jy kan steeds so 'n speler gebruik, maar hiervoor moet jy dit handmatig in die rekening- of kamera-instellings kies. Dit is nie 'n huldeblyk aan mode nie, net volgens die statistieke van ons diens is daar feitlik geen gebruikers wat met Flash werk nie. En om te probeer vasstel of die gebruiker se blaaier dit ondersteun, verloor ons ongeveer 2 sekondes se kosbare tyd.
Hier is 'n kort opsomming van die veranderinge wat op jou wag in ons wolk-gebaseerde video-toesigstelsel en persoonlike rekening. Bly by ons en volg die nuus!
Bron: will.com
