WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām

Jau no pirmajām dienām, strādājot pie mākoņa videonovērošanas sistēmas, mēs saskārāmies ar problēmu, bez kuras risinājuma varējām atteikties no Ivideon - tas bija mūsu Everests, kāpšana paņēma daudz enerģijas, bet tagad beidzot esam iestrēdzis ledus cirvi starpplatformu mīklas augšdaļā.

Sistēma audio un video pārraidīšanai internetā nedrīkst būt atkarīga no aprīkojuma, tīmekļa klientiem un to atbalstītajiem standartiem, kā arī pareizi darboties tīkla adrešu tulkotāju un ugunsmūru klātbūtnē. Mākoņvideonovērošanas lietotājs vēlas piekļūt pakalpojumam, pat ja viņš izmanto analogās kameras, un dod priekšroku video tiešraidei skatīties vismodernākajā ierīcē.

Ir ļoti svarīgi, ka lietotājs vēlas skatīties videoklipus ar minimālu aizkavi. Gandrīz vienīgais veids, kā pārlūkprogrammā parādīt video ar zemu latentumu, ir izmantot WebRTC (tīmekļa reāllaika saziņas). WebRTC ir tehnoloģiju kopums video un audio vienādranga pārraidei pārlūkprogrammās, sākotnēji paredzēts video straumju pārraidei un atskaņošanai ar zemu latentumu. Šim nolūkam, cita starpā, tiek izmantots UDP protokols.

Pirms pastāstīsim, ko jaunais dzinējs sniedz lietotājam, atgādināsim, kāpēc un kāpēc mēs atbalstām HLS tehnoloģijas un kāpēc nolēmām turpināt.

HLS dzinējs: plusi un mīnusi

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām
(c)

HLS (HTTP tiešraides straumēšanas) tehnoloģiju izstrādāja Apple, tāpēc nav pārsteigums, ka tā sākotnēji tika atbalstīta Apple ierīcēs. Mūsdienās HLS video atbalsta arī praktiski visi televizora pierīces un daudzas ierīces, kurās darbojas šī operētājsistēma. Android.

HLS dzinējs izmanto labi zināmo H264 video kodeku kopā ar AAC vai MP3 audio straumēm, lai straumētu video datus. Visa audio un video datu straume ir iesaiņota MPEG-TS transporta konteinerā. Pārsūtīšanai, izmantojot HTTP protokolu, straumē esošā informācija tiek sadalīta fragmentos, kas aprakstīti m3u8 atskaņošanas sarakstos. Un tikai tad šie fragmenti kopā ar atskaņošanas sarakstiem tiek pārsūtīti caur HTTP. Sadalīšana automātiski nozīmē aizkavēšanos sekundēs. Šī ir MPEG-TS konteinera funkcija.

HLS dzinējs atbalsta arī vairāku bitu pārraides straumes, tiešraides/VOD.

Galvenās HLS priekšrocības:

  • iebūvēts atbalsts visās lielākajās pārlūkprogrammās;
  • ieviešanas vienkāršība (salīdzinājumā ar WebRTC);
  • Ir ļoti ērti un efektīvi organizēt visa veida pārraides lielai auditorijai, jo segmentus var augšupielādēt CDN vienu reizi.

Neskatoties uz dzinēja vienkāršību, ne viss ir tik gluds, kā šķiet. Galvenā problēma ir tā, ka trešo pušu atskaņotāju izstrādātāji ir attālinājušies no Apple ieteikumiem, piemēram, attiecībā uz atbalstītajiem audio formātiem. Jo īpaši daudzi izstrādātāji sāka pievienot iespēju strādāt ar populārām audio straumēm: mpeg2 video, mpeg2 audio utt. Tā rezultātā viņiem bija jāizveido dažādi atskaņošanas sarakstu formāti dažādiem atskaņotājiem.

Taču viena no lielākajām HLS dzinēja problēmām ir lielais datu pārsūtīšanas latentums.

"Bremžu" izcelsme

Galvenais iemesls augstajam HLS latentumam ir tas, ka programmētāji izveidoja dzinēju, lai iegūtu augstākās kvalitātes attēlus. Tāpēc izmantotā kadru intervāla parametri un atskaņošanas bufera lielums vienkārši nav piemēroti video tiešraidēm. Šī iemesla dēļ videomateriāla pārraidē ir diezgan liela aizkave, kas var būt 5–7 sekundes.

