La comunicació de vídeo és la principal via de comunicació entre professor i alumne a la plataforma Vimbox. Vam renunciar a Skype fa molt de temps, vam provar diverses solucions de tercers i finalment vam optar per la combinació WebRTC - Janus-gateway. Durant un temps vam estar contents amb tot, però tot i així van continuar sorgint alguns aspectes negatius. Com a resultat, es va crear una direcció de vídeo separada.
Vaig demanar a Kirill Rogovoy, cap de la nova direcció, que parlés de l'evolució de la comunicació de vídeo a Skyeng, dels problemes descoberts, de les solucions i de les crosses que vam utilitzar finalment. Esperem que l'article sigui útil per a les empreses que també creen vídeo per si mateixes a través d'una aplicació web.
Una mica d'història
A l'estiu del 2017, el cap de desenvolupament de Skyeng, Sergey Safonov, va parlar a Backend Conf amb una història sobre com vam "abandonar Skype i implementar WebRTC". Les persones interessades poden veure la gravació de la intervenció a (~45 min), i aquí en resumiré breument l'essència.
Per a l'escola Skyeng, la comunicació de vídeo sempre ha estat una via prioritària de comunicació professor-alumne. Al principi, s'utilitzava Skype, però categòricament no era satisfactori per diverses raons, principalment per la manca de registres i la impossibilitat d'integrar-se directament a l'aplicació web. Per tant, hem fet tot tipus d'experiments.
De fet, els nostres requisits per a la comunicació de vídeo eren aproximadament els següents:
- estabilitat;
— preu baix per lliçó;
- enregistrament de lliçons;
— fer un seguiment de qui parla quant (és important per a nosaltres que els alumnes parlin més que el professor durant les classes);
- escala lineal;
- Capacitat d'utilitzar tant UDP com TCP.
El primer a intentar va ser implementar Tokbox el 2013. Tot anava bé, però va resultar molt car (113 rubles per lliçó) i es va consumir els beneficis.
Després, el 2015, es va integrar Voximplant. Aquesta era la funció que necessitàvem per fer un seguiment de qui parlava quant i, alhora, la solució era molt més barata: si només es gravava àudio, costava 20 rubles per lliçó. Tanmateix, només funcionava mitjançant UDP i no podia canviar a TCP. Tanmateix, al voltant del 40% dels estudiants l'han acabat utilitzant.
Un any més tard, vam començar a tenir clients corporatius amb els seus requisits específics. Per exemple, tot hauria de funcionar a través d'un navegador, l'empresa només obre http i https; és a dir, sense Skype ni UDP. Clients corporatius = diners, així que van tornar a Tokbox, però el problema del preu no va desaparèixer.
Solució: WebRTC i Janus
Decidit a utilitzar . S'encarrega d'establir una connexió, codificar i descodificar fluxos, sincronitzar pistes i controlar la qualitat amb la gestió de fallades de xarxa. Per la nostra banda, hem d'assegurar-nos de llegir els fluxos de la càmera i del micròfon, dibuixar vídeo, gestionar la connexió, establir una connexió WebRTC i transmetre-hi fluxos, així com transmetre missatges de senyalització entre clients per establir una connexió (el mateix WebRTC descriu només la format de dades, però no el seu mecanisme de transferència). Si els clients estan darrere de NAT, WebRTC connecta els servidors STUN; si això no ajuda, els servidors TURN.
Una connexió p2p normal no és suficient per a nosaltres, perquè volem gravar lliçons per a una anàlisi posterior en cas de queixes. Per tant, enviem fluxos WebRTC a través d'un relé . Com a resultat, els clients no coneixen les adreces dels altres, només veuen l'adreça del servidor Janus; també realitza les funcions de servidor de senyals. Janus té moltes de les característiques que necessitem: canvia automàticament a TCP si el client té UDP bloquejat; pot gravar tant flux UDP com TCP; escalable; Fins i tot hi ha un connector integrat per a proves d'eco. Si cal, els servidors STUN i TURN de Twilio es connecten automàticament.
A l'estiu del 2017 teníem dos servidors Janus en funcionament, més un servidor addicional per processar fitxers d'àudio i vídeo en brut gravats, per no ocupar els processadors dels principals. En connectar-se, els servidors Janus es van seleccionar de manera imparell (número de connexió). En aquell moment, això era suficient, segons els nostres sentiments, donava un marge de seguretat aproximadament quatre vegades superior, el percentatge d'implementació era d'uns 80. Al mateix temps, el preu es va reduir a ~ 2 rubles per lliçó, més desenvolupament i suport.
Tornant al tema de la videocomunicació
Fem un seguiment constant dels comentaris d'alumnes i professors per tal d'identificar i corregir els problemes de manera oportuna. A l'estiu del 2018, la qualitat de les trucades ocupava el primer lloc entre les queixes. D'una banda, això significava que havíem superat amb èxit altres mancances. D'altra banda, calia fer alguna cosa amb urgència: si la lliçó s'interromp, correm el risc de perdre el seu valor, de vegades juntament amb el cost d'adquirir el següent paquet, i si s'interromp la lliçó introductòria, correm el risc de perdre un client potencial. en conjunt.
En aquell moment, la nostra comunicació de vídeo encara estava en mode MVP. En poques paraules, el van llançar, va funcionar, el van escalar una vegada, van entendre com fer-ho, bé, genial. Si funciona, no ho arregleu. Ningú va abordar deliberadament el tema de la qualitat de la comunicació. A l'agost, va quedar clar que això no podia continuar i vam llançar una direcció separada per esbrinar què passava amb WebRTC i Janus.
A l'entrada, aquesta direcció va rebre: una solució MVP, sense mètriques, sense objectius, sense processos de millora, mentre que el 7% dels professors es queixen de la qualitat de la comunicació (tampoc hi havia dades sobre els alumnes).
Una nova direcció està en marxa
L'ordre s'assembla a això:
- El cap del departament, que també és el principal desenvolupador.
- El control de qualitat ajuda a provar els canvis, busca noves maneres de crear condicions de comunicació inestables i informa de problemes des de la primera línia.
- L'analista busca constantment diverses correlacions en les dades tècniques, millora l'anàlisi dels comentaris dels usuaris i comprova els resultats dels experiments.
- El gestor de producte ajuda amb la direcció general i l'assignació de recursos per als experiments.
- Un segon desenvolupador sovint ajuda amb la programació i les tasques relacionades.
Per començar, vam establir una mètrica relativament fiable que feia un seguiment dels canvis en les avaluacions de la qualitat de la comunicació (mitjana durant dies, setmanes, mesos). Aleshores, aquestes eren qualificacions dels professors; posteriorment s'hi van afegir notes dels estudiants. Aleshores van començar a construir hipòtesis sobre què funcionava malament, a corregir-ho i a observar els canvis en la dinàmica. Vam optar per la fruita baixa: per exemple, vam substituir el còdec vp8 per vp9, el rendiment va millorar. Vam intentar jugar amb la configuració de Janus i fer altres experiments, en la majoria dels casos no van conduir a res.
En la segona etapa, va sorgir una hipòtesi: WebRTC és una solució peer-to-peer, i fem servir un servidor al mig. Potser el problema rau aquí? Vam començar a excavar i vam trobar la millora més significativa fins ara.
En aquell moment, es va seleccionar un servidor del grup mitjançant un algorisme bastant estúpid: cadascun tenia el seu propi "pes", segons el canal i la potència, i vam intentar enviar l'usuari al que tenia el "pes" més gran, sense prestant atenció a on es trobava geogràficament l'usuari. Com a resultat, un professor de Sant Petersburg podria comunicar-se amb un estudiant de Sibèria a través de Moscou, i no a través del nostre servidor Janus a Sant Petersburg.
L'algorisme s'ha refet: ara, quan un usuari obre la nostra plataforma, recollim pings d'ell a tots els servidors que utilitzen Ajax. En establir una connexió, seleccionem un parell de pings (professor-servidor i alumne-servidor) amb la menor quantitat. Menys ping significa menys distància de xarxa al servidor; una distància més curta significa una menor probabilitat de perdre paquets; La pèrdua de paquets és el factor negatiu més important en la comunicació de vídeo. La quota de negativitat es va reduir a la meitat en tres mesos (per ser justos, es van dur a terme altres experiments en aquest moment, però aquest gairebé segur que va tenir més impacte).
Recentment hem descobert una altra cosa no òbvia, però aparentment important: en comptes d'un servidor Janus potent en un canal gruixut, és millor tenir-ne dos més senzills amb una amplada de banda més fina. Això va quedar clar després que vam comprar màquines potents amb l'esperança d'amuntegar tantes sales (sessions de comunicació) al mateix temps. Els servidors tenen un límit d'ample de banda, que podem traduir amb precisió en el nombre d'habitacions: sabem quantes es poden obrir, per exemple, a 300 Mbit/s. Tan bon punt hi hagi massa sales obertes en un servidor, deixem de triar-lo per a noves activitats fins que la càrrega disminueixi. La idea era que, havent comprat una màquina potent, hi carregaríem el canal al màxim, de manera que al final quedés limitat pel processador i la memòria, i no per l'ample de banda. Però va resultar que després d'un cert nombre de sales obertes (420), malgrat que la càrrega del processador, la memòria i el disc encara està molt lluny dels límits, la negativitat comença a arribar al suport tècnic. Pel que sembla, alguna cosa empitjora dins de Janus, potser també hi ha algunes restriccions. Vam començar a experimentar, vam baixar el límit d'ample de banda de 300 a 200 Mbit/s i els problemes van desaparèixer. Ara hem comprat tres nous servidors alhora amb límits i característiques baixes, pensem que això comportarà una millora estable de la qualitat de la comunicació. Per descomptat, no vam intentar esbrinar què passava allà; les nostres crosses ho són tot. En la nostra defensa, diguem que en aquell moment calia resoldre el problema urgent el més ràpid possible, i no fer-ho bé; a més, Janus per a nosaltres és una caixa negra escrita en C, és molt car jugar-hi.
Bé, en el procés:
- actualitzem totes les dependències que es podien actualitzar, tant al servidor com al client (també eren experiments, vam fer un seguiment dels resultats);
- es van corregir tots els errors identificats relacionats amb casos concrets, per exemple, quan la connexió es va caure i no es va restaurar automàticament;
- Vam mantenir moltes reunions amb empreses que treballen en l'àmbit de la videocomunicació i que coneixien els nostres problemes: jocs en streaming, organització de seminaris web; vam provar tot allò que ens va semblar útil;
- S'ha realitzat una revisió tècnica del maquinari i la qualitat de la comunicació del professorat, dels quals provenen més queixes.
Els experiments i els canvis posteriors van permetre reduir la insatisfacció amb la comunicació entre el professorat del 7,1% el gener del 2018 al 2,5% el gener del 2019.
Què és el següent
L'estabilització de la nostra plataforma Vimbox és un dels principals projectes de la companyia per al 2019. Tenim moltes esperances que podrem mantenir l'impuls i deixar de veure la comunicació de vídeo a les principals queixes. Entenem que una part important d'aquestes queixes estan relacionades amb retards en els ordinadors i Internet dels usuaris, però hem de determinar aquesta part i resoldre la resta. Tota la resta és un problema tècnic, sembla que hauríem de ser capaços de fer-hi front.
La principal dificultat és que no sabem fins a quin nivell és realment possible millorar la qualitat. Esbrinar aquest sostre és la tasca principal. Per tant, es van planificar dos experiments:
- compara el vídeo a través de Janus amb p2p normal en condicions de combat. Aquest experiment ja s'ha realitzat, no es va trobar cap diferència estadísticament significativa entre la nostra solució i p2p;
- Subministrem serveis (cars) d'empreses que guanyen diners exclusivament amb solucions de comunicació de vídeo i comparem la quantitat de negativitat d'aquestes amb l'existent.
Aquests dos experiments ens permetran identificar un objectiu assolible i centrar-nos-hi.
A més, hi ha una sèrie de tasques que es poden resoldre de manera rutinària:
- Creem una mètrica tècnica de qualitat de la comunicació en lloc de revisions subjectives;
- Fem registres de sessió més detallats per analitzar amb més precisió els errors que es produeixen, entendre quan i on es van produir exactament, i quins esdeveniments aparentment no relacionats van tenir lloc en aquell moment;
- Preparem una prova automàtica de qualitat de connexió abans de la lliçó, i també donem al client l'oportunitat de provar la connexió manualment per tal de reduir la quantitat de negativitat causada pel seu maquinari i canal;
- desenvoluparem i realitzarem més proves de càrrega de comunicació de vídeo en males condicions, amb pèrdua variable de paquets, etc.;
- canviem el comportament dels servidors en cas de problemes per augmentar la tolerància a errors;
- Avisarem l'usuari si hi ha alguna cosa malament amb la seva connexió, com fa Skype, perquè entengui que el problema està del seu costat.
Des de l'abril, la direcció de comunicació de vídeo s'ha convertit en un projecte independent complet dins de Skyeng, que tracta el seu propi producte, no només una part de Vimbox. Això vol dir que estem començant a buscar gent . Bé, com sempre .
I, per descomptat, continuem comunicant-nos activament amb persones i empreses que treballen amb comunicacions de vídeo. Si vols intercanviar experiències amb nosaltres, estarem encantats! Comenta, posa't en contacte: respondrem a tothom.
Font: www.habr.com