A comunicación por vídeo é a principal vía de comunicación entre profesor e alumno na plataforma Vimbox. Renunciamos a Skype hai moito tempo, probamos varias solucións de terceiros e finalmente decidimos a combinación WebRTC - Janus-gateway. Durante algún tempo estivemos contentos con todo, pero aínda así seguiron xurdindo algúns aspectos negativos. Como resultado, creouse unha dirección de vídeo separada.
Pedinlle a Kirill Rogovoy, xefe da nova dirección, que falase da evolución da comunicación por vídeo en Skyeng, dos problemas descubertos, das solucións e das muletas que finalmente utilizamos. Agardamos que o artigo sexa útil para as empresas que tamén crean vídeos pola súa conta a través dunha aplicación web.
Un pouco de historia
No verán de 2017, o xefe de desenvolvemento de Skyeng, Sergey Safonov, falou en Backend Conf cunha historia sobre como "abandonamos Skype e implementamos WebRTC". Os interesados poden ver a gravación da intervención en (~45 min), e aquí esbozarei brevemente a súa esencia.
Para Skyeng School, a comunicación por vídeo sempre foi unha forma prioritaria de comunicación profesor-alumno. Nun principio utilizouse Skype, pero categoricamente non resultou satisfactorio por varias razóns, principalmente pola falta de rexistros e a imposibilidade de integración directa na aplicación web. Por iso, realizamos todo tipo de experimentos.
En realidade, os nosos requisitos para a comunicación de vídeo eran aproximadamente os seguintes:
- estabilidade;
- prezo baixo por lección;
- gravación de clases;
— rastrexar quen fala canto (é importante para nós que os estudantes falen máis que o profesor durante as clases);
- escala lineal;
- Capacidade de usar tanto UDP como TCP.
O primeiro en tentar foi implementar Tokbox en 2013. Todo estaba ben, pero resultou moi caro - 113 rublos por lección - e comía o beneficio.
Despois, en 2015, integrouse Voximplant. Aquí estaba a función que necesitabamos para rastrexar quen falaba canto e, ao mesmo tempo, a solución era moito máis barata: se só se gravaba audio, custaba 20 rublos por lección. Non obstante, só funcionaba a través de UDP e non podía cambiar a TCP. Non obstante, preto do 40% dos estudantes acabou utilizándoo.
Un ano despois, comezamos a ter clientes corporativos con requisitos específicos propios. Por exemplo, todo debería funcionar a través dun navegador, a empresa só abre http e https; é dicir, sen Skype nin UDP. Clientes corporativos = cartos, polo que volveron a Tokbox, pero o problema do prezo non desapareceu.
Solución: WebRTC e Janus
Decidiu usar . Encárgase de establecer unha conexión, codificar e descodificar fluxos, sincronizar pistas e controlar a calidade coa xestión de fallos de rede. Pola nosa banda, debemos asegurarnos de ler fluxos desde a cámara e o micrófono, debuxar vídeo, xestionar a conexión, establecer unha conexión WebRTC e transmitirlle fluxos, así como transmitir mensaxes de sinalización entre clientes para establecer unha conexión (o propio WebRTC describe só o formato de datos, pero non o seu mecanismo de transferencia). Se os clientes están detrás de NAT, WebRTC conecta os servidores STUN; se isto non axuda, os servidores TURN.
Unha conexión p2p normal non é suficiente para nós, porque queremos gravar as leccións para analizalas máis en caso de queixas. Polo tanto, enviamos fluxos WebRTC a través dun relé . Como resultado, os clientes non coñecen os enderezos dos outros, vendo só o enderezo do servidor de Janus; tamén realiza as funcións de servidor de sinais. Janus ten moitas das características que necesitamos: cambia automaticamente a TCP se o cliente ten UDP bloqueado; pode gravar fluxos UDP e TCP; escalable; Incluso hai un complemento integrado para probas de eco. Se é necesario, os servidores STUN e TURN de Twilio conéctanse automaticamente.
No verán de 2017 tiñamos en funcionamento dous servidores Janus, ademais dun servidor adicional para procesar ficheiros de audio e vídeo en bruto gravados, para non ocupar os procesadores dos principais. Ao conectarse, seleccionáronse os servidores de Janus nunha base impar-par (número de conexión). Nese momento, isto era suficiente, segundo os nosos sentimentos, daba aproximadamente unha marxe de seguridade cuádruple, a porcentaxe de implementación era de aproximadamente 80. Ao mesmo tempo, o prezo reduciuse a ~ 2 rublos por lección, ademais de desenvolvemento e apoio.
Volvendo ao tema da videocomunicación
Seguimos constantemente os comentarios dos alumnos e dos profesores para identificar e corrixir os problemas de forma oportuna. No verán de 2018, a calidade das chamadas ocupaba o primeiro lugar entre as queixas. Por unha banda, isto significaba que superamos con éxito outras carencias. Por outra banda, había que facer algo con urxencia: se a lección se interrompe, corremos o risco de perder o seu valor, ás veces xunto co custo da compra do seguinte paquete, e se se interrompe a lección de iniciación, corremos o risco de perder un cliente potencial. en conxunto.
Nese momento, a nosa comunicación de vídeo aínda estaba en modo MVP. En pocas palabras, lanzárono, funcionou, escalárono unha vez, entenderon como facelo, ben, xenial. Se funciona, non o arranxes. Ninguén abordou deliberadamente o tema da calidade da comunicación. En agosto, quedou claro que isto non podía continuar e lanzamos unha dirección separada para descubrir o que estaba mal con WebRTC e Janus.
Na entrada, esta dirección recibiu: unha solución de MVP, sen métricas, sen obxectivos, sen procesos de mellora, mentres que o 7% do profesorado quéixase da calidade da comunicación (tampouco había datos sobre o alumnado).
Unha nova dirección está en marcha
O comando parece algo así:
- O xefe do departamento, que tamén é o principal promotor.
- O control de calidade axuda a probar os cambios, busca novas formas de crear condicións de comunicación inestables e informa de problemas desde a primeira liña.
- O analista busca constantemente varias correlacións nos datos técnicos, mellora a análise dos comentarios dos usuarios e verifica os resultados dos experimentos.
- O xestor de produto axuda coa dirección xeral e a asignación de recursos para os experimentos.
- Un segundo programador a miúdo axuda coa programación e tarefas relacionadas.
Para comezar, configuramos unha métrica relativamente fiable que facía un seguimento dos cambios nas avaliacións da calidade da comunicación (media en días, semanas e meses). Nese momento, estas eran as cualificacións dos profesores; máis tarde engadíronlles as notas dos estudantes. Despois comezaron a construír hipóteses sobre o que funcionaba mal, corrixilo e analizar os cambios na dinámica. Fomos pola froita baixa: por exemplo, substituímos o códec vp8 por vp9, o rendemento mellorou. Tentamos xogar coa configuración de Janus e realizar outros experimentos, na maioría dos casos non levaron a nada.
Na segunda etapa, xurdiu unha hipótese: WebRTC é unha solución peer-to-peer e usamos un servidor no medio. Quizais o problema está aquí? Comezamos a escavar e atopamos a mellora máis significativa ata agora.
Nese momento, seleccionouse un servidor do grupo mediante un algoritmo bastante estúpido: cada un tiña o seu propio "peso", dependendo da canle e da potencia, e intentamos enviar ao usuario ao que tiña o "peso" máis grande, sen prestando atención a onde se atopaba xeograficamente o usuario. Como resultado, un profesor de San Petersburgo podería comunicarse cun estudante de Siberia a través de Moscova, e non a través do noso servidor Janus en San Petersburgo.
O algoritmo foi renovado: agora, cando un usuario abre a nosa plataforma, recollemos pings del a todos os servidores que usan Ajax. Ao establecer unha conexión, seleccionamos un par de pings (profesor-servidor e alumno-servidor) coa menor cantidade. Menos ping significa menos distancia da rede ao servidor; unha distancia máis curta significa menor probabilidade de perder paquetes; A perda de paquetes é o maior factor negativo na comunicación de vídeo. A porcentaxe de negatividade caeu á metade en tres meses (para ser xustos, neste momento leváronse a cabo outros experimentos, pero este case seguramente tivo o maior impacto).
Recentemente descubrimos outra cousa non obvia, pero aparentemente importante: en lugar dun servidor Janus poderoso nunha canle grosa, é mellor ter dous máis sinxelos cun ancho de banda máis fino. Isto quedou claro despois de que compramos máquinas potentes coa esperanza de abarrotar tantas salas (sesións de comunicación) ao mesmo tempo. Os servidores teñen un límite de ancho de banda, que podemos traducir con precisión no número de salas; sabemos cantas se poden abrir, por exemplo, a 300 Mbit/s. En canto hai demasiadas salas abertas nun servidor, deixamos de elixilo para novas actividades ata que a carga diminúe. A idea era que, comprando unha máquina potente, cargaramos a canle ao máximo, para que ao final quedara limitada polo procesador e a memoria, e non polo ancho de banda. Pero resultou que despois dun certo número de salas abertas (420), a pesar de que a carga do procesador, memoria e disco aínda está moi lonxe dos límites, a negatividade comeza a chegar ao soporte técnico. Ao parecer, algo está empeorando dentro de Janus, quizais tamén hai algunhas restricións. Comezamos a experimentar, baixamos o límite de ancho de banda de 300 a 200 Mbit/s e os problemas desapareceron. Agora compramos tres novos servidores á vez con límites e características baixos, pensamos que isto levará a unha mellora estable na calidade da comunicación. Por suposto, non intentamos descubrir o que estaba a pasar alí; as nosas muletas son todo. Na nosa defensa, digamos que nese momento era necesario resolver o problema urxente o máis rápido posible, e non facelo ben; ademais, Janus para nós é unha caixa negra escrita en C, é moi caro xogar con ela.
Ben, no proceso:
- actualizou todas as dependencias que se puidesen actualizar, tanto no servidor como no cliente (estes tamén eran experimentos, monitorizamos os resultados);
- corrixiron todos os erros identificados relacionados con casos específicos, por exemplo, cando a conexión caeu e non se restauraba automaticamente;
- Mantivemos moitas xuntanzas con empresas que traballan no campo das videocomunicacións e coñecen os nosos problemas: streaming de xogos, organización de webinars; probamos todo o que nos pareceu útil;
- Realizouse unha revisión técnica do hardware e da calidade da comunicación do profesorado, de quen proviñan máis queixas.
Os experimentos e os cambios posteriores permitiron reducir a insatisfacción coa comunicación entre o profesorado do 7,1% en xaneiro de 2018 ao 2,5% en xaneiro de 2019.
Que hai a continuación
A estabilización da nosa plataforma Vimbox é un dos principais proxectos da compañía para 2019. Temos grandes esperanzas de poder manter o impulso e deixar de ver a comunicación de vídeo nas principais queixas. Entendemos que unha parte importante destas queixas están relacionadas con atrasos nos ordenadores e Internet dos usuarios, pero debemos determinar esta parte e resolver o resto. Todo o demais é un problema técnico, parece que deberíamos ser capaces de facerlle fronte.
A principal dificultade é que non sabemos ata que nivel é realmente posible mellorar a calidade. Descubrir este teito é a tarefa principal. Polo tanto, planificáronse dous experimentos:
- compara o vídeo vía Janus con p2p normal en condicións de combate. Este experimento xa foi realizado, non se atopou ningunha diferenza estatisticamente significativa entre a nosa solución e p2p;
- Proporcionemos servizos (caros) de empresas que gañan cartos exclusivamente en solucións de comunicación de vídeo e comparemos a cantidade de negatividade deles coa existente.
Estes dous experimentos permitiranos identificar un obxectivo alcanzable e centrarnos nel.
Ademais, hai unha serie de tarefas que se poden resolver habitualmente:
- Creamos unha métrica técnica de calidade da comunicación en lugar de revisións subxectivas;
- Facemos rexistros de sesións máis detallados para analizar con maior precisión os fallos que se producen, comprender cando e onde se produciron exactamente e que acontecementos aparentemente non relacionados tiveron lugar nese momento;
- Preparamos unha proba de calidade de conexión automática antes da lección e tamén damos ao cliente a oportunidade de probar manualmente a conexión para reducir a cantidade de negatividade causada polo seu hardware e canle;
- desenvolveremos e realizaremos máis probas de carga de comunicación de vídeo en malas condicións, con perda de paquetes variable, etc.;
- cambiamos o comportamento dos servidores en caso de problemas para aumentar a tolerancia a fallos;
- Avisaremos ao usuario se hai algo mal na súa conexión, como fai Skype, para que entenda que o problema está da súa parte.
Desde abril, a dirección de comunicación de vídeo converteuse nun proxecto separado completo dentro de Skyeng, que trata do seu propio produto, non só dunha parte de Vimbox. Isto significa que estamos empezando a buscar xente . Pois coma sempre .
E, por suposto, seguimos comunicándonos activamente con persoas e empresas que traballan con comunicacións de vídeo. Se queres intercambiar experiencias connosco, estaremos encantados! Comenta, ponte en contacto: responderemos a todos.
Fonte: www.habr.com