Comunicarea video este principala modalitate de comunicare între profesor și elev pe platforma Vimbox. Am renunțat la Skype cu mult timp în urmă, am încercat mai multe soluții de la terți și, în cele din urmă, ne-am stabilit pe combinația WebRTC - Janus-gateway. De ceva vreme am fost mulțumiți de tot, dar totuși au continuat să apară unele aspecte negative. Ca rezultat, a fost creată o direcție video separată.
L-am rugat pe Kirill Rogovoy, șeful noii direcții, să vorbească despre evoluția comunicării video la Skyeng, problemele descoperite, soluțiile și cârjele pe care le-am folosit până la urmă. Sperăm că articolul va fi util companiilor care creează video și pe cont propriu printr-o aplicație web.
Un pic de istorie
În vara lui 2017, șeful dezvoltării Skyeng, Sergey Safonov, a vorbit la Backend Conf cu o poveste despre cum „am abandonat Skype și am implementat WebRTC”. Cei interesați pot urmări înregistrarea discursului la adresa (~45 min), iar aici îi voi schița pe scurt esența.
Pentru Skyeng School, comunicarea video a fost întotdeauna o modalitate prioritară de comunicare profesor-elev. La început, Skype a fost folosit, dar nu a fost categoric nesatisfăcător din mai multe motive, în primul rând din cauza lipsei de jurnale și a imposibilității integrării direct în aplicația web. Prin urmare, am efectuat tot felul de experimente.
De fapt, cerințele noastre pentru comunicarea video au fost aproximativ următoarele:
- stabilitate;
— preț mic pe lecție;
— lecții de înregistrare;
— urmărirea cine vorbește cât de mult (este important pentru noi ca elevii să vorbească mai mult decât profesorul în timpul lecțiilor);
— scalare liniară;
- capacitatea de a utiliza atât UDP, cât și TCP.
Primul care a încercat a fost implementarea Tokbox în 2013. Totul a fost bine, dar s-a dovedit a fi foarte scump - 113 ruble pe lecție - și a mâncat profitul.
Apoi, în 2015, a fost integrat Voximplant. Iată funcția de care aveam nevoie pentru a urmări cine a vorbit cât de mult și, în același timp, soluția era mult mai ieftină: dacă se înregistra doar audio, costa 20 de ruble per lecție. Cu toate acestea, a funcționat doar prin UDP și nu a putut trece la TCP. Cu toate acestea, aproximativ 40% dintre studenți au ajuns să-l folosească.
Un an mai târziu, am început să avem clienți corporativi cu propriile cerințe specifice. De exemplu, totul ar trebui să funcționeze printr-un browser; compania deschide doar http și https; adică fără Skype sau UDP. Clienții corporativi = bani, așa că s-au întors la Tokbox, dar problema prețului nu a dispărut.
Soluție - WebRTC și Janus
Hotărât să folosească . Este responsabil pentru stabilirea unei conexiuni, codificarea și decodarea fluxurilor, sincronizarea pieselor și controlul calității cu gestionarea erorilor rețelei. La noi, trebuie să ne asigurăm citirea fluxurilor de la cameră și microfon, desenarea video, gestionarea conexiunii, stabilirea unei conexiuni WebRTC și transmiterea fluxurilor către aceasta, precum și transmiterea mesajelor de semnalizare între clienți pentru a stabili o conexiune (WebRTC în sine descrie doar formatul de date, dar nu și mecanismul de transfer al acestuia). Dacă clienții sunt în spatele NAT, WebRTC conectează serverele STUN; dacă acest lucru nu ajută, serverele TURN.
O conexiune p2p obișnuită nu este suficientă pentru noi, deoarece dorim să înregistrăm lecții pentru analize ulterioare în cazul unor reclamații. Prin urmare, trimitem fluxuri WebRTC printr-un releu . Ca urmare, clienții nu cunosc adresele celuilalt, văzând doar adresa serverului Janus; îndeplinește și funcțiile unui server de semnal. Janus are multe dintre caracteristicile de care avem nevoie: trece automat la TCP dacă clientul are UDP blocat; poate înregistra atât fluxuri UDP, cât și TCP; scalabil; Există chiar și un plugin încorporat pentru testele de eco. Dacă este necesar, serverele STUN și TURN de la Twilio sunt conectate automat.
În vara lui 2017 aveam în funcțiune două servere Janus, plus un server suplimentar pentru procesarea fișierelor audio și video brute înregistrate, pentru a nu ocupa procesoarele celor principale. La conectare, serverele Janus au fost selectate pe o bază impar-par (număr de conectare). La acea vreme, acest lucru a fost suficient, conform sentimentelor noastre, a oferit o marjă de siguranță de aproximativ patru ori, procentul de implementare a fost de aproximativ 80. În același timp, prețul a fost redus la ~2 ruble pe lecție, plus dezvoltare și suport.
Revenind la subiectul comunicării video
Monitorizăm constant feedback-ul de la elevi și profesori pentru a identifica și corecta problemele în timp util. Până în vara lui 2018, calitatea apelurilor era ferm pe primul loc printre reclamații. Pe de o parte, asta însemna că am depășit cu succes alte neajunsuri. Pe de altă parte, era necesar să facem ceva urgent: dacă lecția este întreruptă, riscăm să pierdem din valoare, uneori odată cu costul achiziției următorului pachet, iar dacă lecția introductivă este întreruptă, riscăm să pierdem un potențial client. cu totul.
La acel moment, comunicarea noastră video era încă în modul MVP. Mai simplu spus, l-au lansat, a funcționat, l-au scalat o dată, au înțeles cum să o facă - bine, grozav. Dacă funcționează, nu-l repara. Nimeni nu a abordat în mod deliberat problema calității comunicării. Până în august, a devenit clar că acest lucru nu poate continua și am lansat o direcție separată pentru a ne da seama ce este în neregulă cu WebRTC și Janus.
La intrare, această direcție a primit: o soluție MVP, fără metrici, fără obiective, fără procese de îmbunătățire, în timp ce 7% dintre profesori se plâng de calitatea comunicării (nu existau date nici despre elevi).
O nouă direcție este în curs de desfășurare
Comanda arată cam așa:
- Șeful departamentului, care este și dezvoltatorul principal.
- QA ajută la testarea schimbărilor, caută noi modalități de a crea condiții instabile de comunicare și raportează problemele din prima linie.
- Analistul caută în mod constant diverse corelații în datele tehnice, îmbunătățește analiza feedback-ului utilizatorilor și verifică rezultatele experimentelor.
- Managerul de produs ajută la direcția generală și alocarea resurselor pentru experimente.
- Un al doilea dezvoltator ajută adesea la programare și sarcinile conexe.
Pentru început, am creat o măsură relativ fiabilă care a urmărit schimbările în evaluările calității comunicațiilor (medie pe zile, săptămâni, luni). La acea vreme, acestea erau note de la profesori, iar ulterior li se adăugau note de la elevi. Apoi au început să construiască ipoteze despre ceea ce a funcționat greșit, să-l corecteze și să se uite la schimbările din dinamică. Am optat pentru fructele low-hanging: de exemplu, am înlocuit codecul vp8 cu vp9, performanța s-a îmbunătățit. Am încercat să ne jucăm cu setările Janus și să realizăm alte experimente - în cele mai multe cazuri nu au dus la nimic.
În a doua etapă, a apărut o ipoteză: WebRTC este o soluție peer-to-peer, iar noi folosim un server la mijloc. Poate problema este aici? Am început să săpăm și am găsit cea mai semnificativă îmbunătățire de până acum.
În acel moment, un server din pool a fost selectat folosind un algoritm destul de stupid: fiecare avea propria „greutate”, în funcție de canal și putere, și am încercat să trimitem utilizatorul la cel cu cea mai mare „greutate”, fără acordând atenție locului în care se afla utilizatorul din punct de vedere geografic. Drept urmare, un profesor din Sankt Petersburg ar putea comunica cu un elev din Siberia prin Moscova, și nu prin serverul nostru Janus din Sankt Petersburg.
Algoritmul a fost refăcut: acum, când un utilizator deschide platforma noastră, colectăm ping-uri de la el către toate serverele care folosesc Ajax. La stabilirea unei conexiuni, selectăm o pereche de ping-uri (profesor-server și elev-server) cu cea mai mică cantitate. Mai puțin ping înseamnă mai puțină distanță de rețea până la server; distanta mai mica inseamna probabilitate mai mica de pierdere a pachetelor; Pierderea pachetelor este cel mai mare factor negativ în comunicarea video. Ponderea negativității a scăzut la jumătate în trei luni (pentru a fi corect, alte experimente au fost efectuate în acest moment, dar acesta a avut aproape sigur cel mai mare impact).
Am descoperit recent un alt lucru care nu este evident, dar aparent important: în loc de un server puternic Janus pe un canal gros, este mai bine să aveți două mai simple, cu lățime de bandă mai mică. Acest lucru a devenit clar după ce am cumpărat mașini puternice în speranța de a înghesui cât mai multe camere (sesiuni de comunicare) în ele în același timp. Serverele au o limită de lățime de bandă, pe care o putem traduce cu exactitate în numărul de camere - știm câte pot fi deschise, de exemplu, la 300 Mbit/s. De îndată ce sunt prea multe camere deschise pe un server, încetăm să-l alegem pentru activități noi până când sarcina scade. Ideea a fost că, după ce am cumpărat o mașină puternică, vom încărca canalul la maxim, astfel încât în final să fie limitat de procesor și memorie, și nu de lățime de bandă. Dar s-a dovedit că după un anumit număr de camere deschise (420), în ciuda faptului că încărcarea procesorului, memoriei și discului este încă foarte departe de limite, negativitatea începe să ajungă la suportul tehnic. Aparent, ceva se înrăutățește în interiorul lui Janus, poate că există și unele restricții acolo. Am început să experimentăm, am redus limita lățimii de bandă de la 300 la 200 Mbit/s, iar problemele au dispărut. Acum am cumpărat trei servere noi deodată cu limite și caracteristici scăzute, credem că acest lucru va duce la o îmbunătățire stabilă a calității comunicației. Desigur, nu am încercat să ne dăm seama ce se întâmplă acolo; cârjele noastre sunt totul. În apărarea noastră, să spunem că în acel moment era necesar să rezolvăm cât mai repede problema presantă și să nu o facem frumos; în plus, Janus pentru noi este o cutie neagră scrisă cu C, este foarte scump să o faci.
Ei bine, în acest proces noi:
- actualizat toate dependențele care puteau fi actualizate, atât pe server, cât și pe client (au fost și acestea experimente, am monitorizat rezultatele);
- a remediat toate erorile identificate legate de cazuri specifice, de exemplu, când conexiunea a încetat și nu a fost restaurată automat;
- Am avut o mulțime de întâlniri cu companii care lucrează în domeniul comunicațiilor video și familiarizate cu problemele noastre: jocuri de streaming, organizarea de webinarii; am încercat tot ce ni s-a părut de folos;
- A efectuat o revizuire tehnică a hardware-ului și a calității comunicării profesorilor, de la care au venit cele mai multe reclamații.
Experimentele și modificările ulterioare au făcut posibilă reducerea nemulțumirii față de comunicarea în rândul profesorilor de la 7,1% în ianuarie 2018 la 2,5% în ianuarie 2019.
Ce urmează
Stabilizarea platformei noastre Vimbox este unul dintre principalele proiecte ale companiei pentru 2019. Avem mari speranțe că vom reuși să menținem impulsul și să nu mai vedem comunicarea video în topul reclamațiilor. Înțelegem că o parte semnificativă a acestor reclamații sunt legate de întârzieri în computerele utilizatorilor și pe internet, dar trebuie să stabilim această parte și să rezolvăm restul. Orice altceva este o problemă tehnică, se pare că ar trebui să putem face față.
Principala dificultate este că nu știm până la ce nivel este de fapt posibil să îmbunătățim calitatea. Aflarea acestui plafon este sarcina principală. Prin urmare, au fost planificate două experimente:
- compara video prin Janus cu p2p obișnuit în condiții de luptă. Acest experiment a fost deja efectuat, nu a fost găsită nicio diferență semnificativă statistic între soluția noastră și p2p;
- Să furnizăm servicii (costisitoare) de la companii care câștigă bani exclusiv pe soluții de comunicații video și să comparăm cantitatea de negativitate de la acestea cu cea existentă.
Aceste două experimente ne vor permite să identificăm un obiectiv realizabil și să ne concentrăm asupra acestuia.
În plus, există o serie de sarcini care pot fi rezolvate în mod obișnuit:
- Creăm o metrică tehnică a calității comunicării în loc de recenzii subiective;
- Realizăm jurnalele de sesiune mai detaliate pentru a analiza cu mai multă acuratețe defecțiunile care apar, pentru a înțelege când și unde exact au avut loc și ce evenimente aparent fără legătură au avut loc în acel moment;
- Pregătim un test automat de calitate a conexiunii înainte de lecție și, de asemenea, oferim clientului posibilitatea de a testa manual conexiunea pentru a reduce cantitatea de negativitate cauzată de hardware-ul și canalul său;
- vom dezvolta și efectua mai multe teste de încărcare a comunicațiilor video în condiții proaste, cu pierderi variabile de pachete etc.;
- schimbam comportamentul serverelor in caz de probleme pentru a creste toleranta la erori;
- Vom avertiza utilizatorul dacă este ceva în neregulă cu conexiunea lui, așa cum face Skype, astfel încât să înțeleagă că problema este de partea lui.
Din aprilie, direcția de comunicare video a devenit un proiect separat cu drepturi depline în cadrul Skyeng, care se ocupă de propriul produs, nu doar de o parte a Vimbox. Asta înseamnă că începem să căutăm oameni pe . Ei bine, ca întotdeauna .
Și, desigur, continuăm să comunicăm activ cu oameni și companii care lucrează cu comunicații video. Dacă doriți să faceți schimb de experiență cu noi, vom fi bucuroși! Comentați, contactați - vom răspunde tuturor.
Sursa: www.habr.com