Publier et jouer
Il existe deux principales fonctionnalités WebRTC côté serveur dans le streaming vidéo: la publication et la lecture. En cas de publication, le flux vidéo est capturé à partir de la webcam et passe du navigateur au serveur. Dans le cas de la lecture, le flux se déplace dans la direction opposée - du serveur au navigateur, est décodé et lu dans l'élément de navigateur HTML5 <video> sur l'écran de l'appareil.
UDP et TCP
La vidéo peut se déplacer sur deux protocoles de transport: TCP ou UDP. Dans le cas d'UDP, les rétroactions RTCP NACK fonctionnent activement, qui transportent des informations sur les paquets perdus, et donc, déterminer la détérioration du canal UDP est une tâche assez simple et se réduit à compter NACK (Negative ACK) pour déterminer la qualité. Plus il y a de retours NACK et PLI (Picture Loss Indicator), plus les pertes sont réelles et plus la qualité du canal est mauvaise
TCP sans NACK
Dans cet article, nous nous intéresserons davantage au protocole TCP. Lors de l'utilisation de WebRTC sur TCP, les commentaires NACK RTCP ne sont pas envoyés et s'ils le sont, ils ne reflètent pas l'image réelle des pertes et il n'est pas possible de déterminer la qualité du canal par les commentaires. Comme vous le savez, TCP est un protocole de transport avec une livraison garantie. Pour cette raison, en cas de dégradation d'un canal, les paquets sur le réseau seront envoyés au niveau du protocole de transport. Tôt ou tard, ils seront livrés, mais NACK ne sera pas généré pour ces pertes, car il n'y a eu aucune perte en fait. Les colis arriveront finalement en retard. Les paquets en retard ne seront tout simplement pas collectés dans les images vidéo et seront supprimés par le dépacketizer, à la suite de quoi l'utilisateur verra quelque chose comme ça plein d'artefacts:
Sur les retours, tout ira bien, mais il y aura des artefacts dans l'image. Vous trouverez ci-dessous des captures d'écran du trafic Wireshark, qui illustrent le comportement du flux publié sur les canaux TCP et UDP pincés, ainsi que des captures d'écran des statistiques de Google Chrome. Les captures d'écran montrent que dans le cas de TCP, la métrique NACK ne se développe pas, contrairement à UDP, malgré le fait que tout va très mal avec le canal.
TCP
UDP
Et pourquoi avez-vous besoin de diffuser sur TCP s'il y a UDP
Question raisonnable. Réponse: pour pousser de grandes résolutions à travers le canal. Par exemple, lors du streaming VR (réalité virtuelle), les autorisations peuvent commencer à 4k. Il n'est pas possible de pousser un flux de cette résolution et du débit binaire d'environ 10 Mbps dans un canal normal sans perte, le serveur crache des paquets UDP et ils commencent à se perdre dans les paquets du réseau, puis envoyés, etc. Les gros vidages de paquets vidéo gâchent la vidéo et, au final, la qualité devient mauvaise. Pour cette raison, pour les réseaux à usage général et les hautes résolutions Full HD, 4k, WebRTC sur TCP est utilisé pour la livraison vidéo afin d'éliminer la perte de paquets réseau au prix d'une certaine augmentation du délai de communication.
RTT pour déterminer la qualité du canal
Ainsi, aucune métrique ne garantit que tout va mal avec le canal. Certains développeurs essaient de s'appuyer sur la métrique RTT, mais elle ne fonctionne pas sur tous les navigateurs et ne donne pas de résultats précis.
Ci-dessous, une illustration de la dépendance de la qualité de canal sur RTT selon la version du projet callstat
Solution REMB
Nous avons décidé d'aborder ce problème sous un angle légèrement différent. REMB fonctionne du côté serveur , qui calcule le débit binaire entrant pour tous les flux entrants, calcule son écart par rapport à la moyenne et, dans le cas d'une large propagation, propose au navigateur de réduire le débit binaire en envoyant des commandes REMB spéciales en utilisant le protocole RTCP. Le navigateur reçoit un tel message et réduit 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 d'entrée. Ainsi, côté serveur, un mécanisme de calcul du débit a déjà été implémenté. La détermination de la moyenne et de la diffusion est mise en œuvre via le filtre de Kalman. Cela vous permet de supprimer le débit binaire actuel à tout moment avec une grande précision et de filtrer les écarts importants.
Le lecteur aura probablement une question - «Que lui donnera la connaissance du débit binaire que le serveur voit sur le flux entrant?». Cela permettra de comprendre exactement ce que la vidéo avec le débit binaire entre sur le serveur, dont la valeur a été déterminée. Pour évaluer la qualité du canal, un composant supplémentaire est requis.
Débit sortant et pourquoi est-il important
Les statistiques du flux WebRTC de publication indiquent avec quel débit le flux vidéo quitte le navigateur. Comme dans une blague barbu: Admin, vérifiant la machine: «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 est de comparer deux débits: 1) le débit binaire que le navigateur envoie 2) le débit binaire que le serveur reçoit réellement.
L'administrateur tire des balles et calcule la vitesse de leur départ à la maison. Le serveur calcule la vitesse à laquelle ils sont reçus à domicile. Il y a un autre participant à cet événement, TCP est un super-héros qui se trouve au milieu entre l'administrateur et le serveur et peut ralentir les balles de manière aléatoire. Par exemple, il peut freiner 10 balles aléatoires sur cent pendant 2 secondes, puis leur permettre de voler à nouveau. Voici une telle matrice.
Du côté du navigateur, nous prenons le débit actuel des statistiques WebRTC, puis nous lissons le graphique avec le filtre de Kalman dans l'implémentation JavaScript et à la sortie, nous obtenons une version lissée du débit du navigateur client. Maintenant, nous avons presque tout ce dont nous avons besoin: le débit binaire du client nous indique comment le trafic quitte le navigateur, et le débit binaire du serveur indique comment le serveur voit ce trafic et quel débit il reçoit. Évidemment, si le débit binaire du client reste élevé et que le débit binaire du serveur commence à s'affaisser par rapport au client, cela signifie que toutes les «balles n'ont pas volé» et que le serveur ne voit pas réellement une partie du trafic qui lui a été envoyé. Sur cette base, nous concluons que quelque chose ne va pas avec le canal et qu'il est temps de passer l'indicateur au rouge.
Plus à venir
Les graphiques sont corrélés, mais 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 combiner les chronogrammes afin de comparer le débit binaire du client et du serveur au même point temporel sur les données historiques. La désynchronisation ressemble à ceci:
Et cela ressemble à un graphique synchronisé dans le temps.
Test
Le boitier est petit, il reste à tester. Nous publions le flux vidéo, ouvrons et regardons le planning des débits publiés: côté navigateur et côté serveur. Selon les graphiques, nous voyons une correspondance presque parfaite. L'indicateur est appelé PARFAIT.
Ensuite, nous commençons à gâcher la chaîne. Pour ce faire, vous pouvez utiliser ces outils gratuits « winShaper » sous Windows ou « Network Link Conditioner » sous MacOS. Ils vous permettent de pincer le canal à la valeur définie. Par exemple, si nous savons qu'un flux de 640x480 peut accélérer à 1Mbps, le pincer à 300 kbs. Dans le même temps, nous nous souvenons que nous travaillons avec TCP. Nous vérifions le résultat du test - les graphiques montrent une corrélation inverse et l'indicateur tombe en BAD. En effet, le navigateur continue d'envoyer des données et augmente même le débit binaire, essayant de pousser une nouvelle partie du trafic sur le réseau. Ces données se déposent sur le réseau sous forme de retransmissions et n'atteignent pas le serveur, par conséquent, le serveur montre l'image opposée et dit que le débit binaire qu'il voit est tombé. Vraiment mauvais.
Nous avons effectué de nombreux tests qui montrent le bon fonctionnement de l' indicateur . Le résultat est une fonctionnalité qui vous permet d'informer qualitativement et efficacement l'utilisateur des problèmes avec la chaîne à la fois pour la publication du flux et pour la lecture (cela fonctionne sur le même principe). Oui, pour le bien de cette ampoule PERFECT-BAD vert-rouge, nous avons clôturé tout ce jardin. Mais la pratique montre que cet indicateur est très important et que son absence et sa mauvaise compréhension de l'état actuel peuvent considérablement ruiner la vie d'un utilisateur ordinaire d'un service de streaming vidéo via WebRTC.
Les références
WCS 5.2 - un serveur multimédia pour développer des applications vidéo Web et mobiles
Documentation de contrôle qualité des canaux WebRTC pour la publication et la lecture
REMB - gestion du débit binaire côté serveur
NACK - contrôle des paquets perdus côté serveur