ProHoster > Blogs > Administrācija > No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

Video komunikācija ir galvenais saziņas veids starp skolotāju un skolēnu Vimbox platformā. Mēs jau sen atteicāmies no Skype, izmēģinājām vairākus treÅ”o puÅ”u risinājumus un galu galā izvēlējāmies WebRTC - Janus-gateway kombināciju. Kādu laiku bijām ar visu apmierināti, bet tomēr turpināja iezÄ«mēties daži negatÄ«vie aspekti. Rezultātā tika izveidots atseviŔķs video virziens.

Es lÅ«dzu Kirilu Rogovoju, jaunā virziena vadÄ«tāju, pastāstÄ«t par video komunikācijas attÄ«stÄ«bu Skyeng, atklātajām problēmām, risinājumiem un kruÄ·iem, ko mēs galu galā izmantojām. Mēs ceram, ka raksts bÅ«s noderÄ«gs uzņēmumiem, kas arÄ« paÅ”i veido video, izmantojot tÄ«mekļa lietojumprogrammu.

Nedaudz vēstures

2017. gada vasarā Skyeng attÄ«stÄ«bas vadÄ«tājs Sergejs Safonovs uzstājās Backend Conf ar stāstu par to, kā mēs ā€œatteicāmies no Skype un ieviesām WebRTCā€. Interesenti runas ierakstu var noskatÄ«ties plkst saite (~45 min), un Å”eit es Ä«si ieskicēju tā bÅ«tÄ«bu.

Skyeng skolai video komunikācija vienmēr ir bijusi prioritārs skolotāju un studentu saziņas veids. Sākumā tika izmantots Skype, taču tas kategoriski nebija apmierinoÅ”s vairāku iemeslu dēļ, galvenokārt tāpēc, ka trÅ«ka žurnālu un nebija iespējams tieÅ”i integrēt tÄ«mekļa lietojumprogrammā. Tāpēc mēs veicām visdažādākos eksperimentus.

Faktiski mÅ«su prasÄ«bas video saziņai bija aptuveni Ŕādas:
ā€” stabilitāte;
ā€” zema cena par nodarbÄ«bu;
ā€” nodarbÄ«bu ierakstÄ«Å”ana;
ā€” izsekoÅ”ana, kurÅ” cik daudz runā (mums ir svarÄ«gi, lai stundās skolēni runātu vairāk nekā skolotājs);
ā€” lineārā mērogoÅ”ana;
- spēja izmantot gan UDP, gan TCP.

Pirmais mēģinājums bija Tokbox ievieÅ”ana 2013. gadā. Viss bija labi, bet tas izrādÄ«jās ļoti dārgs - 113 rubļi par nodarbÄ«bu - un apēda peļņu.

Pēc tam 2015. gadā Voximplant tika integrēts. Å eit bija funkcija, kas mums bija nepiecieÅ”ama, lai izsekotu, kurÅ” cik runā, un tajā paŔā laikā risinājums bija daudz lētāks: ja tika ierakstÄ«ts tikai audio, tas maksāja 20 rubļus par stundu. Tomēr tas darbojās tikai caur UDP un nevarēja pārslēgties uz TCP. Tomēr aptuveni 40% studentu to izmantoja.

Gadu vēlāk mums sāka bÅ«t korporatÄ«vie klienti ar savām Ä«paŔām prasÄ«bām. Piemēram, visam vajadzētu darboties caur pārlÅ«kprogrammu, uzņēmums atver tikai http un https; t.i., nav Skype vai UDP. KorporatÄ«vie klienti = nauda, ā€‹ā€‹tāpēc viņi atgriezās Tokbox, bet cenu problēma nepazuda.

Risinājums - WebRTC un Janus

Nolēma izmantot pārlÅ«kprogrammas platforma vienādranga video saziņai WebRTC. Tas ir atbildÄ«gs par savienojuma izveidi, straumju kodÄ“Å”anu un dekodÄ“Å”anu, celiņu sinhronizÄ“Å”anu un kvalitātes kontroli ar tÄ«kla kļūmju apstrādi. No savas puses mums ir jānodroÅ”ina straumju nolasÄ«Å”ana no kameras un mikrofona, video zÄ«mÄ“Å”ana, savienojuma pārvaldÄ«ba, WebRTC savienojuma izveidoÅ”ana un straumju pārsÅ«tÄ«Å”ana uz to, kā arÄ« signalizācijas ziņojumu pārsÅ«tÄ«Å”ana starp klientiem, lai izveidotu savienojumu (Pats WebRTC apraksta tikai datu formātu, bet ne tā pārsÅ«tÄ«Å”anas mehānismu). Ja klienti ir aiz NAT, WebRTC savieno STUN serverus; ja tas nepalÄ«dz, TURN serverus.