No vienas puses, tas nav daudz, piemēram, tiem, kas skatās filmu no video hostinga servera. Taču videonovērošanas sistēmām aizkavēšanās videomateriāla pārraidē var būt ļoti svarīga.

Ja skatāties uz biroju, kurā darbinieki reizi stundā paceļ acis no monitora, tad 5 sekunžu aizkavei nav nekādas nozīmes. Bet cilvēki sāka sūdzēties, ka, piemēram, pārraidot futbola spēli, viņi jau čatā ierakstīja GOOOOL, bet tas vēl nav video :). Mums jau ir vairāki lietotāju gadījumi, kad Ivideon praktiski vajadzētu aizstāt Skype.

Vai ir iespējams pārspēt latentumu HLS? Atbilde uz šo jautājumu izklausās pēc pieredzējuša žurku iznīcinātāja runas lekcijā iesācējiem kaitēkļu apkarošanas speciālistiem: "Žurkas nevar iznīcināt, bet to skaitu var samazināt līdz saprātīgam minimumam." Tas pats ar kavēšanos HLS, to nebūs iespējams samazināt līdz nullei, taču tirgū ir risinājumi, kas var ievērojami samazināt kavēšanos.

Smalki griezumi

Vēl viens dzinēja trūkums ir mazu failu izmantošana datu pārsūtīšanai. Šķiet, kas ar to slikts?

Ikviens, kurš ir mēģinājis pārkopēt lielu skaitu mazu failu no viena datu nesēja uz citu, droši vien ir pamanījis, ka šāda komplekta rakstīšanas ātrums ir daudz mazāks nekā vienam lielam tāda paša izmēra failam. Un piekļuves intensitāte cietajam diskam ievērojami palielinās, kas kopumā negatīvi ietekmē visa datora veiktspēju. Tāpēc video datu pārsūtīšana nelielās 10 sekunžu daļās arī palielina dzinēja latentumu.

Īsi apkoposim visus HLS tehnoloģijas plusus un mīnusus.

HLS priekšrocības:

  1. Spēja strādāt ar jebkādām ierīcēm. Varat skatīties videoklipus jebkurā modernā ierīcē, neatkarīgi no tā, vai tas ir viedtālrunis, planšetdators, klēpjdators vai galddators. Galvenais, lai tīmekļa pārlūkprogramma būtu atjaunināta un saderīga ar HTML5 un Media Source Extensions.
  2. Izcila attēla kvalitāte. Izmantotā adaptīvā datu pārraides funkcija ļauj dinamiski mainīt pārraidītā video kvalitāti atkarībā no interneta savienojuma joslas platuma, savukārt algoritms cenšas saglabāt maksimālu kvalitāti.
  3. Nav nepieciešama sarežģīta lietotāja aprīkojuma konfigurācija.

Trūkumi:

  1. Ierobežots atbalsts darbam ar dzinēju dažās ierīcēs.
  2. Liela aizkave attēla pārraidē.
  3. Ievērojams pieskaitāmo izmaksu pieaugums un optimizācijas sarežģītība mazu failu izmantošanas dēļ. Konteinera rakstura dēļ mēs nekad nevarēsim iegūt latentumu, kas ir mazāks par segmenta lielumu.

HLS trūkumi mums atsvēra tās priekšrocības un piespieda mūs meklēt alternatīvas iespējas.

Kas ir WebRTC

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām
(c)

WebRTC platformu Google izstrādāja 2011. gadā, lai ar minimālu latentumu pārraidītu straumētus video un audio datus starp pārlūkprogrammām un mobilajām lietojumprogrammām. Šim nolūkam tiek izmantots standarta UDP protokols un īpaši plūsmas kontroles algoritmi. Šodien tas ir atvērtā koda projekts, to aktīvi uztur Google un tas tiek izstrādāts.

WebRTC ir tehnoloģiju kopums vienādranga video un audio pārraidei. Tas ir, piemēram, lietotāju pārlūkprogrammas, kas izmanto WebRTC, var tieši pārsūtīt datus viena otrai, neizmantojot attālos serverus datu glabāšanai un apstrādei. Visu informāciju apstrādā arī galalietotāju pārlūkprogrammas un mobilās aplikācijas.

Šīs tehnoloģijas ērtības un plašās iespējas ir novērtējuši visu populāro pārlūkprogrammu izstrādātāji. WebRTC atbalsts pašlaik ir pieejams Mozilla Firefox, Opera, Google Chrome (un visās Chromium bāzes pārlūkprogrammās), kā arī mobilajās lietotnēs, kas darbojas ar Android un iOS.

