Publier et jouer
Il existe deux fonctions principales de fonctionnement WebRTC côté serveur dans le domaine de la diffusion vidéo en continu: la publication et la lecture. Dans le cas de la publication, le flux vidéo est capturé à partir de la caméra Web et se déplace du navigateur vers le serveur. Dans le cas de la lecture, le flux se déplace dans la direction opposée, du serveur vers le navigateur, est décodé et lu dans l'élément HTML5 <video> du navigateur sur l'écran de l'appareil.
UDP et TCP
La vidéo peut se déplacer via deux protocoles de transport: TCP ou UDP. Dans le cas d'UDP, les rétroactions NACK RTCP fonctionnent activement, transportant les informations sur les paquets perdus, en raison desquelles il est assez simple de détecter la détérioration du canal UDP, il se résume à compter le NACK (ACK négatif) pour déterminer la qualité. Plus il y a de rétroactions NACK et PLI (Picture Loss Indicator), plus il y a de pertes réelles et plus la qualité du canal est faible.
TCP sans NACK
Dans cet article, nous allons nous concentrer davantage sur le protocole TCP. Lorsque WebRTC est utilisé sur TCP, les retours NACK RTCP ne sont pas envoyés, et même s'ils sont envoyés, ils ne reflètent pas l'image réelle des pertes, et il ne semble pas possible de déterminer la qualité du canal par les retours. Comme il est communément connu, TCP est un protocole de transport avec livraison garantie. Pour cette raison, dans le cas où la qualité du canal se détériore, le reste des paquets qui se trouvent dans le réseau seront envoyés au niveau du protocole de transport. Tôt ou tard, ils seront livrés, mais aucun NACK ne sera généré pour ces pertes car en fait il n'y a pas eu de pertes. En conséquence, les paquets atteindront leur destination avec un retard. Les paquets retardés ne se rassembleront tout simplement pas dans les images vidéo et seront rejetés par le dépacketizer, à la suite de quoi l'utilisateur verra une image comme celle-ci, pleine d'artefacts:
Les retours montreront que tout va bien, mais l'image contiendra des artefacts. Ci-dessous, vous pouvez voir des captures d'écran du trafic Wireshark qui illustrent le comportement du flux publié sur les canaux TCP et UDP compressés, ainsi que des captures d'écran des statistiques de Google Chrome. Dans les captures d'écran, vous pouvez voir que dans le cas de TCP, la métrique NACK ne se développe pas contrairement à l'UDP, même si l'état du canal est très mauvais.
TCP
UDP
Pourquoi diffuser sur TCP s'il y a UDP
C'est une question raisonnable à poser. La réponse est, pour pousser de grandes résolutions à travers le canal. Par exemple, dans le cas du streaming VR (Virtual Reality), les résolutions peuvent commencer à partir de 4k. Il ne semble pas possible de pousser un flux avec une telle résolution et avec un débit d'environ 10 Mbps dans un canal normal sans pertes, le serveur crache les paquets UDP et ils commencent à se perdre dans le réseau en grappes, puis le reste d'entre eux commencent à être envoyés, etc. De grandes quantités de paquets vidéo jetés corrompent la vidéo, et le résultat net est que la qualité devient très mauvaise. C'est la raison pour laquelle WebRTC sur TCP est utilisé pour diffuser la vidéo dans des réseaux à usage général et avec des résolutions élevées, telles que Full HD et 4k, afin d'exclure les pertes de paquets réseau au détriment d'une légère augmentation de la latence de communication.
RTT pour déterminer la qualité du canal
Donc, il n'y a pas de métrique pour vous dire avec certitude que le canal est en très mauvais état. Certains développeurs essaient de s'appuyer sur la métrique RTT mais elle est loin de pouvoir fonctionner dans tous les navigateurs, et ne donne pas de résultats précis.
Ci-dessous vous pouvez trouver une illustration de la dépendance de la qualité de canal sur RTT selon le projet callstat
Solution basée sur REMB
Nous avons décidé d'adopter une approche légèrement différente de ce problème. Le REMB fonctionne du côté serveur , qui calcule le débit entrant pour tous les flux entrants, calcule son écart par rapport à la moyenne et suggère que le navigateur réduit le débit en cas de dispersion importante, en envoyant des commandes REMB spécialisées sur le RTCP protocole. Le navigateur reçoit un tel message et abaisse le débit binaire de l'encodeur vidéo pour les valeurs recommandées: c'est ainsi que fonctionne la protection contre la surcharge des canaux et la dégradation du flux entrant. De cette façon, le mécanisme de calcul du débit a déjà été implémenté côté serveur. La moyenne et la détermination de la dispersion ont été réalisées via le filtre de Kalman. Cela permet d'obtenir le débit binaire actuel à tout moment avec une grande précision et de filtrer les écarts importants.
Le lecteur aura certainement cette question: «Comment cela m'aidera-t-il à connaître le débit binaire que le serveur peut voir pour le flux entrant?» Cela vous permettra seulement de comprendre qu'il y a de la vidéo entrant dans le serveur avec un débit binaire de la valeur dont il a été possible de déterminer. Pour évaluer la qualité du canal, un composant supplémentaire sera nécessaire.
Le débit sortant et pourquoi il est important
Les statistiques du flux WebRTC de publication indiquent avec quel débit le flux vidéo sort du navigateur. Comme le dit une vieille blague, un administrateur du site dit lors de la vérification de son fusil d'assaut: «De mon côté, les balles ont volé. Les problèmes sont de votre côté ... »L'idée de vérifier la qualité du canal implique de comparer deux débits: 1) le débit envoyé par le navigateur, 2) le débit effectivement reçu par le serveur.
L'administrateur du site tire les balles et calcule la vitesse à laquelle il s'envole de son côté. Le serveur calcule la vitesse à laquelle ils sont reçus de son côté. Il y a un autre participant à cet événement, TCP, c'est un super-héros qui se trouve au milieu entre l'administrateur et le serveur et peut arrêter les balles au hasard. Par exemple, il peut arrêter 10 balles aléatoires de 100 pendant 2 secondes, puis les laisser voler à nouveau. C'est la matrice que nous voyons ici.
Côté navigateur, nous prenons le débit actuel des statistiques WebRTC, puis lissons le graphique avec le filtre de Kalman dans l'implémentation JavaScript, et obtenons une version lissée du débit du navigateur client à la fin du processus. Maintenant, nous avons pratiquement tout ce dont nous avons besoin: le débit binaire du client nous indique comment le trafic sort du navigateur, et le débit binaire du serveur nous indique comment ce trafic est vu par le serveur, et avec quel débit binaire il est reçu. Il est évident que si le débit binaire client reste élevé et que le débit binaire du serveur commence à diminuer par rapport au débit binaire client, cela signifie que toutes les puces n'ont pas «atteint la cible» et que le serveur ne peut en fait pas voir une partie du trafic. qui lui a été envoyé. Sur cette base, nous pouvons conclure que quelque chose ne va pas avec le canal et qu'il est temps de changer la couleur de l'indicateur en rouge.
Et il y a plus
Les graphiques sont corrélés mais ils sont légèrement décalés dans le temps les uns par rapport aux autres. Pour une corrélation complète, il est nécessaire de faire correspondre les graphiques dans le temps afin de comparer le débit binaire du client et du serveur au même moment avec les données historiques. La désynchronisation ressemble approximativement à ceci:
Et voici à quoi ressemble un graphique synchronisé dans le temps.
Testons-le
Il nous reste un peu à faire, il suffit de le tester. Publions un flux vidéo, ouvrons-le et regardons le graphique des débits publiés: côté navigateur et côté serveur. Les graphiques démontrent pratiquement une correspondance parfaite. Et c'est le nom de l'indicateur, PARFAIT.
Commençons ensuite à corrompre la chaîne. Pour ce faire, nous pouvons utiliser les outils gratuits suivants: winShaper pour Windows ou Network Link Conditioner pour MacOS. Ils permettent de compresser le canal à la valeur prédéfinie. Par exemple, si nous savons qu'un flux de 640x480 peut atteindre une vitesse de 1 Mbps, compressons-le à 300 kbs. Ce faisant, nous ne devons pas oublier que nous travaillons avec TCP. Vérifions le résultat de notre test: il y a une corrélation inverse dans les graphiques, et l'indicateur glisse vers BAD. En effet, le navigateur continue d'envoyer des données et augmente même le débit binaire en tentant de pousser une nouvelle partie du trafic sur le réseau. Ces données s'accumulent dans le réseau sous forme de retransmissions et ne parviennent pas au serveur, par conséquent, le serveur montre une image inverse et dit que le débit binaire qu'il peut voir a chuté. En effet, c'est MAUVAIS.
Nous avons effectué de nombreux tests qui montrent le bon fonctionnement de l' indicateur . En conséquence, nous avons une fonctionnalité qui permet d'informer l'utilisateur de manière fiable et rapide de tout problème avec le canal à la fois pour la publication et la lecture de flux (fonctionnant selon le même principe). Oui, tout ce tapage était pour cette lampe verte et rouge, PERFECT-BAD. Mais la pratique montre que cet indicateur est très important, et son absence, ainsi que l'incapacité à comprendre l'état actuel, peut créer de gros problèmes pour un utilisateur ordinaire d'un service de streaming vidéo WebRTC.
Les liens
WCS 5.2 est un serveur multimédia en continu pour le développement d'applications Web et mobiles
Contrôle de la qualité de la chaîne des éditeurs et des lecteurs
REMB - Débit maximal estimé du récepteur utilisé pour le contrôle de la bande passante
NACK - Accusé de réception négatif utilisé pour le contrôle de perte de paquets et retransmissions