Ar parastu p2p savienojumu mums nepietiek, jo vēlamies ierakstÄ«t nodarbÄ«bas tālākai analÄ«zei sÅ«dzÄ«bu gadÄ«jumā. Tāpēc mēs nosÅ«tām WebRTC straumes caur releju Meetecho Janus Gateway. Rezultātā klienti nezina viens otra adreses, redzot tikai Janus servera adresi; tas veic arÄ« signālu servera funkcijas. Janus ir daudzas mums nepiecieÅ”amās funkcijas: automātiski pārslēdzas uz TCP, ja klientam ir bloķēts UDP; var ierakstÄ«t gan UDP, gan TCP straumes; mērogojams; Ir pat iebÅ«vēts spraudnis atbalss testiem. Ja nepiecieÅ”ams, STUN un TURN serveri no Twilio tiek automātiski savienoti.

2017. gada vasarā mums darbojās divi Janus serveri, kā arÄ« papildus serveris ierakstÄ«to neapstrādāto audio un video failu apstrādei, lai nenoslogotu galveno procesorus. Pieslēdzoties, Janus serveri tika atlasÄ«ti pēc nepāra un pāra principa (savienojuma numurs). Toreiz ar to pietika, pēc mÅ«su izjÅ«tām tas deva aptuveni četrkārtÄ«gu droŔības rezervi, realizācijas procents bija ap 80. Tajā paŔā laikā cena tika samazināta lÄ«dz ~2 rubļiem par stundu, plus attÄ«stÄ«ba un atbalsts.

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

Atgriežoties pie video komunikācijas tēmas

Mēs pastāvÄ«gi uzraugām studentu un skolotāju atsauksmes, lai savlaicÄ«gi identificētu un labotu problēmas. LÄ«dz 2018. gada vasarai zvanu kvalitāte bija pārliecinoÅ”i pirmajā vietā starp sÅ«dzÄ«bām. No vienas puses, tas nozÄ«mēja, ka esam veiksmÄ«gi tikuÅ”i galā ar citiem trÅ«kumiem. No otras puses, vajadzēja kaut ko darÄ«t steidzami: ja nodarbÄ«ba tiek traucēta, mēs riskējam zaudēt tās vērtÄ«bu, dažreiz kopā ar nākamās paketes iegādes izmaksām, un, ja tiek traucēta ievadnodarbÄ«ba, mēs riskējam zaudēt potenciālo klientu. vispār.

TobrÄ«d mÅ«su video komunikācija vēl bija MVP režīmā. VienkārÅ”i sakot, viņi to palaida, tas strādāja, viņi vienreiz palielināja to, viņi saprata, kā to izdarÄ«t - nu, lieliski. Ja tas darbojas, nelabojiet to. Neviens apzināti nerisināja komunikācijas kvalitātes jautājumu. LÄ«dz augustam kļuva skaidrs, ka tas nevar turpināties, un mēs sākām atseviŔķu virzienu, lai noskaidrotu, kas ir nepareizi ar WebRTC un Janus.

Ievadā Å”is virziens saņēma: MVP risinājums, nav metriku, nav mērÄ·u, nav procesu uzlaboÅ”anai, savukārt 7% skolotāju sÅ«dzas par komunikācijas kvalitāti (arÄ« nebija datu par skolēniem).

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

Notiek jauns virziens

Komanda izskatās apmēram Ŕādi:

  • Nodaļas vadÄ«tājs, kurÅ” ir arÄ« galvenais izstrādātājs.
  • QA palÄ«dz pārbaudÄ«t izmaiņas, meklē jaunus veidus, kā radÄ«t nestabilus saziņas apstākļus, un ziņo par problēmām no priekŔējās lÄ«nijas.
  • AnalÄ«tiÄ·is pastāvÄ«gi meklē dažādas tehnisko datu korelācijas, uzlabo lietotāju atsauksmju analÄ«zi un pārbauda eksperimentu rezultātus.
  • Produktu vadÄ«tājs palÄ«dz ar vispārējo virzÄ«bu un resursu pieŔķirÅ”anu eksperimentiem.
  • Otrs izstrādātājs bieži palÄ«dz ar programmÄ“Å”anu un saistÄ«tiem uzdevumiem.

Sākumā mēs izveidojām salÄ«dzinoÅ”i uzticamu metriku, kas izsekoja komunikācijas kvalitātes novērtējumu izmaiņas (vidēji dienās, nedēļās, mēneÅ”os). Toreiz tās bija skolotāju atzÄ«mes, vēlāk tām pievienoja skolēnu atzÄ«mes. Pēc tam viņi sāka izvirzÄ«t hipotēzes par to, kas darbojas nepareizi, to laboja un aplÅ«koja izmaiņas dinamikā. Mēs izvēlējāmies zemu karājas augļus: piemēram, nomainÄ«jām vp8 kodeku ar vp9, veiktspēja uzlabojās. Mēģinājām spēlēties ar Janus iestatÄ«jumiem un veikt citus eksperimentus ā€“ vairumā gadÄ«jumu tie ne pie kā nenoveda.