Neskatoties uz visām neapšaubāmajām priekšrocībām, WebRTC ir vairāki būtiski trūkumi.

Izvēles grūtības

WebRTC tehnoloģija ir daudz sarežģītāka tīkla mijiedarbības ziņā, jo runa ir par P2P. To ir grūti atkļūdot, pārbaudīt, un tas var darboties neparedzami. Tajā pašā laikā mums ir jāpārvar NAT un ugunsmūris, jānodrošina darbība tīklos, kur ir bloķēts UDP.

Google WebRTC ieviešanu ir ļoti grūti izmantot. Ir pat viss uzņēmums, kas sniedz SDK montāžas pakalpojumus. Turklāt Google ieviešanu bija ļoti grūti integrēt mūsu sistēmā bez visa videoklipa atkārtotas kodēšanas.

Tomēr mēs jau sen esam vēlējušies sniegt lietotājiem iespēju strādāt ar pilnvērtīgu “tiešraides” video un samazināt nobīdi starp attēlu ekrānā un pašiem notikumiem. Turklāt mums bija vēlme padarīt ērtāku PTZ kameru izmantošanu, kur kavēšanās ir kritiska.

Ņemot vērā, ka citām anti-lag implementācijām joprojām ir ierobežota funkcionalitāte un tās darbojas ievērojami sliktāk, mēs nolēmām izmantot WebRTC.

Ko mēs esam izdarījuši

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām

Pareiza WebRTC platformas ieviešana nav viegls uzdevums. Jebkurš kļūdains aprēķins vai neprecizitāte var novest pie tā, ka video pārraides aizkavēšanās ne tikai nesamazinās salīdzinājumā ar citām platformām, bet pat palielinās.

Lai WebRTC darbotos pareizi, pirmkārt, ir jāveic steka tehnoloģiskā jaunināšana darbam ar tīmekļa video. Tā mēs arī izdarījām.

Pirmkārt, mēs ieviesām WebRTC signalizācijas protokola serveri, izmantojot Websocket, kā arī izvietojām WebRTC vienādranga serveri mākonī, pamatojoties uz webrtc.org SDK. Tās uzdevums ir izplatīt video straumes klienta WebRTC vienaudžiem H.264 + Opus/G.711 formātā bez video pārkodēšanas.

Mēs izvēlējāmies Websocket kā signalizācijas protokolu, jo tam jau ir augstas kvalitātes atbalsts visās populārajās tīmekļa pārlūkprogrammās. Pateicoties tam, jūs varat ievērojami samazināt ne tikai izstrādes izmaksas, bet arī izvairīties no laika un resursu tērēšanas atkārtotam TCP un TLS rokasspiedienam salīdzinājumā ar AJAX.

Fakts ir tāds, ka pēc noklusējuma WebRTC nenodrošina signalizācijas protokolu, kas nepieciešams, lai pareizi konfigurētu, uzturētu un pārtrauktu reāllaika video saziņu starp avota un klienta lietojumprogrammām.

Un, lai neatkarīgi ieviestu signalizācijas tehnoloģiju, mums bija jāizstrādā savs signalizācijas serveris ar atbalstu vairākiem tīmekļa protokoliem (Websocet, WebRTC). Un ar iespēju droši pārvaldīt sesijas un paziņojumus reāllaikā, video pārvaldību un daudz ko citu.

Mēs pārvarējām P2P ierobežojumus, samazinot latentumu nevis izmantojot P2P, bet gan UDP un plūsmas kontroli, lai samazinātu latentumu. Tas ir arī iebūvēts WebRTC, jo galvenais lietošanas gadījums ir p2p sarunas, izmantojot pārlūkprogrammu.

Mobilajā klientā mēs ieviesām atskaņotāju, izmantojot webrtc.org SDK, jo tikai tas pareizi īsteno plūsmas kontroli, tam ir visas zināmās pārsūtīšanas kļūdu labošanas (FEC) shēmas un pareizi tiek ieviests pakešu atkārtotas nosūtīšanas mehānisms visām pārlūkprogrammām. Svarīgi ir arī tas, ka webrtc.org SDK aktīvi izstrādā Google.

Kāds ir WebRTC ieviešanas rezultāts?


