Maintenant, il semble impossible de trouver un messager sans la fonction d'appel. Ceci est pratique pour les utilisateurs, car toutes les communications peuvent être effectuées dans une seule application. Si nous combinons toutes les statistiques disponibles dans les médias, il s'avère que les gens parlent sur Internet pendant plus d'un milliard de minutes par jour. Et avec le développement de la technologie, la part de la communication vidéo augmente, car la vidéo transmet mieux les émotions de l'interlocuteur et permet de créer l'effet de présence.

Un nouveau défi pour le service d'appel vidéo est de réunir à la fois toute une famille ou un groupe d'amis situés dans différentes parties du monde, ou des collègues travaillant à distance sur le même projet, pour la planification.

Le responsable du développement des plates-formes vidéo et bande, Alexander Tobol ( alatobol ), montrera que sous le capot il y a un service d'appel vidéo, quelles technologies et hacks utiliser pour créer votre serveur de conférence et comment transférer la vidéo correctement. Venez sous la coupe et apprenez comment transférer un service d'appel individuel à des appels de groupe pour 100 personnes et pourquoi avez-vous besoin de soutien pour tant de participants.


L'article est basé sur un rapport sur HighLoad ++ Siberia , dans lequel Alexander Tobol tente de donner une image complète. Si vous connaissez déjà d'autres documents sur le sujet (par exemple, sur les fonctionnalités de la transmission vidéo et des protocoles réseau ), vous pouvez ignorer la partie théorique et passer directement à la solution .

Le plan de l'article:

• Historique et appels des appareils.
• Transition des appels privés aux appels de groupe.
• Service d'appel de groupe bricolage.
• Serveur de conférence: explorez les concurrents et faites mieux.

Historique des appels