Otrajā posmā parādÄ«jās hipotēze: WebRTC ir vienādranga risinājums, un mēs izmantojam serveri pa vidu. VarbÅ«t problēma slēpjas Å”eit? Mēs sākām rakt un atradām lÄ«dz Å”im bÅ«tiskāko uzlabojumu.

Tajā brÄ«dÄ« serveris no baseina tika izvēlēts, izmantojot diezgan muļķīgu algoritmu: katram bija savs ā€œsvarsā€, atkarÄ«bā no kanāla un jaudas, un mēs mēģinājām nosÅ«tÄ«t lietotāju uz to, kuram ir vislielākais ā€œsvarsā€, bez pievērÅ”ot uzmanÄ«bu lietotāja Ä£eogrāfiskajai atraÅ”anās vietai . Rezultātā skolotājs no Pēterburgas ar studentu no SibÄ«rijas varēja sazināties caur Maskavu, nevis caur mÅ«su Janus serveri Sanktpēterburgā.

Algoritms ir pārveidots: tagad, kad lietotājs atver mÅ«su platformu, mēs savācam no viņa ping uz visiem serveriem, kas izmanto Ajax. Veidojot savienojumu, mēs izvēlamies ping pāri (skolotājs-serveris un skolēns-serveris) ar mazāko summu. Mazāks ping nozÄ«mē mazāku tÄ«kla attālumu lÄ«dz serverim; mazāks attālums nozÄ«mē mazāku pakeÅ”u zaudÄ“Å”anas varbÅ«tÄ«bu; PakeÅ”u zudums ir lielākais negatÄ«vais faktors video komunikācijā. Negativitātes Ä«patsvars trÄ«s mēneÅ”u laikā samazinājās uz pusi (taisnÄ«bas labad jāsaka, ka Å”ajā laikā tika veikti arÄ« citi eksperimenti, taču Å”im gandrÄ«z noteikti bija vislielākā ietekme).

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

Mēs nesen atklājām vēl vienu nepārprotamu, bet Ŕķietami svarÄ«gu lietu: viena jaudÄ«ga Janus servera vietā biezā kanālā labāk ir izmantot divus vienkārŔākus ar mazāku joslas platumu. Tas kļuva skaidrs pēc tam, kad iegādājāmies jaudÄ«gas maŔīnas, cerot tajās vienlaikus sabāzt pēc iespējas vairāk telpu (saziņas sesiju). Serveriem ir joslas platuma limits, ko varam precÄ«zi pārtulkot telpu skaitā ā€“ zinām, cik var atvērt, piemēram, pie 300 Mbit/s. TiklÄ«dz serverÄ« ir atvērts pārāk daudz istabu, mēs pārtraucam to izvēlēties jaunām aktivitātēm, lÄ«dz slodze samazinās. Ideja bija tāda, ka, iegādājoties jaudÄ«gu maŔīnu, mēs maksimāli ielādējam tajā kanālu, lai galu galā to ierobežotu procesors un atmiņa, nevis joslas platums. Bet izrādÄ«jās, ka pēc noteikta skaita atvērto telpu (420), neskatoties uz to, ka procesora, atmiņas un diska slodze joprojām ir ļoti tālu no robežām, tehniskajā nodroÅ”inājumā sāk nonākt negatÄ«visms. AcÄ«mredzot Janusā kaut kas kļūst sliktāks, varbÅ«t arÄ« tur ir kādi ierobežojumi. Mēs sākām eksperimentēt, pazeminājām joslas platuma ierobežojumu no 300 lÄ«dz 200 Mbit/s, un problēmas pazuda. Tagad mēs iegādājāmies trÄ«s jaunus serverus uzreiz ar zemiem limitiem un parametriem, domājam, ka tas nodroÅ”inās stabilu komunikācijas kvalitātes uzlaboÅ”anos. Protams, mēs necentāmies saprast, kas tur notiek; mÅ«su kruÄ·i ir viss. Aizstāvot, teiksim, ka tajā brÄ«dÄ« bija nepiecieÅ”ams pēc iespējas ātrāk atrisināt aktuālo problēmu, nevis to darÄ«t skaisti; turklāt Janus mums ir melnā kaste, kas rakstÄ«ta ar C, ar to ir ļoti dārgi lāpÄ«t.

No Skype līdz WebRTC: kā mēs organizējām video saziņu tīmeklī