Lai skatītu tiešraides video no kamerām, jūsu personīgajam kontam esam pievienojuši jaunu optimizētu atskaņotāju, kura pamatā ir WebRTC. Tas nodrošina ātru video ielādes ātrumu un pilnībā novērš latentuma uzkrāšanos, palielinoties skatīšanās laikam.

Pēc WebRTC atbalsta ieviešanas Ivideon mākoņpakalpojumā mēs varam ar pilnīgu pārliecību teikt, ka mūsu klienti tagad var skatīties pilnvērtīgu tiešraides video. Tagad video secību pārraidīšanas aizkave nepārsniedz vienu sekundi! Salīdzinājumam iepriekšējais HLS dzinējs nodrošināja video piegādi ar 5-7 sekunžu aizkavi. Video demonstrēšanas ātruma atšķirība ir ļoti būtiska, un lietotājs to pamanīs uzreiz pēc darba uzsākšanas ar mūsu video servisu.

Kā jau gaidījām, jaunā atskaņotāja ieviešana ir uzlabojusi PTZ un balss sakaru ar kameru atsaucību.

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām

Ir tikai viens smalks punkts, kam mēs vēlamies pievērst uzmanību. Jaunais WebRTC atskaņotājs šobrīd strādā testa režīmā. Un tāpēc mēs to neiespējojam visiem mūsu klientiem pēc noklusējuma. Bet jūs varat to aktivizēt pats, kameras iestatījumos iespējojot atbilstošo vienumu (lai to izdarītu, dodieties uz kabinets).

WebRTC ieviešanas iezīmes pakalpojumā Ivideon

WebRTC un videonovērošana: kā mēs uzvarējām video latentumu no kamerām

WebRTC šobrīd joprojām ir eksperimentāla tehnoloģija. Tā atbalsts vēl nav pareizi ieviests visās pārlūkprogrammās un lietotāju ierīcēs, kā arī ne visās kamerās.

Tieši tāpēc mēs vēl neesam padarījuši WebRTC atskaņotāju par noklusējuma atskaņotāju visiem lietotājiem.

Pagaidām WebRTC iesakām izmantot tikai Google Chrome pārlūkprogrammās. Arī jaunākās Firefox un Safari versijas atbalsta šo tehnoloģiju, taču diemžēl tā joprojām ir nestabila.

Mēs vēl neesam ieviesuši WebRTC atbalstu mobilo ierīču pārlūkprogrammām. Pašlaik, ja piesakāties no mobilās ierīces un aktivizējat WebRTC, šis režīms nedarbosies. Tomēr WebRTC ir pieejams mūsu mobilajās lietojumprogrammās Android и iOS.

Un, noslēdzot stāstu par WebRTC ieviešanas iezīmēm mūsu pakalpojumā, atzīmēsim vēl divus smalkus punktus.

Pirmkārt, tehnoloģija ir vērsta uz video tiešraidi reāllaikā. Tāpēc, ja jūsu kanālam nav pietiekami daudz joslas platuma, lai pārraidītu video, jūs pamanīsit kadru kritumu (ar HLS jūs pamanīsit video izbalēšanu un palielinātu latentumu, bet nebūs kadru krituma), taču video joprojām tiks pārraidīts reālā režīmā. laiks.

Otrkārt, tā kā tehnoloģija ir izstrādāta īpaši darbam ar tiešraides video reāllaikā, mēs to neizmantojam darbam ar arhivētiem video datiem.

Citas izmaiņas pakalpojumā

Šobrīd Flash vairs nav iesaistīts automātiskā dzinēja izvēles mehānismā. Jūs joprojām varat izmantot šādu atskaņotāju, taču, lai to izdarītu, tas ir jāatlasa manuāli konta vai kameras iestatījumos. Tas nav veltījums modei, vienkārši saskaņā ar mūsu pakalpojuma statistiku praktiski vairs nav neviena lietotāja, kas strādātu ar Flash. Un, mēģinot noteikt, vai lietotāja pārlūkprogramma to atbalsta, mēs zaudējam apmēram 2 sekundes dārgā laika.

Šeit ir īss pārskats par izmaiņām, kas jūs gaida mūsu mākoņa videonovērošanas sistēmā un personīgajā kontā. Palieciet kopā ar mums un sekojiet jaunumiem!

Avots: www.habr.com

Iegādājieties uzticamu mitināšanu vietnēm ar DDoS aizsardzību, VPS VDS serveriem 🔥 Iegādājieties uzticamu tīmekļa vietņu mitināšanu ar DDoS aizsardzību, VPS VDS serveriem | ProHoster