Alors que les premiers premiers adoptants essaient nos nouvelles vidéoconférences (jusqu'à 100 personnes!) Dans leurs projets, nous continuons à parler de choses intéressantes du monde de la transmission vocale et vidéo avec un navigateur. Nous parlerons également de visioconférence, mais plus tard - lorsqu'une masse critique d'utilisateurs s'accumule et que des statistiques intéressantes sont collectées. Et maintenant, j'ai traduit et adapté pour nous l'histoire du Dr Alex sur la place des différents protocoles lors de la transmission vidéo à faible latence. L'histoire est essentiellement une réponse à un autre article, et l'auteur, avec l'histoire, souligne les erreurs et les inexactitudes que ses collègues de l'atelier ont faites.
Données réseau: alarme séparément, vidéo séparément
Dans les systèmes modernes, si vous voyez de la vidéo dans un navigateur, le flux vidéo et l'alarme seront très probablement traités par différents serveurs. Si tout est clair avec la vidéo, le «serveur d'alarme» fournit deux choses: «découverte» et «poignée de main». La première, la «découverte», est le choix de la méthode de transfert des données: adresses IP, un serveur intermédiaire (si nécessaire). «Poignée de main» - sur la négociation entre les participants à la transmission vidéo et sonore: codecs, résolution, fréquence d'images, qualité. Fait intéressant, dans Flash ancien, la signalisation et la transmission multimédia n'étaient pas séparées comme dans VoxIP ou WebRTC et étaient fournies par un protocole: RTMP.
La différence entre le protocole de signalisation et le transport de signalisation
Le protocole de signalisation définit la langue avec laquelle le navigateur et les autres participants à la transmission vidéo se mettront d'accord sur la découverte et la prise de contact. Cela peut être SIP pour la découverte en VoIP ou WebRTC, et c'est avec une offre / réponse pour une poignée de main. Il y a longtemps, Flash utilisait
RTMP / AMF . Et si vous le souhaitez, pour WebRTC, vous pouvez utiliser non pas SIP, mais JSEP inhabituel.
Le protocole de transport de signalisation de la même pile, mais inférieur: c'est ainsi que les paquets de protocole de signalisation seront physiquement transmis. Traditionnellement, pour Flash + SIP, TCP ou UDP était utilisé, mais maintenant dans le bundle WebRTC + SIP, les WebSockets sont de plus en plus présents. Le protocole de transport WebSockets occupe la niche TCP des navigateurs où vous ne pouvez pas utiliser de sockets TCP et UDP «purs».
Une pile de signalisation complète est désormais couramment décrite avec des expressions comme «SIP au-dessus des sockets Web», «JSEP au-dessus des sockets Web», obsolète «SIP au-dessus de TCP / UDP» ou l'ancienne «partie de RTMP».
Programmeur anglicisme: Media Codec
La plupart des protocoles de streaming vidéo sont liés à un ou plusieurs codecs. La vidéo reçue de la caméra est traitée image par image. Et les problèmes de réseau, tels que la réduction de la bande passante, la perte de paquets ou le retard entre eux, sont résolus par les paramètres du codec pour chaque trame. Pour en savoir plus sur les problèmes de réseau dans le temps, nous utilisons des mécanismes de protocole de transport (RTP / RTCP) et des mécanismes d'estimation de bande passante (REMB, Transport-CC, TIMBR). L'un des problèmes fondamentaux avec la vidéo Flash était que RTMP ne pouvait pas faire non plus, donc la vidéo s'arrêtait simplement lorsque la bande passante du canal diminuait.
Un autre anglicisme: le protocole de streaming multimédia
Détermine comment diviser le flux vidéo en petits paquets qui sont envoyés sur le réseau par le protocole de transport. En règle générale, le protocole de streaming fournit toujours des mécanismes pour gérer les problèmes de réseau: perte et retard de paquets. Tampon de gigue, retransmission (RTC), redondance (RED) et correction d'erreur directe (FEC).
Protocole de transfert de média
Une fois la vidéo reçue de la caméra divisée en petits paquets, ils doivent être transmis sur le réseau. Le protocole de transport utilisé pour cela est similaire à celui de signalisation, mais comme la «charge utile» est complètement différente, certains protocoles sont meilleurs que d'autres. Par exemple, TCP fournit l'accessibilité des paquets, mais il n'ajoute pas de valeur à la pile, car des mécanismes similaires (RTX / RED / FEC) sont déjà dans le protocole de streaming. Mais les retards dans la retransmission vers TCP sont une faille évidente que UDP n'a pas. Mais il y a la pratique de bloquer UDP comme «protocole pour les torrents».
Le choix du protocole et des ports réseau était précédemment décidé par «hardcoding», mais maintenant nous utilisons des protocoles tels que ICE dans WebRTC, ce qui nous permet de nous mettre d'accord sur les ports et le transport dans chaque connexion spécifique. Dans un avenir proche, il est possible d'utiliser le protocole QUIC (rétrocompatible avec UDP), qui est activement discuté par l'IETF et présente des avantages par rapport à TCP et UDP en termes de vitesse et de fiabilité. Enfin, nous pouvons mentionner les protocoles de streaming multimédia tels que MPEG-DASH et HLS, qui utilisent HTTP comme transport et bénéficieront de l'introduction de HTTP / 2.0.
Sécurité de transmission des médias
Certains moteurs protègent les données lors de leur transmission sur le réseau: soit le flux multimédia lui-même, soit les paquets de la couche transport. Le processus comprend le transfert même de clés de chiffrement, pour lesquelles des protocoles distincts sont utilisés: SDES en VoIP et DTLS en WebRTC. Ce dernier a un avantage, car en plus des données, il protège également la transmission des clés de chiffrement.
Ce qui me dérange dans tout ça
Certains développeurs, tels que les auteurs de
cet article , placent les protocoles purement WebSocket et QUIC au même niveau que WebRTC, Flash ou HLS. Pour moi, un tel regroupement semble étrange, car les trois derniers protocoles sont une histoire de streaming multimédia. L'encodage et la mise en paquets ont lieu avant d'utiliser WebSocket ou QUIC. L'implémentation WebRTC de référence de Google (libwebrtc / chrome) et l'ORTC de Microsoft utilisent QUIC comme protocole de transport.
Tout aussi surprenant est le manque de mention de HTTP / 2.0 comme optimisation pour les protocoles basés sur HTTP tels que HLS et MPEG-DASH. Et le CMAF mentionné n'est rien de plus qu'un format de fichier pour HLS et MPEG-DASH, mais pas leur remplacement du tout.
Enfin, SRT n'est qu'un protocole de transport. Bien sûr, il ajoute un certain nombre de puces par rapport à celles basées sur les fichiers HLS et MPEG-DASH, mais toutes ces puces sont déjà à un niveau de pile différent et sont implémentées dans RTMP ou WebRTC. SRT partage également l'encodage du flux multimédia et des statistiques, ce qui ne permet pas au codec de garder ces informations aussi proches que possible les unes des autres. Une telle décision peut nuire à la capacité d'adapter la vidéo transférée à l'évolution de la bande passante du réseau.
Les protocoles basés sur des fichiers, tels que HLS, codent plusieurs flux et sélectionnent ceux nécessaires pour s'adapter à la largeur du canal. WebRTC vous permet d'adapter l'encodage de chaque trame en temps réel: c'est beaucoup plus rapide que de sélectionner un autre flux en HLS, ce qui nécessite de compter jusqu'à 10 secondes de données déjà envoyées.