Video komunikacija je glavni način komunikacije med učiteljem in učencem na platformi Vimbox. Skype smo že zdavnaj opustili, preizkusili več rešitev tretjih oseb in se na koncu odločili za kombinacijo WebRTC - Janus-gateway. Nekaj časa smo bili z vsem zadovoljni, vendar so se še vedno pojavljale nekatere negativne plati. Posledično je nastala ločena video smer.
Kirilla Rogovoya, vodjo nove smeri, sem prosil, naj spregovori o evoluciji video komunikacije v Skyeng, odkritih težavah, rešitvah in berglah, ki smo jih na koncu uporabili. Upamo, da bo članek koristen za podjetja, ki tudi sami ustvarjajo video prek spletne aplikacije.
Malo zgodovine
Poleti 2017 je vodja razvoja Skyeng, Sergey Safonov, govoril na Backend Conf z zgodbo o tem, kako smo "opustili Skype in implementirali WebRTC." Zainteresirani si lahko ogledate posnetek govora na (~45 min), tukaj pa bom na kratko orisal njeno bistvo.
Za šolo Skyeng je bila video komunikacija vedno prednostni način komunikacije učitelj-učenec. Sprva je bil uporabljen Skype, ki pa kategorično ni bil zadovoljiv iz več razlogov, predvsem zaradi pomanjkanja dnevnikov in nemožnosti neposredne integracije v spletno aplikacijo. Zato smo izvedli najrazličnejše poskuse.
Pravzaprav so bile naše zahteve za video komunikacijo približno naslednje:
— stabilnost;
— nizka cena na lekcijo;
— snemanje pouka;
— spremljanje, kdo koliko govori (pomembno nam je, da učenci pri pouku govorijo več kot učitelj);
— linearno skaliranje;
- sposobnost uporabe tako UDP kot TCP.
Prvi, ki je poskušal implementirati Tokbox leta 2013. Vse je bilo dobro, vendar se je izkazalo, da je zelo drago - 113 rubljev na lekcijo - in je požrlo dobiček.
Nato je bil leta 2015 integriran Voximplant. Tu je bila funkcija, ki smo jo potrebovali, da bi spremljali, kdo koliko govori, hkrati pa je bila rešitev veliko cenejša: če je bil posnet samo zvok, je stalo 20 rubljev na lekcijo. Vendar je deloval samo prek UDP in ni mogel preklopiti na TCP. Vendar ga je na koncu uporabilo približno 40 % študentov.
Leto kasneje so se nam začele pojavljati korporativne stranke s svojimi specifičnimi zahtevami. Na primer, vse bi moralo delovati prek brskalnika, podjetje odpre samo http in https; tj. brez Skypa ali UDP. Korporativne stranke = denar, zato so se vrnile v Tokbox, vendar problem cene ni izginil.
Rešitev - WebRTC in Janus
Odločil se je za uporabo . Odgovoren je za vzpostavitev povezave, kodiranje in dekodiranje tokov, sinhronizacijo skladb in nadzor kakovosti z obravnavanjem omrežnih napak. Z naše strani moramo zagotoviti branje tokov iz kamere in mikrofona, risanje videa, upravljanje povezave, vzpostavitev povezave WebRTC in prenos tokov vanjo ter prenos signalnih sporočil med odjemalci za vzpostavitev povezave (WebRTC sam opisuje samo podatkovni format, ne pa tudi njegov mehanizem prenosa). Če so odjemalci za NAT, WebRTC poveže strežnike STUN; če to ne pomaga, strežnike TURN.
Redna p2p povezava nam ne zadošča, saj želimo beležiti lekcije za nadaljnjo analizo v primeru reklamacij. Zato pošiljamo tokove WebRTC prek releja . Posledično odjemalci ne poznajo naslovov drug drugega, vidijo le naslov strežnika Janus; opravlja tudi funkcije signalnega strežnika. Janus ima veliko funkcij, ki jih potrebujemo: samodejno preklopi na TCP, če ima odjemalec blokiran UDP; lahko snema tokove UDP in TCP; razširljiv; Obstaja celo vgrajen vtičnik za teste odmeva. Po potrebi se samodejno povežeta strežnika STUN in TURN iz Twilia.
Poleti 2017 smo imeli v pogonu dva Janusova strežnika ter dodatni strežnik za obdelavo posnetih surovih avdio in video datotek, da ne bi zasedali procesorjev glavnih. Pri povezovanju so bili Janusovi strežniki izbrani po sodo-lihi osnovi (številka povezave). Takrat je bilo to dovolj, po naših občutkih je dalo približno štirikratno varnostno rezervo, odstotek implementacije je bil približno 80. Hkrati se je cena znižala na ~2 rublja na lekcijo, plus razvoj in podpora.
Če se vrnem k temi video komunikacije
Nenehno spremljamo povratne informacije učencev in učiteljev, da bi pravočasno prepoznali in odpravili težave. Do poletja 2018 je bila kakovost klicev trdno na prvem mestu med pritožbami. Po eni strani je to pomenilo, da smo uspešno premagali druge pomanjkljivosti. Po drugi strani pa je bilo treba nujno nekaj storiti: če je učna ura motena, tvegamo izgubo njene vrednosti, včasih skupaj s stroškom nakupa naslednjega paketa, če je uvodna učna ura motena, tvegamo izgubo potencialne stranke. skupaj.
Takrat je bila naša video komunikacija še v načinu MVP. Preprosto povedano, zagnali so ga, delovalo je, enkrat so ga prilagodili, razumeli so, kako to narediti - no, super. Če deluje, ga ne popravljajte. Nihče se namenoma ni lotil vprašanja kakovosti komunikacije. Do avgusta je postalo jasno, da se to ne more nadaljevati, in sprožili smo ločeno smer, da bi ugotovili, kaj je narobe z WebRTC in Janusom.
Na vhodu je ta smer prejela: rešitev MVP, brez metrik, brez ciljev, brez procesov za izboljšave, medtem ko se 7 % učiteljev pritožuje nad kakovostjo komunikacije (tudi podatkov o študentih ni bilo).
V teku je nova smer
Ukaz izgleda nekako takole:
- Vodja oddelka, ki je tudi glavni razvijalec.
- QA pomaga testirati spremembe, išče nove načine za ustvarjanje nestabilnih komunikacijskih pogojev in poroča o težavah iz prve linije.
- Analitik nenehno išče različne korelacije v tehničnih podatkih, izboljšuje analizo povratnih informacij uporabnikov in preverja rezultate eksperimentov.
- Produktni vodja pomaga pri splošnem usmerjanju in dodeljevanju virov za poskuse.
- Drugi razvijalec pogosto pomaga pri programiranju in sorodnih opravilih.
Za začetek smo postavili razmeroma zanesljivo metriko, ki je spremljala spremembe v ocenah kakovosti komunikacije (povprečje po dneh, tednih, mesecih). Takrat so bile to ocene učiteljev, kasneje so se jim dodale še ocene učencev. Nato so začeli graditi hipoteze o tem, kaj je delovalo narobe, to popravljati in opazovati spremembe v dinamiki. Odločili smo se za nizko viseče sadje: na primer, zamenjali smo kodek vp8 z vp9, zmogljivost se je izboljšala. Poskušali smo se igrati z nastavitvami Janusa in izvesti druge poskuse - v večini primerov niso pripeljali do ničesar.
Na drugi stopnji se je pojavila hipoteza: WebRTC je peer-to-peer rešitev, vmes pa uporabljamo strežnik. Morda je težava tukaj? Začeli smo kopati in našli najpomembnejšo izboljšavo doslej.
V tistem trenutku je bil strežnik iz bazena izbran po precej neumnem algoritmu: vsak je imel svojo “težo”, odvisno od kanala in moči, uporabnika pa smo poskušali poslati na tistega z največjo “težo”, brez pozoren na to, kje se uporabnik geografsko nahaja. Posledično je učitelj iz Sankt Peterburga lahko komuniciral z učencem iz Sibirije prek Moskve in ne prek našega strežnika Janus v Sankt Peterburgu.
Algoritem je bil prenovljen: zdaj, ko uporabnik odpre našo platformo, od njega zbiramo pinge do vseh strežnikov, ki uporabljajo Ajax. Pri vzpostavljanju povezave izberemo par pingov (učitelj-strežnik in učenec-strežnik) z najmanjšo količino. Manj pinga pomeni manjšo omrežno razdaljo do strežnika; krajša razdalja pomeni manjšo verjetnost izgube paketov; Izguba paketov je največji negativni dejavnik pri video komunikaciji. Delež negativnosti se je v treh mesecih zmanjšal za polovico (po pravici povedano, v tem času so bili izvedeni tudi drugi poskusi, a ta je skoraj zagotovo imel največji učinek).
Nedavno smo odkrili še eno neočitno, a očitno pomembno stvar: namesto enega zmogljivega Janusovega strežnika na debelem kanalu je bolje imeti dva enostavnejša s tanjšo pasovno širino. To je postalo jasno, ko smo kupili močne stroje v upanju, da bomo vanje strpali čim več sob (komunikacijskih sej) hkrati. Strežniki imajo omejitev pasovne širine, ki jo lahko natančno prevedemo v število sob – vemo, koliko jih lahko odpremo na primer pri 300 Mbit/s. Takoj, ko je na strežniku odprtih preveč sob, ga prenehamo izbirati za nove aktivnosti, dokler se obremenitev ne zmanjša. Ideja je bila, da bi po nakupu zmogljivega stroja kanal do njega maksimalno obremenili, tako da bi bil na koncu omejen s procesorjem in pomnilnikom in ne s pasovno širino. Izkazalo pa se je, da po določenem številu odprtih prostorov (420), kljub dejstvu, da je obremenitev procesorja, pomnilnika in diska še vedno zelo daleč od meja, negativnost začne prihajati na tehnično podporo. Očitno se znotraj Janusa nekaj slabša, morda so tudi tam kakšne omejitve. Začeli smo eksperimentirati, znižali omejitev pasovne širine s 300 na 200 Mbit/s in težave so izginile. Zdaj smo kupili tri nove strežnike naenkrat z nizkimi omejitvami in značilnostmi, menimo, da bo to privedlo do stabilnega izboljšanja kakovosti komunikacije. Seveda nismo poskušali ugotoviti, kaj se tam dogaja, naše bergle so vse. V svojo obrambo povejmo, da je bilo v tistem trenutku treba pereč problem rešiti čim hitreje, ne pa lepo; poleg tega je Janus za nas črna skrinjica, napisana v C, zelo drago je poigravati se z njo.
No, v procesu mi:
- posodobljene vse odvisnosti, ki jih je bilo mogoče posodobiti, tako na strežniku kot na odjemalcu (tudi to so bili poskusi, spremljali smo rezultate);
- popravljene vse ugotovljene napake, povezane s posebnimi primeri, na primer, ko je povezava padla in ni bila samodejno obnovljena;
- Opravili smo veliko sestankov s podjetji, ki delujejo na področju video komunikacij in poznajo našo problematiko: pretakanje iger, organizacija webinarjev; poskusili smo vse, kar se nam je zdelo koristno;
- Opravili tehnični pregled strojne in komunikacijske kakovosti učiteljev, od katerih je prišlo največ pritožb.
Eksperimenti in kasnejše spremembe so omogočili zmanjšanje nezadovoljstva s komunikacijo med učitelji s 7,1 % januarja 2018 na 2,5 % januarja 2019.
Kaj je naslednje?
Stabilizacija naše platforme Vimbox je eden glavnih projektov podjetja za leto 2019. Zelo upamo, da bomo uspeli ohraniti zagon in video komunikacije ne bomo več videli med glavnimi pritožbami. Zavedamo se, da je precejšen del teh pritožb povezan z zaostanki uporabnikovih računalnikov in interneta, vendar moramo ta del ugotoviti, ostalo pa rešiti. Vse drugo je tehnična težava, zdi se, da bi ji morali biti kos.
Glavna težava je v tem, da ne vemo, do katere stopnje je dejansko mogoče izboljšati kakovost. Najti to zgornjo mejo je glavna naloga. Zato sta bila načrtovana dva poskusa:
- primerjajte video prek Janusa z običajnim p2p v bojnih razmerah. Ta poskus je bil že izveden, med našo raztopino in p2p ni bilo ugotovljene statistično pomembne razlike;
- Dobavimo (drage) storitve podjetij, ki služijo denar izključno na video komunikacijskih rešitvah, in primerjajmo količino negativnosti od njih z obstoječo.
Ta dva poskusa nam bosta omogočila, da prepoznamo dosegljiv cilj in se osredotočimo nanj.
Poleg tega obstajajo številne naloge, ki jih je mogoče rutinsko rešiti:
- Ustvarimo tehnično metriko kakovosti komunikacije namesto subjektivnih ocen;
- Naredimo podrobnejše dnevnike sej, da bi natančneje analizirali nastale napake, razumeli, kdaj in kje natančno so se zgodile ter kateri na videz nepovezani dogodki so se zgodili v tistem trenutku;
- Pred lekcijo pripravimo samodejni test kakovosti povezave, naročniku pa damo tudi možnost ročnega testiranja povezave, da zmanjšamo količino negativnosti, ki jo povzročata njegova strojna oprema in kanal;
- razvili in izvedli bomo več testov obremenitve videokomunikacije v slabih pogojih, s spremenljivo izgubo paketov itd.;
- spremenimo obnašanje strežnikov v primeru težav, da povečamo toleranco na napake;
- Uporabnika bomo opozorili, če je z njegovo povezavo sploh kaj narobe, kot to počne Skype, da bo razumel, da je težava na njegovi strani.
Smer videokomunikacije je od aprila postala samostojen projekt znotraj Skyenga, ki se ukvarja s svojim produktom, ne le delom Vimboxa. To pomeni, da začnemo iskati ljudi na . No, kot vedno .
In seveda še naprej aktivno komuniciramo z ljudmi in podjetji, ki se ukvarjajo z video komunikacijami. Če želite z nami izmenjati izkušnje, bomo veseli! Komentirajte, stopite v stik - odgovorili bomo vsem.
Vir: www.habr.com