Nu, Å”ajā procesā mēs:

  • atjauninātas visas atkarÄ«bas, kuras varēja atjaunināt gan serverÄ«, gan klientā (tie arÄ« bija eksperimenti, uzraudzÄ«jām rezultātus);
  • novērstas visas identificētās kļūdas, kas saistÄ«tas ar konkrētiem gadÄ«jumiem, piemēram, kad savienojums pārtrÅ«ka un netika automātiski atjaunots;
  • Bijām daudz tikÅ”anās ar uzņēmumiem, kas strādā video komunikācijas jomā un iepazināmies ar mÅ«su problēmām: spēļu straumÄ“Å”ana, vebināru organizÄ“Å”ana; izmēģinājām visu, kas mums Ŕķita noderÄ«gs;
  • Veica skolotāju aparatÅ«ras un komunikācijas kvalitātes tehnisko pārbaudi, no kuriem saņemtas visvairāk sÅ«dzÄ«bu.

Eksperimenti un tam sekojoŔās izmaiņas ļāva samazināt skolotāju neapmierinātÄ«bu ar komunikāciju no 7,1% 2018. gada janvārÄ« lÄ«dz 2,5% 2019. gada janvārÄ«.

Kas ir nākamais

MÅ«su Vimbox platformas stabilizÄ“Å”ana ir viens no uzņēmuma galvenajiem projektiem 2019. gadā. Mēs ļoti ceram, ka spēsim noturēt tempu un vairs neredzēsim video komunikāciju galvenajās sÅ«dzÄ«bās. Mēs saprotam, ka bÅ«tiska daļa no Ŕīm sÅ«dzÄ«bām ir saistÄ«tas ar lietotāju datoru un interneta nobÄ«dēm, taču Ŕī daļa mums ir jānosaka un pārējā jāatrisina. Viss pārējais ir tehniska problēma, Ŕķiet, ar to mums vajadzētu tikt galā.

Galvenā grÅ«tÄ«ba ir tā, ka mēs nezinām, lÄ«dz kādam lÄ«menim patiesÄ«bā ir iespējams uzlabot kvalitāti. Å o griestu noskaidroÅ”ana ir galvenais uzdevums. Tāpēc tika plānoti divi eksperimenti:

  1. salÄ«dziniet video caur Janus ar parasto p2p kaujas apstākļos. Å is eksperiments jau ir veikts, nav konstatēta statistiski nozÄ«mÄ«ga atŔķirÄ«ba starp mÅ«su risinājumu un p2p;
  2. Piegādāsim (dārgus) pakalpojumus no uzņēmumiem, kas pelna tikai ar video komunikācijas risinājumiem, un salÄ«dzināsim no tiem negatÄ«vo daudzumu ar esoÅ”o.

Šie divi eksperimenti ļaus mums noteikt sasniedzamu mērķi un koncentrēties uz to.

Turklāt ir vairāki uzdevumi, kurus var atrisināt regulāri:

  • Mēs veidojam komunikācijas kvalitātes tehnisko metriku subjektÄ«vu atsauksmju vietā;
  • Mēs veidojam detalizētākus sesiju žurnālus, lai precÄ«zāk analizētu raduŔās kļūmes, saprastu, kad un kur tieÅ”i tās raduŔās un kādi Ŕķietami nesaistÄ«ti notikumi tajā brÄ«dÄ« notika;
  • Pirms nodarbÄ«bas sagatavojam automātisku savienojuma kvalitātes pārbaudi, kā arÄ« dodam klientam iespēju manuāli pārbaudÄ«t savienojumu, lai samazinātu viņa aparatÅ«ras un kanāla radÄ«to negatÄ«vismu;
  • izstrādāsim un veiksim vairāk video sakaru slodzes testu sliktos apstākļos, ar mainÄ«gu pakeÅ”u zudumu utt.;
  • mēs mainām serveru uzvedÄ«bu problēmu gadÄ«jumā, lai palielinātu kļūdu toleranci;
  • Mēs brÄ«dināsim lietotāju, ja ar viņa savienojumu vispār kaut kas nav kārtÄ«bā, kā to dara Skype, lai viņŔ saprastu, ka problēma ir viņa pusē.

KopÅ” aprīļa video komunikācijas virziens ir kļuvis par pilnvērtÄ«gu atseviŔķu projektu Skyeng ietvaros, kas nodarbojas ar savu produktu, nevis tikai Vimbox daļu. Tas nozÄ«mē, ka mēs sākam meklēt cilvēkus darbs ar video pilna laika režīmā. Nu kā vienmēr Mēs meklējam daudz labu cilvēku.

Un, protams, mēs turpinām aktīvi sazināties ar cilvēkiem un uzņēmumiem, kas strādā ar video komunikāciju. Ja vēlies ar mums apmainīties pieredzē, būsim priecīgi! Komentējiet, sazinieties - mēs atbildēsim visiem.

Avots: www.habr.com