Les appels vidéo sont le principal moyen de communication des enseignants et des étudiants sur la plate-forme Vimbox. Nous avons abandonné Skype il y a longtemps, essayé plusieurs solutions tierces et finalement opté pour un tas de WebRTC - Janus-gateway. Pendant un certain temps, tout allait bien pour nous, mais certains points négatifs ont continué de se répandre. En conséquence, une direction vidéo distincte a été créée.
J'ai demandé à Kirill Rogovoy, le chef de la nouvelle direction, de parler de l'évolution des communications vidéo à Skyeng, des problèmes, des solutions et des béquilles que nous avons finalement appliqués. Nous espérons que cet article sera utile aux entreprises qui réalisent elles-mêmes des vidéos via une application Web.
Un peu d'histoire
À l'été 2017, Sergey Safonov, le responsable du développement de Skyeng, a expliqué à Backend Conf comment nous avons «abandonné Skype et mis en œuvre WebRTC». Ceux qui le souhaitent peuvent voir l'enregistrement de la performance par référence (~ 45 min), mais ici je vais brièvement décrire son essence.
Pour Skyeng, la communication vidéo a toujours été une méthode de communication prioritaire enseignant-élève. Au début, Skype était utilisé, mais il ne convenait absolument pas pour un certain nombre de raisons, principalement en raison du manque de journaux et de l'impossibilité de s'intégrer directement dans l'application Web. Par conséquent, nous avons mené toutes sortes d'expériences.
En fait, les exigences pour la communication vidéo étaient approximativement les suivantes:
- stabilité;
- petit prix par leçon;
- enregistrement des leçons;
- suivre qui dit combien (il est important pour nous que les élèves parlent plus en classe que l'enseignant);
- mise à l'échelle linéaire;
- La possibilité d'utiliser à la fois UDP et TCP.
Le premier en 2013 a essayé de mettre en œuvre Tokbox. Tout allait bien, mais cela s'est avéré très cher - 113 roubles par leçon - et a mangé le profit.
Puis en 2015, Voximplant a été intégré. Voici la fonction de suivi dont nous avions besoin, qui dit combien, et en même temps, la solution était beaucoup moins chère: à condition que seul le son soit enregistré, 20 roubles par leçon sortaient. Cependant, cela ne fonctionnait que via UDP; le passage à TCP n'était pas une compétence. Cependant, au final, environ 40% des étudiants l'ont utilisé.
Un an plus tard, les entreprises clientes ont commencé à apparaître avec leurs besoins spécifiques. Par exemple, tout devrait fonctionner via un navigateur, seuls http et https sont ouverts dans l'entreprise; c'est-à-dire, pas de Skype et UDP. Les clients professionnels = argent, ils sont donc revenus sur Tokbox, mais le problème de prix n'a pas disparu.
Solution - WebRTC et Janus
Nous avons décidé d'utiliser la plate-forme de navigateur pour les communications vidéo peer-to-peer WebRTC . Elle est responsable de l'établissement des connexions, du codage et du décodage des flux, de la synchronisation des pistes et du contrôle qualité avec le traitement des problèmes de réseau. Pour notre part, nous devons nous assurer que les flux de la caméra et du microphone sont lus, la vidéo est dessinée, la connexion est établie, la connexion WebRTC est établie et les flux lui sont transmis, ainsi que la transmission de messages de signal entre les clients pour établir la connexion (WebRTC lui-même ne décrit que le format des données, mais pas leur mécanisme transmission). Dans le cas où les clients sont derrière NAT, WebRTC connecte les serveurs STUN, si cela n'aide pas, les serveurs TURN.
La connexion p2p habituelle ne nous suffit pas, car nous voulons enregistrer des leçons pour une analyse plus approfondie en cas de réclamation. Par conséquent, nous envoyons des flux WebRTC via le répéteur Janus Gateway de Meetecho . Par conséquent, les clients ne connaissent pas les adresses des autres, ne voyant que l'adresse du serveur Janus; il remplit également les fonctions d'un serveur de signaux. Janus a de nombreuses fonctionnalités dont nous avons besoin: il passe automatiquement à TCP si UDP est bloqué sur le client; capable d'enregistrer des flux à la fois UDP et TCP; évolutif; il y a même un plugin intégré pour les tests d'écho. Si nécessaire, les serveurs STUN et TURN de Twilio sont automatiquement connectés.
À l'été 2017, nous avions deux serveurs Janus, plus un serveur supplémentaire pour le traitement des fichiers audio et vidéo bruts enregistrés, afin de ne pas occuper les principaux processeurs. Lors de la connexion, les serveurs Janus ont été sélectionnés sur une base paire / impaire (numéro de connexion). À l'époque, cela suffisait, selon nos sentiments, cela donnait environ quatre fois la marge de sécurité, le pourcentage de mise en œuvre était d'environ 80. Dans le même temps, le prix est tombé à environ 2 roubles par leçon, plus le développement et le support.
Revenir au sujet des appels vidéo
Nous surveillons constamment les commentaires des étudiants et des enseignants afin d'identifier et de résoudre les problèmes à temps. À l'été 2018, en premier lieu parmi les plaintes, la qualité de la communication était solidement ancrée. D'une part, cela signifiait que nous avions réussi à surmonter d'autres lacunes. D'un autre côté, il y avait un besoin urgent de faire quelque chose: si la leçon est interrompue, nous risquons de perdre son coût, parfois avec le coût d'achat du package suivant, et si la leçon d'introduction est perdue, nous perdons complètement le client potentiel.
À cette époque, la communication vidéo était toujours en mode MVP. Autrement dit, ils l'ont lancé, cela a fonctionné, mis à l'échelle une fois, compris comment le faire - eh bien, c'est bien. Si cela fonctionne, ne le réparez pas. Personne n'a délibérément traité la question de la qualité de la communication. En août, il est devenu clair que cela ne pouvait pas continuer, et nous avons lancé un espace séparé pour comprendre ce qui se passait avec WebRTC et Janus.
A l'entrée, cette direction a reçu: solution MVP, pas de métriques, pas d'objectifs, pas de processus d'amélioration, alors que 7% des enseignants se plaignent de la qualité de la communication (il n'y avait pas non plus de données sur les élèves).
Une nouvelle direction est prise pour le travail
La commande ressemble à ceci:
- A la tête de la direction, il en est le principal développeur.
- Le contrôle qualité aide à tester les changements, à rechercher de nouvelles façons de créer des conditions de communication instables, à signaler les problèmes en première ligne.
- L'analyste recherche en permanence différentes corrélations dans les données techniques, améliore l'analyse des retours utilisateurs, vérifie les résultats des expériences.
- Le chef de produit aide à la direction générale et à l'allocation des ressources pour les expériences.
- Avec la programmation elle-même et les tâches connexes, un deuxième développeur aide souvent.
Pour commencer, nous avons mis en place une métrique relativement fiable qui suit les changements dans l'évaluation de la qualité de la communication (moyenne par jours, semaines, mois). À cette époque, il s'agissait de notes des enseignants et d'autres notes des étudiants leur étaient ajoutées. Puis ils ont commencé à construire des hypothèses de ce qui ne fonctionne pas, à corriger et à regarder les changements de dynamique. Nous avons opté pour des fruits bas: par exemple, nous avons remplacé le codec vp8 par vp9, les performances ont été améliorées. Nous avons essayé de jouer avec les paramètres de Janus, de mener d'autres expériences - dans la plupart des cas, en vain.
À la deuxième étape, une hypothèse est apparue: WebRTC est une solution peer-to-peer, et nous utilisons le serveur au milieu. Peut-être que le problème réside ici? Ils ont commencé à creuser et ont trouvé ici l'amélioration la plus significative à ce jour.
À ce moment, le serveur de la piscine a été sélectionné selon un algorithme plutôt stupide: chacun avait son propre "poids", en fonction du canal et de la puissance, et nous avons essayé d'envoyer l'utilisateur à celui où le "poids" est plus important, sans prêter attention à l'emplacement géographique de l'utilisateur. . En conséquence, un enseignant de Saint-Pétersbourg pouvait communiquer avec un élève de Sibérie via Moscou, et non via notre serveur Janus à Saint-Pétersbourg.
L'algorithme a été refait: maintenant, lorsque l'utilisateur ouvre notre plateforme, nous utilisons Ajax pour en collecter des pings sur tous les serveurs. Lors de l'établissement d'une connexion, nous sélectionnons une paire de pings (enseignant-serveur et élève-serveur) avec le plus petit montant. Moins de ping - moins de distance du réseau au serveur; moins de distance - moins de chances de perdre des paquets; la perte de paquets est le principal facteur négatif des appels vidéo. La part de négativité a chuté deux fois en trois mois (pour être honnête, d'autres expériences ont également été menées à cette époque, mais celle-ci a presque certainement touché le plus).
Récemment, nous avons découvert une autre chose non évidente, mais apparemment importante: au lieu d'un serveur Janus puissant sur un canal épais, deux sont plus simples avec une bande passante meilleure. Cela s'est avéré après que nous ayons acheté des machines puissantes dans l'espoir d'y remplir autant de pièces (sessions de communication) que possible en même temps. Les serveurs ont une limite de bande passante que nous pouvons traduire avec précision en nombre de salles - nous savons combien vous pouvez ouvrir, par exemple, à 300 Mbps. Dès que trop de salles sont ouvertes sur le serveur, nous arrêtons de le choisir pour de nouvelles activités jusqu'à ce que la charge diminue. L'idée était que, après avoir acheté une machine puissante, nous lui chargerons le canal au maximum pour qu'à la fin il repose sur le processeur et la mémoire, et non sur la bande passante. Mais il s'est avéré qu'après un certain nombre de salles ouvertes (420), malgré le fait que la charge sur le processeur, la mémoire et le disque soit encore très loin des limites, la négativité commence à voler dans le support technique. Apparemment, quelque chose empire à l'intérieur de Janus, il y a peut-être aussi des restrictions. Ils ont commencé à expérimenter, réduit la limite de bande passante de 300 à 200 Mbps, les problèmes avaient disparu. Maintenant que nous avons acheté trois nouveaux serveurs à la fois avec des limites et des caractéristiques basses, nous pensons que cela conduira à une amélioration stable de la qualité de la communication. Bien sûr, nous n'avons pas commencé à comprendre quel était le problème, les béquilles étaient à nous. Pour notre défense, nous disons qu'à ce moment-là, il était nécessaire de résoudre le problème urgent le plus rapidement possible, et non de le faire magnifiquement; De plus, Janus est pour nous une boîte noire, écrite en C, ça coûte très cher de creuser dedans.
Eh bien, dans le processus, nous:
- mis à jour toutes les dépendances qui pouvaient être mises à jour, à la fois sur le serveur et sur le client (il s'agissait également d'expériences, suivi du résultat);
- correction de tous les bogues identifiés liés à des cas spécifiques, par exemple, lorsque la connexion est tombée et n'a pas été restaurée automatiquement;
- eu de nombreuses rencontres avec des entreprises travaillant dans le domaine des communications vidéo et familières avec nos problèmes: jeux en streaming, webinaires hôtes; testé tout ce qui nous semblait utile;
- a effectué un examen technique du fer et de la qualité de la communication avec les enseignants, d'où proviennent le plus de plaintes.
Les expériences et les changements ultérieurs ont permis de réduire l'insatisfaction à l'égard de la communication entre les enseignants de 7,1% en janvier 2018 à 2,5% en janvier 2019.
Et ensuite
La stabilisation de notre plateforme Vimbox est l'un des principaux projets de l'entreprise pour 2019. Nous espérons vivement que nous pourrons maintenir l'élan et ne plus voir la communication vidéo dans les principales plaintes. Nous comprenons qu'une partie importante de ces plaintes est liée aux retards des ordinateurs et à l'Internet des utilisateurs, mais nous devons déterminer cette partie et résoudre tout le reste. Tout le reste est un problème technique, il semble que nous devrions pouvoir y faire face.
La principale difficulté est que nous ne savons pas à quel niveau il est généralement réaliste d'améliorer la qualité. La clarification de ce plafond est la tâche principale. Par conséquent, deux expériences étaient prévues:
- Comparez la vidéo via Janus avec le P2P normal en combat. Cette expérience a déjà été réalisée, aucune différence statistiquement significative entre notre solution et p2p n'a été trouvée;
- nous fournirons des services (coûteux) à des entreprises qui gagnent exclusivement sur des solutions de communication vidéo, et comparerons le montant de leurs négatifs avec celui existant.
Ces deux expériences nous permettront de déterminer un objectif réalisable et de nous concentrer sur lui.
De plus, un certain nombre de tâches sont résolues dans l'ordre de travail:
- nous créons une métrique technique de la qualité de la communication au lieu d'examens subjectifs;
- nous faisons des journaux de session plus détaillés afin d'analyser plus précisément les dysfonctionnements qui se produisent, de comprendre quand et où exactement ils se sont produits, quels événements apparemment sans rapport ont eu lieu à ce moment;
- nous préparons un test automatique de la qualité de la communication avant le cours, et nous allons également permettre au client de tester manuellement la connexion afin de réduire la quantité de négatif causée par son fer et son canal;
- Nous développerons et réaliserons plus de tests de résistance des communications vidéo dans de mauvaises conditions, avec une perte de paquets variable, etc.;
- Nous modifions le comportement des serveurs en cas de problème pour augmenter la tolérance aux pannes;
- nous avertirons l'utilisateur s'il a un problème avec la connexion, comme le fait Skype, afin qu'il comprenne que le problème est de son côté.
Depuis avril, la direction de la communication vidéo est devenue un projet distinct à part entière au sein de Skyeng, engagé dans son propre produit, pas seulement une partie de Vimbox. Et cela signifie que nous commençons à chercher des personnes pour travailler avec la vidéo en mode plein temps . Eh bien, comme toujours, nous recherchons beaucoup de bonnes personnes .
Eh bien, bien sûr, nous continuons à communiquer activement avec les personnes et les entreprises travaillant avec les communications vidéo. Si vous souhaitez échanger avec nous, nous serons heureux! Commentaire, contact - nous répondrons à tout le monde.