La communication vidéo est le principal moyen de communication entre enseignant et élève sur la plateforme Vimbox. Nous avons abandonné Skype il y a longtemps, essayé plusieurs solutions tierces et avons finalement opté pour la combinaison WebRTC - Janus-gateway. Pendant un certain temps, nous avons été satisfaits de tout, mais certains aspects négatifs ont continué à apparaître. En conséquence, une direction vidéo distincte a été créée.
J'ai demandé à Kirill Rogovoy, chef de la nouvelle direction, de parler de l'évolution de la communication vidéo à Skyeng, des problèmes découverts, des solutions et des béquilles que nous avons finalement utilisées. Nous espérons que cet article sera utile aux entreprises qui créent également elles-mêmes des vidéos via une application Web.
Un peu d'histoire
À l'été 2017, le responsable du développement de Skyeng, Sergey Safonov, a parlé lors de la Backend Conf en racontant comment nous « avons abandonné Skype et implémenté WebRTC ». Les personnes intéressées peuvent visionner l'enregistrement du discours sur (~ 45 min), et je vais ici brièvement décrire son essence.
Pour l'école Skyeng, la communication vidéo a toujours été un moyen prioritaire de communication enseignant-élève. Au début, Skype a été utilisé, mais il n'était absolument pas satisfaisant pour plusieurs raisons, principalement dues au manque de logs et à l'impossibilité d'intégration directement dans l'application web. Nous avons donc réalisé toutes sortes d’expériences.
En fait, nos exigences en matière de communication vidéo étaient approximativement les suivantes :
- la stabilité;
— prix bas par leçon;
— enregistrer les leçons;
— suivre qui parle combien (il est important pour nous que les élèves parlent plus que l'enseignant pendant les cours) ;
— mise à l'échelle linéaire ;
- possibilité d'utiliser à la fois UDP et TCP.
La première tentative a été d’implémenter Tokbox en 2013. Tout allait bien, mais cela s'est avéré très cher - 113 roubles par leçon - et a englouti les bénéfices.
Puis en 2015, Voximplant a été intégré. Voici la fonction dont nous avions besoin pour savoir qui parlait combien, et en même temps, la solution était beaucoup moins chère : si seul l'audio était enregistré, cela coûtait 20 roubles par leçon. Cependant, cela ne fonctionnait que via UDP et ne pouvait pas passer à TCP. Cependant, environ 40 % des étudiants l’ont finalement utilisé.
Un an plus tard, nous avons commencé à avoir des entreprises clientes avec leurs propres exigences spécifiques. Par exemple, tout devrait fonctionner via un navigateur : l'entreprise n'ouvre que http et https ; c'est-à-dire pas de Skype ou d'UDP. Clients entreprises = argent, ils sont donc revenus chez Tokbox, mais le problème du prix n'a pas disparu.
Solution-WebRTC et Janus
J'ai décidé d'utiliser . Il est responsable de l’établissement d’une connexion, de l’encodage et du décodage des flux, de la synchronisation des pistes et du contrôle qualité avec la gestion des problèmes de réseau. De notre côté, nous devons assurer la lecture des flux de la caméra et du microphone, dessiner la vidéo, gérer la connexion, établir une connexion WebRTC et lui transmettre les flux, ainsi que transmettre les messages de signalisation entre clients pour établir une connexion (WebRTC lui-même décrit uniquement le format de données, mais pas son mécanisme de transfert). Si les clients sont derrière NAT, WebRTC connecte les serveurs STUN ; si cela ne résout pas le problème, les serveurs TURN.
Une connexion p2p régulière ne nous suffit pas, car nous souhaitons enregistrer les leçons pour une analyse plus approfondie en cas de réclamation. Nous envoyons donc les flux WebRTC via un relais . En conséquence, les clients ne connaissent pas les adresses des autres, ne voyant que l'adresse du serveur Janus ; il remplit également les fonctions de serveur de signaux. Janus possède de nombreuses fonctionnalités dont nous avons besoin : passe automatiquement à TCP si le client a bloqué UDP ; peut enregistrer à la fois les flux UDP et TCP ; évolutif; Il existe 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 en fonctionnement, plus un serveur supplémentaire pour le traitement des fichiers audio et vidéo bruts enregistrés, afin de ne pas occuper les processeurs des principaux. Lors de la connexion, les serveurs Janus ont été sélectionnés sur une base impaire-pair (numéro de connexion). À cette époque, cela suffisait, selon nos sentiments, cela donnait une marge de sécurité d'environ quatre fois, le pourcentage de mise en œuvre était d'environ 80. Dans le même temps, le prix a été réduit à environ 2 roubles par leçon, plus développement et support.
Revenons au sujet de la communication vidéo
Nous surveillons constamment les commentaires des étudiants et des enseignants afin d'identifier et de corriger les problèmes en temps opportun. À l’été 2018, la qualité des appels occupait la première place parmi les plaintes. D’une part, cela signifiait que nous avions réussi à surmonter d’autres lacunes. En revanche, il fallait faire quelque chose de toute urgence : si le cours d'introduction est perturbé, on risque de perdre sa valeur, parfois avec le coût d'achat du prochain forfait, et si le cours d'introduction est perturbé, on risque de perdre un client potentiel. tout à fait.
A cette époque, notre communication vidéo était encore en mode MVP. En termes simples, ils l'ont lancé, cela a fonctionné, ils l'ont mis à l'échelle une fois, ils ont compris comment le faire - eh bien, super. Si cela fonctionne, ne le réparez pas. Personne n’a délibérément abordé 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é une direction distincte pour comprendre ce qui n'allait pas avec WebRTC et Janus.
A l'entrée, cette direction a reçu : une 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 en cours
La commande ressemble à ceci :
- Le chef du département, qui est également le principal développeur.
- L'assurance qualité aide à tester les modifications, recherche de nouvelles façons de créer des conditions de communication instables et signale les problèmes depuis la première ligne.
- L'analyste recherche constamment diverses corrélations dans les données techniques, améliore l'analyse des commentaires des utilisateurs et vérifie les résultats des expériences.
- Le chef de produit contribue à l’orientation générale et à l’allocation des ressources pour les expériences.
- Un deuxième développeur aide souvent à la programmation et aux tâches associées.
Pour commencer, nous avons mis en place une métrique relativement fiable qui suivait les évolutions des évaluations de la qualité de la communication (moyenne sur jours, semaines, mois). À cette époque, il s’agissait des notes des enseignants, auxquelles ont été ajoutées ultérieurement les notes des élèves. Ensuite, ils ont commencé à formuler des hypothèses sur ce qui ne fonctionnait pas bien, à les corriger et à examiner les changements de dynamique. Nous avons opté pour le fruit le plus simple : par exemple, nous avons remplacé le codec vp8 par vp9, les performances se sont améliorées. Nous avons essayé de jouer avec les paramètres de Janus et de mener d'autres expériences - dans la plupart des cas, elles n'ont abouti à rien.
Lors de la deuxième étape, une hypothèse a émergé : WebRTC est une solution peer-to-peer, et nous utilisons un serveur au milieu. Peut-être que le problème réside ici ? Nous avons commencé à creuser et avons trouvé l’amélioration la plus significative jusqu’à présent.
A ce moment-là, un serveur du pool était sélectionné à l'aide d'un algorithme assez stupide : chacun avait son propre « poids », en fonction du canal et de la puissance, et on essayait d'envoyer l'utilisateur vers celui avec le plus gros « poids », sans en prêtant attention à l'endroit où se trouvait géographiquement l'utilisateur. En conséquence, un enseignant de Saint-Pétersbourg pourrait communiquer avec un étudiant de Sibérie via Moscou et non via notre serveur Janus à Saint-Pétersbourg.
L'algorithme a été refait : désormais, lorsqu'un utilisateur ouvre notre plateforme, nous collectons des pings de sa part vers tous les serveurs utilisant Ajax. Lors de l'établissement d'une connexion, nous sélectionnons une paire de pings (enseignant-serveur et étudiant-serveur) avec le plus petit montant. Moins de ping signifie moins de distance réseau avec le serveur ; une distance plus courte signifie une probabilité plus faible de perdre des paquets ; La perte de paquets est le facteur négatif le plus important dans la communication vidéo. La part de négativité a diminué de moitié en trois mois (pour être honnête, d’autres expériences ont été menées à cette époque, mais celle-ci a certainement eu le plus d’impact).
Nous avons récemment découvert une autre chose non évidente, mais apparemment importante : au lieu d’un serveur Janus puissant sur un canal épais, il vaut mieux en avoir deux plus simples avec une bande passante plus fine. Cela est devenu clair après que nous avons acheté des machines puissantes dans l’espoir d’y intégrer autant de salles (sessions de communication) 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 peuvent être ouvertes, par exemple à 300 Mbit/s. Dès qu’il y a trop de salles ouvertes sur un serveur, on arrête de le choisir pour de nouvelles activités jusqu’à ce que la charge diminue. L'idée était qu'après avoir acheté une machine puissante, nous chargerions le canal au maximum, de sorte qu'à la fin, il serait limité par le processeur et la mémoire, et non par 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, le négatif commence à arriver au support technique. Apparemment, quelque chose empire à l'intérieur de Janus, peut-être qu'il y a aussi des restrictions là-bas. Nous avons commencé à expérimenter, abaissé la limite de bande passante de 300 à 200 Mbit/s et les problèmes ont disparu. Maintenant que nous avons acheté trois nouveaux serveurs à la fois avec des limites et des caractéristiques faibles, nous pensons que cela entraînera une amélioration stable de la qualité de la communication. Bien sûr, nous n’avons pas cherché à comprendre ce qui se passait là-bas : nos béquilles sont tout. Pour notre défense, disons qu’à ce moment-là il fallait résoudre le problème urgent le plus rapidement possible, et non pas le faire en beauté ; en plus, Janus est pour nous une boîte noire écrite en C, ça coûte très cher de la bricoler.
Eh bien, dans le processus, nous :
- mis à jour toutes les dépendances pouvant être mises à jour, aussi bien sur le serveur que sur le client (c'étaient aussi des expérimentations, nous avons surveillé les résultats) ;
- correction de tous les bugs identifiés liés à des cas spécifiques, par exemple lorsque la connexion était interrompue et n'était pas restaurée automatiquement ;
- Nous avons eu de nombreuses réunions avec des entreprises travaillant dans le domaine des communications vidéo et connaissant nos problématiques : streaming de jeux, organisation de webinaires ; nous avons essayé tout ce qui nous semblait utile ;
- Réalisation d'un examen technique du matériel informatique et de la qualité de la communication des enseignants, d'où proviennent le plus grand nombre de plaintes.
Les expérimentations et les évolutions ultérieures ont permis de réduire l'insatisfaction à l'égard de la communication des enseignants de 7,1% en janvier 2018 à 2,5% en janvier 2019.
Quelle est la prochaine
La stabilisation de notre plateforme Vimbox est l'un des principaux projets de l'entreprise pour 2019. Nous avons bon espoir de pouvoir maintenir cette dynamique et de ne plus voir la communication vidéo parmi les principales plaintes. Nous comprenons qu'une partie importante de ces plaintes est liée aux retards des ordinateurs et d'Internet des utilisateurs, mais nous devons déterminer cette partie et résoudre 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 réellement possible d’améliorer la qualité. Trouver ce plafond est la tâche principale. Deux expériences étaient donc prévues :
- comparez la vidéo via Janus avec le p2p classique dans des conditions de combat. Cette expérience a déjà été réalisée, aucune différence statistiquement significative n'a été trouvée entre notre solution et p2p ;
- Fournissons des services (coûteux) d'entreprises qui gagnent de l'argent exclusivement grâce aux solutions de communication vidéo et comparons la quantité de négativité de leur part avec celle existante.
Ces deux expériences permettront d’identifier un objectif réalisable et de se concentrer dessus.
De plus, un certain nombre de tâches peuvent être résolues de manière routinière :
- Nous créons une mesure technique de la qualité de la communication au lieu d'évaluations subjectives ;
- Nous réalisons des journaux de session plus détaillés afin d'analyser plus précisément les pannes qui se produisent, de comprendre quand et où exactement elles se sont produites, et quels événements apparemment sans rapport se sont produits à ce moment-là ;
- Nous préparons un test automatique de qualité de connexion avant le cours, et donnons également au client la possibilité de tester manuellement la connexion afin de réduire la quantité de négativité causée par son matériel et son canal ;
- nous développerons et réaliserons davantage de tests de charge de communication vidéo dans de mauvaises conditions, avec des pertes de paquets variables, etc. ;
- nous modifions le comportement des serveurs en cas de problèmes pour augmenter la tolérance aux pannes ;
- Nous avertirons l'utilisateur s'il y a un problème avec sa 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, traitant de son propre produit, et non seulement d'une partie de Vimbox. Cela signifie que nous commençons à rechercher des personnes sur . Eh bien, comme toujours .
Et bien sûr, nous continuons à communiquer activement avec les personnes et les entreprises travaillant dans le domaine des communications vidéo. Si vous souhaitez échanger vos expériences avec nous, nous serons ravis ! Commentez, contactez-nous, nous répondrons à tout le monde.
Source: habr.com