La première application bien connue pour les appels, et avec la vidéo, était Skype, elle est apparue en 2006. À Odnoklassniki, nous avons lancé des appels basés sur une solution d'Adobe en 2010-2012 ... Il y a quelques années, nous l'avons entièrement refaite sur WebRTC (plus d'informations sur ce lancement ici ), l'année dernière, nous avons ajouté des appels de groupe. Cette transition sera discutée dans l'article.

Pourquoi je pense que je peux vous dire comment faire cela? Parce que notre audience mensuelle utilisant les appels dépasse 10 millions de personnes, et nous avons plus de 2 millions d'appels par jour . De plus, plus de la moitié d'entre eux se produisent via des plateformes mobiles.

Les appels de groupe sont le service qui connaît la croissance la plus rapide, et notre objectif est de 100 participants simultanés à la conférence. Pourquoi tant? Tout d'abord, vous voulez parfois partager un beau cliché avec vos amis et camarades de classe ou organiser un séminaire. Deuxièmement, même si vous pensez que votre service n'a pas besoin de quelque chose, tout peut changer.

Maintenant, il peut sembler que les vidéoconférences pour 100 participants ne sont pas nécessaires, et il y a cinq ans, ils m'ont demandé pourquoi nous lançions la vidéo en 4K. Maintenant, un téléviseur 4K est monnaie courante, et nous étions prêts en 2014.

Le point n'est pas en avance. Si vous voulez rendre un bon service, élevez votre barre d'exigences plus haut.

Si vous pouvez faire des appels qui fonctionnent bien pour 50 à 100 personnes, alors pour 6 à 10 utilisateurs, tout fonctionnera très bien.

Chaque service d'appel comprend 4 composants relativement indépendants:

• Signalisation La tâche consiste à appeler l'abonné, à échanger les données initiales, à informer ce que chaque abonné peut faire, puis à établir un canal par lequel les données vidéo peuvent être transmises.
• Vidéo / audio. Les données vidéo et audio sont compressées à l'aide de codecs.
• Réseau. Il est nécessaire d'assurer le travail dans les mauvais réseaux, de mettre en œuvre la récupération de paquets, les connexions p2p, etc.
• Topologie - ajoutée en cas d'appels de groupe.

Vous pouvez parler de chacune de ces parties séparément. Mais je veux donner une vue d'ensemble du fonctionnement des appels, je vais donc essayer de tout mettre dans une seule histoire.

Avant de commencer à travailler sur le service, vous devez identifier les exigences :

• Établissez rapidement une connexion afin que la connexion soit établie immédiatement après que l'interlocuteur a décroché le téléphone.
• Qualité d'appel élevée pour que la vidéo ne s'effrite pas et ne gèle pas.
• Le nombre de participants à l'appel , afin que vous puissiez appeler dans des chats, dans lesquels jusqu'à 100 participants.
• Faible latence entre les appelants. Latence de 1,3 s car Polycom ne nous convient pas du tout.

Voici les significations spécifiques dans lesquelles ces exigences pour les appels de groupe sont exprimées: début d'un appel pas plus d'une seconde; un réseau dans lequel la vidéo à 300 Kbps fonctionne de manière stable; latence de l'appelant à l'auditeur pas plus de 0,5 seconde; 100 utilisateurs en un seul appel.

Qu'est-ce qui vous gêne?

Comme vous le savez, les données dans les réseaux sont transmises par paquets: il y a une socket, vous y envoyez un flux de données, tout s'envole, comme si dans une boîte noire, il collecte et fonctionne.

Mais les réseaux sont différents. La moitié des appels sont passés via des réseaux mobiles et ne ressemblent pas toujours à une autoroute.

Les réseaux peuvent être surchargés, puis les données seront perdues et elles devront être restaurées, ce qui chargera davantage le réseau. Il existe des réseaux avec lesquels tout semble être en ordre, mais les paquets disparaissent toujours - par exemple, du fait que le routeur Wi-Fi est situé derrière un mur en béton armé.

Caractéristiques réseau

Nous analyserons les principales caractéristiques qui décrivent la qualité du réseau.

RTT

Temps d'aller-retour - le temps entre l'envoi par le serveur des données au client et la réception de l'accusé de réception.

Rappelez-vous, nous voulons établir une connexion en 1 seconde. Si le temps d'aller-retour est de 200 ms, alors avec la connexion établie, par exemple, sur TCP, plus certains TLS, vous ne pouvez perdre 500 ms que lorsque la connexion est établie . Il ne restera que 500 ms, soit quelques demandes supplémentaires, après quoi la connexion doit être établie. Par conséquent, avec des demandes supplémentaires avec RTT, vous devez travailler très attentivement.

Un exemple:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

Avec RTT = 220 ms, la réception d'une réponse via https prend jusqu'à 800 ms. Par conséquent, si vous avez une connexion sécurisée de socket Web, alors avec un tel ping, la seconde entière disparaîtra.

Le tableau montre les retards de prise de contact mesurés dans les réseaux mobiles (dans ce rapport, plus de détails sur le fonctionnement des applications dans les réseaux mobiles).

Débit

Vous pouvez envoyer des paquets au réseau comme vous le souhaitez: par lots ou immédiatement tout marteler dans le tampon, ils parviendront toujours au client de manière uniforme. Le nombre de paquets ou de données par seconde est la bande passante ou la bande passante.

Le problème est que la bande passante dans les réseaux mobiles est en constante évolution . S'il a fortement chuté et que les données sont transmises avec le même débit, elles subiront évidemment des pertes et l'appel de l'utilisateur "se bloquera". Cela devra également être combattu.

Perte de paquets

Lors du transfert de données, le paquet peut être perdu. Dans ce cas, il y a un choix: soit ignorer une partie des paquets et obtenir des distorsions, soit essayer de retransmettre des paquets et obtenir un arrêt sur image.

Jitter

Le fait est que les paquets n'arrivent pas uniformément un à la fois, mais en paquets groupés à un certain intervalle.


La gigue est facile à mesurer:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

Pinganuli highload.ru plusieurs fois (le ping est une valeur instable, il faut faire la moyenne), nous avons obtenu la gigue moyenne: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .

Supposons que nous transmettions une vidéo et qu'une trame soit un paquet réseau. Plusieurs images sont jouées sans interruption, mais le troisième oiseau est retardé en raison de la gigue - nous obtenons une image figée. Donc, vous devez accumuler des packages quelque part et égaliser cet effet.

Autrement dit, pour caractériser les réseaux sans fil, il suffit de connaître les valeurs suivantes: RTT (temps aller-retour); bande passante BW (bande passante); pourcentage de perte de paquets; gigue.

À quoi ressemble l'utilisateur?

Avant de commencer à optimiser le travail avec le réseau, vous devez savoir quel type d'Internet les utilisateurs ont - peut-être que tout le monde a un réseau parfait, n'importe quelle solution fonctionnera.

Dans 80% des cas, l'utilisateur final utilise une connexion sans fil: il s'agit soit d'un réseau mobile soit du Wi-Fi.



En Russie, en dehors de la région occidentale et des grandes villes, les caractéristiques moyennes du réseau sont: RTT - 200 ms, bande passante - 1,1 Mbps, perte de paquets - 0,6%, gigue - 5 ms.

Nous avons divisé ces valeurs par types de réseaux et nous avons réalisé qu'il était nécessaire d'apprendre à travailler dessus.

Fonctions de développement d'appels

Beaucoup de gens oublient, mais le LTE et la 3G sont des canaux de communication asymétriques: la liaison descendante est toujours plus que la liaison montante. Selon le type de protocole, ce ratio peut varier de 15/85 à 30/70. Lors de la conception des appels, cela est important.

Comment vérifier le canal de vos clients?



Vous pouvez regarder speedtest, quel est le rapport de vitesse dans le monde entre Internet mobile et Internet fixe. Il s'est avéré que dans le monde entier, l'Internet fixe est également asymétrique. En Russie, heureusement, il s'est avéré être symétrique: le rapport de liaison montante / liaison descendante sur un Internet fixe via Wi-Fi en Russie est de 50/50. Nous nous concentrerons sur ces valeurs.



Conclusion: les réseaux sans fil sont populaires et instables.

• Plus de 80% des clients utilisent Internet sans fil.
• Les paramètres sans fil changent dynamiquement.
• Les réseaux sans fil ont des taux élevés de perte de paquets, de gigue et de réorganisation.
• Canal de liaison montante / liaison descendante asymétrique dans un rapport de 30/70.

Appels

Avec ce magasin de connaissances, revenons à l'implémentation des appels de groupe. Considérons un algorithme pour un appel de groupe simple, que nous affinons ensuite.

Étape 1. Alice veut appeler Boris et lui envoie une offre, dans laquelle elle rapporte tout ce qu'elle peut, qui prend en charge les protocoles, les paramètres, etc.

Étape 2. Boris répond à Alice, après quoi une connexion de transport est établie.

Étape 3. Après cela, l'échange de données audio / vidéo commence.

L'architecture de tous les appels ressemble au schéma ci-dessous.

Il y a toujours un serveur partagé, mais lorsque la connexion est établie, les utilisateurs peuvent déjà transférer des données p2p ou via des serveurs tiers.

Les données sont capturées par une caméra qui les encode sur l'appareil et les envoie à la connexion socket. Ils transitent par le réseau, sont lus de l'autre côté par le codec et affichés à l'écran.

Considérez toutes les étapes de l'algorithme en détail et essayez de passer d'appels individuels à des appels de groupe.

Signalisation

Tâche: signaler un appel et établir des connexions de données.

Tout est assez simple:

• Alice appelle, une notification est envoyée à Boris sur un appareil mobile ou un navigateur.
• Une prise Web ou toute autre connexion est établie.
• Après cela, la négociation a lieu - Alice et Boris sont d'accord.
• Lorsque le combiné est décroché sur un appareil, l'appel se termine automatiquement sur l'autre.

La plate-forme d'appel d'Odnoklassniki prend en charge divers clients et transports. Ils sont tous proches d'une sorte de serveur, qui s'occupe d'un service d'appel et de transfert de messages.

En cas de panne du serveur ou d'installation de mises à jour, il existe un stockage persistant dans lequel tous les messages sont enregistrés. En cas de perte de serveur, vous pouvez facilement passer à un autre. C'est ce que fait ZooKeeper.

La seule difficulté est exactement une fois . Nous ne voulons pas appliquer deux fois certains messages. Ce problème est résolu simplement: tous les messages ont un numéro de série - deux fois, un seul message n'arrivera pas.

De plus, vous devez être prudent lors de la création d'un appel. Une personne peut créer un appel, raccrocher et créer un autre appel. Ou il peut ne pas se bloquer, mais en créer un autre. Tous ces appels ne sont pas uniques - il n'est pas clair s'il s'agit d'un relais ou si l'utilisateur a double-cliqué sur le bouton d'appel. Il est facile à réparer: un identifiant unique est généré sur le client, et la déduplication est effectuée sur celui-ci. En principe, il n'y a pas de difficultés de signalisation .

La signalisation p2p au groupe se termine facilement.

Les mêmes offres et réponses qu'Alice envoie maintenant non seulement à Boris, mais aussi à Dima. Ils les reçoivent, d'accord, des canaux d'échange de données apparaissent entre eux.

Audio / vidéo

Afin de faire face à un appel de groupe et de comprendre quelles technologies sont nécessaires, nous devrons parler un peu de la vidéo.

La vidéo est de 24 ou 60 images par seconde. Afin de les compresser, des codecs sont utilisés. L'essence principale des codecs est que, sur quelques images, il existe une image de référence (telle que JPEG), et les images intermédiaires sont déterminées par des modifications.

Dans l'image ci-dessus, la première image avec la machine est la référence, et dans l'image suivante, seules les modifications (mouvement de la machine) sont codées, et la prochaine fois, seules les modifications sont également codées.

C'est ce qu'on appelle un groupe d'images - un ensemble indépendant de trames interconnectées qui peuvent être décodées. Le codec est un algorithme de transformation entre les trames. Plus le codec est raide, mieux il compresse les données et plus il a besoin de ressources.
À propos du ratio de débits de codec, il existe des règles générales (voir lien ).

Les codecs les plus populaires utilisés pour les appels sont H.264 et VP8 . Le H.264 est bon car il travaille partout dur et ne mange pas de batterie. Mais généralement sur les téléphones, un encodeur (encodeur) et 4 décodeurs. Pour tout le reste, vous avez besoin du logiciel VP8, qui consomme une bonne batterie. Il vaut la peine de changer la priorité en H.264 pour les appels de groupe (voir le lien sur la façon de procéder).

Le codec peut coder avec une variable (débit variable) ou un débit constant (débit constant). De nombreux codecs sur les appareils ne prennent pas en charge un débit binaire constant, vous devez donc vivre avec l'image de gauche.

Codecs audio

Il existe différents codecs hérités pour l'audio, tels que le G711. Le codec Opus est très populaire - il résout le problème d'encodage à bas et à haut débit, car à l'intérieur il contient SILK de Skype et le codec CELT pour la musique.

Il vaut la peine de dire qu'Opus dispose d'un algorithme de correction d'erreur proactive de correction d'erreur directe (FEC). Pour l'audio, cet algorithme fonctionne comme ceci: dans chaque paquet, il y a des données de haute qualité et des données des trames précédentes pendant un certain temps de faible qualité. Par conséquent, si le package précédent est perdu, vous pouvez obtenir les données du package précédent en basse qualité et les perdre en quelque sorte. En moyenne, cela se révèle plutôt bien.

Lorsque vous travaillez avec des codecs audio, il est intéressant de regarder le graphique, qui montre le rapport entre la qualité du signal d'entrée et le débit binaire.

On peut voir qu'Opus résout presque tous les problèmes. Il est intéressant de faire attention à l'AAC, qui est utilisé lors du codage vidéo dans divers services d'hébergement, et à l'ancien codec Speex, qui était utilisé exclusivement pour l'audio et fonctionne jusqu'à 32 Kbps.

Données de pathologie des médias

Afin de comprendre le fonctionnement des topologies, leurs fonctionnalités, vous devez comprendre comment un codec vidéo gère les pertes.

Dans le premier cas, rien n'a été perdu et nous voyons une bonne image. Dans la deuxième ligne, une image aléatoire est perdue - il y a de petits artefacts dans l'image. Dans le troisième cas, le cadre de référence a disparu, par conséquent, jusqu'à ce que le cadre de référence suivant, des modifications se chevauchant de manière aléatoire s'affichent.

Évidemment, la réalisation de référentiels est souvent coûteuse car le débit augmente. Par conséquent, presque tous les services d'appel prennent en charge la possibilité de demander une trame de référence en cas de perte. Dans WebRTC, cela s'appelle une trame INTRA complète.

La topologie la plus simple consiste à envoyer toutes vos vidéos à tous les autres participants à la conférence.

Nous démarrons un codec et commençons à transférer la vidéo. Alice allume la caméra, le codec, envoie sa vidéo à Boris et Dima. Mais si Dima a un mauvais Internet, Boris souffre, car vous devez réduire la qualité de la vidéo entière. Et si Dima a perdu le coup et en a demandé un de soutien, Boris l'obtiendra aussi, bien qu'il n'ait pas eu besoin de lui.

D'autre part, vous pouvez coller toutes les vidéos en un seul flux. Cela nécessitera un équipement spécial et, éventuellement, des retards supplémentaires, mais une telle solution existe également.

Transportez ou diffusez de la vidéo et de l'audio avec un délai minimal

Nous avons un choix de protocoles TCP ou UDP.
Tout le monde se souvient probablement que TCP est un protocole fiable qui, en cas de perte de paquets, les renvoie. C'est pourquoi cet ordre d'images est possible, comme dans l'image ci-dessous.

Si un paquet manque dans le paquet, vous pouvez ignorer librement l'une des 24 images de la vidéo, mais TCP ne vous permettra pas de recevoir ce qui suit jusqu'à ce que vous envoyiez celui perdu. La livraison de vidéo sur TCP est extrêmement inefficace. UDP est recommandé pour de telles tâches et tous les services d'appel l'utilisent.

Cet article fournit toutes les fonctionnalités des deux protocoles et explique pourquoi tout le streaming fonctionne sur UDP. Dans le cadre du sujet d'aujourd'hui, il nous suffit de savoir que l'UDP n'est pas disponible partout, il ne fonctionne pas dans 3% des réseaux.

En général, les utilisateurs peuvent établir des connexions P2P entre eux.

C'est le plus rentable, car si nous nous appelons à Novossibirsk, il est préférable de communiquer directement et de ne pas utiliser un serveur supplémentaire qui fournira un effet de levier.

Mais le NAT existe, et plus de 97% des utilisateurs sont maintenant situés derrière lui - peu ont des IP externes. D'une part, ce problème sera tôt ou tard résolu par IPv6. Soit dit en passant, en Russie, MTS a été le premier à le lancer. Maintenant, ils prennent entièrement en charge IPv6, et tous leurs clients ont des adresses IP blanches.

NAT peut percer, peut ne pas percer, et vous devrez alors utiliser le repli via le serveur. Il y a aussi un article sur la façon de percer le NAT.

Tampon de gigue entre le transport et les trames

Nous continuons. Maintenant, nous avons besoin d'un tampon de gigue pour niveler l'effet de la gigue

Nous commençons de façon proactive à afficher les images avec un certain retard et en attendant, nous alignons les images au même intervalle dans le tampon.

Le tampon augmente dynamiquement.

Si la trame est perdue et que l'image est figée, le tampon augmente, et nous travaillons déjà avec un tampon de cette taille.

Mais il peut y avoir une situation inverse lorsque vous devez réduire la mémoire tampon. Par exemple, le réseau s'est stabilisé et il faut gagner du temps. Si vous réduisez simplement le tampon, ce sera ridicule, les gens commenceront à parler très rapidement avec la voix d'un gnome. Par conséquent, il existe des algorithmes spéciaux qui ajustent imperceptiblement la vitesse de l'audio: supprimez les pauses entre les mots ou réduisez les sons trop longs dans la parole.

Si vous souhaitez transcoder une vidéo et corriger quelque chose, vous devez d'abord avoir un tampon de gigue, et sa latence ne sera pas inférieure à la gigue de latence de ce réseau. Autrement dit, cela augmente définitivement la latence, et nous nous souvenons que nous voulons vraiment garder dans les 0,5 s.

Expirez - la théorie est terminée!

Appels à OK

Avant les appels de groupe, nous avons eu des appels p2p, la bibliothèque WebRTC a été utilisée, des clients Web et mobiles ont été collectés, la signalisation a été écrite.

Analyse des concurrents

Lorsque vous ne savez pas quoi faire, regardez vos concurrents. Pour référence, nous avons choisi un ensemble: Skype, WhatsApp, Hangouts, ICQ, Zoom. Nous avons mesuré le nombre maximum de participants à un appel de groupe, la latence, la consommation de batterie et la qualité.

La chose la plus intéressante est de déterminer le retard. Nous procédons de cette façon: allumez la minuterie, commencez à filmer une vidéo, passez un appel.

100 ms - délai de la caméra à partir du moment où la vidéo a heurté l'objectif, avant qu'elle ne soit dessinée sur la matrice du téléphone. Après cela, la vidéo est envoyée au réseau et nous constatons déjà un retard de 310 ms dans l'appel.

N'oubliez pas de mesurer l'utilisation du processeur sur l'appareil. À partir d'iOS 12, il est devenu possible de le faire systématiquement, mais nous utilisons un pyromètre à l'ancienne.

A obtenu les résultats suivants:

WhatsApp et ICQ ont un maximum de 4 participants, Skype en a 25 (Skype Entreprise 250) et Hangouts et Zoom ont chacun 100 participants. Hangouts comptait environ 35 membres, et maintenant il est passé à la section 100+.

Le zoom a un délai légèrement plus long, mais Hangouts consomme plus de batterie. Il m'a semblé que Zoom était de meilleure qualité, mais il y a des articles qui disent le contraire - c'est une métrique subjective.

Certains services utilisent WebRTC ouvert, d'autres utilisent des protocoles propriétaires. Mais il est évident que le type de transport que vous utilisez ci-dessous n'affecte pas le nombre de participants à l'appel. Il existe des solutions avec 100 appels et avec leurs propres protocoles (Zoom), et avec WebRTC (Hangouts).

Échelle de 2 à N

Prenons un cas intéressant: il y a un client avec un canal asymétrique, entrée 3 Mbit / s, sortie 1,5 Mbit / s, perte de paquets 0,6%, gigue 50 ms. Il y a de la vidéo en HD (1280x720) avec un débit binaire de 1,5 Mbps et de la vidéo avec une résolution de 640x360 (appelons LOW) à 600 Kbps. Nous voulons transmettre des vidéos sympas.

Dans le cas où deux personnes appellent p2p, alors tout est simple. Ils ont suffisamment de réseau d'entrée, le réseau de sortie est assez serré, car le canal est asymétrique, et il n'y a pas de problème avec les codecs - tous les codecs sont gratuits.

Lorsque nous commençons à faire des appels de groupe, nous devons reconnecter tout le monde. La version la plus simple de la topologie est Mesh ou "all to all".

C'est formidable que les serveurs intermédiaires ne soient pas nécessaires, mais il devient problématique de donner à tout le monde votre vidéo pour des clients avec de telles caractéristiques. Et si le client ne peut pas distribuer la vidéo à quelqu'un seul, vous devez réduire la qualité, car le flux commun est codé pour tout le monde.

Dans ce cas, pour 5 participants, ni 3 ni 4 Mbps ne suffisent pas.

Par conséquent, dans WhatsApp dans un appel de groupe, il y a un maximum de 4 participants et ne sera plus aussi longtemps qu'ils utiliseront Mesh.

Une autre option consiste à collecter l' image entière sur le serveur . C'est le plus rentable pour le client: il a une connexion au serveur, le serveur recueille l'image, le client la récupère.

Mais supposons que nos utilisateurs de Petropavlovsk-Kamchatsky, Komsomolsk-on-Amur et Novosibirsk souhaitent discuter via un serveur de Moscou. Naturellement, cela se passera très mal. La présence de CDN aidera un peu, mais obtiendra toujours une grande quantité de tampons de gigue, ce qui au total apportera un ajout décent à la latence.

La topologie suivante - Fin du mixage - suggère de ne pas collecter une image générale sur le serveur pour éviter ces retards, mais jette simplement des paquets.

Autrement dit, le serveur de cette topologie est simplement un relais qui transfère des données.

Tout va un peu mieux: l'utilisateur reçoit les flux de tous les autres participants à l'appel et n'envoie le sien qu'une seule fois. Mais encore une fois, il y a des problèmes:

• Qualité. Tous les destinataires de votre flux ont un réseau différent. Si une personne est connectée à un Internet médiocre, alors la vidéo doit lui être livrée en basse résolution et, en conséquence, l'image ira mal pour tout le monde.
• Cadres de référence Storm . Si une personne mal connectée à Internet demande constamment un cadre de référence, alors tout le monde commence également à recevoir des oporniks. Il s'agit d'une utilisation inefficace du débit binaire, la qualité diminue à nouveau.

Si un système centralisé est utilisé , c'est-à-dire que toutes les vidéos sont collectées sur le serveur. Cela nécessite de nombreuses étapes de codage, qui ajoutent de la latence et nécessitent du matériel supplémentaire. En fin de mixage, au contraire, tout est simple et rapide.

Topologies des inconvénients:

• Mesh - maximum 4 membres.
• Centralisé - problèmes de transcodage et de gigue.
• Fin du mélange - limites de qualité et référentiels de tempête

Seuls ICQ et Skype fonctionnent sur la topologie Mesh, et tous les autres sont End mixage. Mais, comme nous nous en souvenons, tous les services sont différents en termes de caractéristiques - ce qui signifie qu'il n'y a pas seulement le mixage final, mais autre chose.

Hangouts a fait l'affaire avec le mixage de fin.

Deux encodeurs sont lancés sur chaque client: H.264 en haute qualité et VP8 en basse qualité. En conséquence, pour les utilisateurs disposant d'un bon Internet, le serveur transmet des vidéos de haute qualité, pour ceux qui ont un mauvais Internet, c'est pire, et la mauvaise qualité s'adapte au pire réseau. Deux qualités sont bonnes, mais c'est un trafic supplémentaire des clients et une consommation de batterie. Mais il n'y a pas de tampon de gigue

Le tableau montre qu'avec les Hangouts, le téléphone chauffe le plus, il présente des retards minimaux, mais la qualité en souffre, car la faible qualité ronge toujours le débit binaire élevé.

, : - , H.264, ( ) End mixing . centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• .
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

Conclusions

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .