Quels codecs vidéo (non) les navigateurs utilisent-ils pour les appels vidéo?

Une demande de support technique typique de Voximplant: "Pourquoi un appel vidéo entre deux Chrome est-il meilleur qu'un appel vidéo entre MS Edge et une application iOS native?" Les collègues répondent généralement neutres - «parce que les codecs». Mais nous, les informaticiens, sommes curieux. Même si je ne développe pas un nouveau Skype-pour-le-Web, lire «quel type de navigateur peut» et comment ils divisent une vidéo en plusieurs flux de qualité différente enrichit l'image du monde et donne un nouveau sujet de discussion dans le fumoir. Article publié avec succès de très connu dans des cercles étroits, le Dr Alex (avec la meilleure explication du terme «moteur multimédia» de tout ce que j'ai vu), un peu de notre expérience, quelques soirées dans le «Dial» - et une traduction adaptée pour Habr attend sous la coupe!

Codecs et largeur de canal

Lorsqu'on parle de codecs vidéo, le plus souvent, ils discutent de l'équilibre entre la qualité et la largeur du canal utilisé. Et ils aiment ignorer les problèmes de charge du processeur et comment transmettre techniquement de la vidéo. Assez raisonnable si nous discutons de l'encodage d'une vidéo déjà enregistrée.

Après tout, si vous avez une vidéo terminée, il n'y a pas beaucoup de différence, elle compressera quelques minutes, quelques heures ou même quelques jours. Tous les coûts de processeur et de mémoire seront justifiés, car il s'agit d'un investissement unique, et vous pourrez ensuite distribuer la vidéo à des millions d'utilisateurs. Les meilleurs codecs vidéo compressent la vidéo en plusieurs passes:

1. Pass # 1: La vidéo est divisée en parties avec des caractéristiques communes: l'action se déroule sur le même arrière-plan, une scène rapide ou lente, etc.
2. Pass # 2: Collectez des statistiques pour le codage et des informations sur la façon dont les trames changent au fil du temps (pour obtenir ces informations, vous avez besoin de plusieurs trames).
3. Passe n ° 3: chaque partie est codée avec ses propres paramètres de codec et en utilisant les informations obtenues à la deuxième étape.

Le streaming est une question complètement différente. Personne n'attendra la fin d'un podcast, d'un flux ou d'une émission avant de commencer à encoder la vidéo. Encodez et envoyez immédiatement. Vivez dessus et dites que le délai minimum devient le plus important.

Lors de l'utilisation de supports physiques, de DVD ou de disques Blu-ray, la taille de la vidéo est fixe et le codec est confronté à la tâche d'assurer une qualité maximale pour une taille donnée. Si la vidéo est distribuée sur le réseau, la tâche du codec est de préparer ce ou ces fichiers afin d'obtenir la qualité maximale avec une largeur de canal fixe ou la largeur de canal minimale avec une qualité fixe, si vous devez réduire le prix. Dans ce cas, les retards réseau peuvent être ignorés et mis en mémoire tampon côté client pendant autant de secondes de vidéo que nécessaire. Mais pour la diffusion en continu, il n'est pas nécessaire de fixer la taille ou la qualité, le codec a une tâche différente: réduire les retards à tout prix.

Enfin, les fabricants de codecs ont longtemps gardé à l'esprit un seul cas d'utilisation: sur l'ordinateur de l'utilisateur, une et une seule vidéo est lue. Qui, de plus, peut presque toujours être décodé par les forces d'une puce vidéo. Ensuite, il y avait les plateformes mobiles. Et puis WebRTC, pour garantir la latence minimale dont les développeurs souhaitaient vraiment utiliser les serveurs de l'unité de transfert sélectif.

L'utilisation de codecs pour les appels vidéo est tellement différente de l'utilisation traditionnelle lors de la lecture de vidéos que la comparaison directe des codecs devient inutile. Lorsque VP8 et H.264 ont été comparés à l'aube de WebRTC, l'une des discussions les plus chaudes a porté sur les paramètres des codecs: les rendre «réalistes» avec des réseaux peu fiables ou «idéaux» pour une qualité vidéo maximale. Les combattants de la «comparaison de codecs propres» ont fait valoir très sérieusement que les codecs devaient être comparés sans tenir compte de la perte de paquets, de la gigue et d'autres problèmes de réseau.

Et les codecs maintenant?

• H.264 et VP8 sont approximativement les mêmes en termes de rapport de qualité vidéo et de largeur de canal utilisée;
• H.265 et VP9 correspondent également à peu près l'un à l'autre, affichant en moyenne 30% de meilleurs résultats par rapport aux codecs de la génération précédente en raison d'une augmentation de la charge du processeur de 20%;
• le nouveau codec AV1, un mélange explosif de VP10, daala et thor, est meilleur que les codecs de la génération précédente autant que ceux mieux que leurs prédécesseurs.

Et maintenant, une surprise: tout le monde ne se soucie pas de ces différences en matière d'appels vidéo et de visioconférence. La chose la plus importante est de savoir comment le codec joue en équipe avec le reste de l'infrastructure. Les développeurs sont préoccupés par ce qu'on appelle le nouveau terme moteur de médias : comment un navigateur ou une application mobile capture la vidéo, l'encode / décode, la décompose en paquets RTP et traite les problèmes de réseau (rappelez-vous la vidéo de notre précédent harast ? Article, donc les médias y ont été comparés moteur - note du traducteur). Si le codeur ne peut pas fonctionner avec une forte diminution de la largeur du canal ou maintenir de manière stable 20 images par seconde, si le décodeur ne peut pas fonctionner avec la perte d'un paquet réseau, alors quelle différence cela fait-il à quel point le codec comprime la vidéo? Il est facile de comprendre pourquoi Google sponsorise les recherches de Stanford sur la meilleure interaction entre le codec et le réseau. C'est l'avenir des communications vidéo.

Codecs et moteur multimédia: tout est compliqué

Les appels vidéo et la vidéoconférence ont presque les mêmes tâches que les médias conventionnels. Seules les priorités sont complètement différentes:

1. Il faut 30 images par seconde (vitesse du codec).
2. Besoin de 30 images par seconde avec interactivité (délai minimum).

Nous avons également Internet entre les participants, dont nous ne pouvons que deviner la qualité. C’est généralement pire. Par conséquent:

1. Vous devez bien expérimenter de petits changements dans la largeur du canal lorsqu'un autre visiteur vient au coworking.
2. Vous devez au moins ressentir des changements importants dans la largeur de la chaîne lorsque ce visiteur commence à télécharger des torrents.
3. Vous devez vous soucier de la gigue (retards aléatoires entre les paquets reçus, en raison desquels ils peuvent non seulement retarder, mais arriver dans le mauvais ordre dans lequel ils ont été envoyés).
4. Besoin de vous inquiéter de la perte de paquets.

3.1. Tâches principales du moteur multimédia

Que signifie «30 images par seconde»? Cela signifie que le moteur multimédia dispose de 33 millisecondes pour capturer la vidéo de la caméra, le son du microphone, la compresser avec un codec, la diviser en paquets RTP, protéger les données transmises (SRTP = RTP + AES) et envoyer sur le réseau (UDP ou TCP , dans la grande majorité des cas UDP). Tout cela est du côté de l'envoi. Et du côté de la réception - répétez dans l'ordre inverse. Étant donné que le codage est généralement plus difficile que le décodage, le côté émetteur a plus de mal.

Sur le plan technique, l'objectif «30 images par seconde» est réalisable avec des retards. Et plus le délai est long, plus il est facile d'atteindre l'objectif: si vous encodez du côté de l'envoi non pas plusieurs images à la fois, mais plusieurs à la fois, vous pouvez économiser considérablement sur la largeur du canal (les codecs compressent mieux plusieurs images en analysant les changements entre elles toutes, et pas seulement entre le courant et le précédent). Dans le même temps, le délai entre la réception du flux vidéo de la caméra et l'envoi sur le réseau augmente proportionnellement au nombre d'images mises en mémoire tampon, plus la compression devient plus lente en raison de calculs supplémentaires. De nombreux sites utilisent cette astuce, déclarant le temps de réponse entre l'envoi et la réception de paquets réseau entre les participants aux appels vidéo. Le retard dans l'encodage et le décodage, ils sont silencieux.

Pour que les appels vidéo ressemblent à une communication personnelle, les créateurs de services de communication refusent tous les paramètres et profils de codec qui peuvent créer des retards. Il s'avère une telle dégradation des codecs modernes en compression trame par trame. Au début, une telle situation a suscité le rejet et les critiques des développeurs de codecs. Mais les temps ont changé, et maintenant les codecs modernes en plus des préréglages traditionnels "taille minimale" et "qualité maximale" ont ajouté un ensemble de paramètres "en temps réel". Et en même temps, le «partage d'écran» est également pour les appels vidéo (il a ses spécificités - grande résolution, image légèrement changeante, besoin de compression sans perte, sinon le texte flottera).

3.2. Moteur média et réseaux publics

Petits changements dans la largeur du canal

Auparavant, les codecs ne pouvaient pas modifier le débit binaire: au début de la compression, ils prenaient le débit binaire cible comme paramètre, puis émettaient un nombre fixe de mégaoctets de vidéo par minute. À cette époque, les appels vidéo et les vidéoconférences étaient le lot des réseaux locaux et de la bande passante redondante. Et en cas de problèmes, le nom de l'administrateur a été appelé, qui a fixé la réservation de la largeur de canal sur tsiska.

Le premier changement évolutif a été la technologie du «débit adaptatif». Le codec possède de nombreux paramètres qui affectent le débit binaire: résolution vidéo, une légère diminution des fps de 30 à 25 images par seconde, quantification du signal vidéo. Le dernier de cette liste est le «grossissement» de la transition entre les couleurs, dont les légers changements sont à peine perceptibles à l'œil humain. Le plus souvent, le principal «réglage» du débit adaptatif était précisément la quantification. Et le moteur multimédia a indiqué au codec la largeur du canal.

Changements importants dans la largeur du canal

Le mécanisme adaptatif de débit binaire aide le moteur multimédia à continuer de diffuser de la vidéo avec des changements mineurs dans la largeur du canal. Mais si votre collègue a commencé à télécharger des torrents et que le canal disponible a baissé deux ou trois fois, le débit adaptatif ne vous aidera pas. Une résolution et une fréquence d'images décroissantes vous aideront. Ce dernier est préférable, car nos yeux sont moins sensibles au nombre d'images par seconde qu'à la résolution de la vidéo. En règle générale, le codec commence à sauter une ou deux images, réduisant la fréquence d'images de 30 à 15, voire à 10.

Détail important: le moteur multimédia sautera les images côté envoi. Si nous avons une vidéoconférence pour plusieurs participants ou une diffusion, et que l'expéditeur n'a pas de problème de réseau, alors un «maillon faible» aggravera la qualité vidéo pour tous les participants. Dans cette situation, un tas de simulcast aide (le côté émetteur donne plusieurs flux vidéo de qualité différente à la fois) et SFU (Selective Forwarding Unit, le serveur donne à chaque participant une vidéoconférence ou diffuse un flux de la qualité souhaitée). Certains codecs ont la capacité de créer plusieurs flux simultanés, des SVC qui se complètent: les clients avec le canal le plus faible reçoivent un flux de qualité minimale, les clients avec un meilleur canal reçoivent le même flux plus la première «mise à niveau», les clients avec un canal encore meilleur sont donnés déjà deux flux de "mise à niveau" et ainsi de suite. Cette méthode vous permet de ne pas transférer les mêmes données vers plusieurs flux et économise environ 20% du trafic par rapport au codage de plusieurs flux vidéo à part entière. Il simplifie également le fonctionnement du serveur - il n'est pas nécessaire de changer de flux, il suffit de ne pas transférer de paquets avec une «mise à niveau» vers les clients. Néanmoins, n'importe quel codec peut être utilisé pour la diffusion simultanée, c'est une caractéristique du moteur multimédia et de l'organisation des paquets RTP, pas un codec.

Gigue et perte de paquets

Les pertes sont les plus difficiles à combattre. La gigue est un peu plus simple - il suffit de créer un tampon côté réception dans lequel collecter les paquets en retard et confus. Pas un tampon trop gros, sinon vous pouvez casser en temps réel et devenir une vidéo YouTube en tampon.

La perte de paquets est généralement combattue avec la redirection (RTX). Si l'expéditeur a une bonne communication avec la SFU, le serveur peut demander un paquet perdu, le récupérer et respecter encore 33 millisecondes. Si la connexion réseau n'est pas fiable (plus de 0,01% de perte de paquets), nous avons besoin d'algorithmes de travail de perte complexes, tels que FEC .

Jusqu'à présent, la meilleure solution consiste à utiliser des codecs SVC. Dans ce cas, pour recevoir au moins une partie de la vidéo, seuls les paquets «de référence» avec un flux de qualité minimale sont nécessaires, ces paquets sont moins nombreux, il est donc plus facile de les renvoyer, cela suffit pour «survivre» même avec un réseau très pauvre (plus de 1% de perte de paquets). Si Simulcast + SFU vous permet de gérer l'affaissement de canal, Simulcast à l'aide du codec SVC + SFU résout à la fois la largeur de canal et les problèmes de paquets perdus.

Quels navigateurs prennent désormais en charge

Firefox et Safari utilisent le moteur multimédia de Google et mettent à jour libwebrtc de temps à autre. Ils le font beaucoup moins souvent que Chrome, dont une nouvelle version sort toutes les 6 semaines. De temps en temps, ils commencent à être loin derrière, puis se synchronisent à nouveau. À l'exception de la prise en charge du codec VP8 dans Safari. Ne demandez même pas.

Avant Kat, un tableau avec une comparaison complète de qui prend en charge quoi, mais en général, tout est assez simple. Edge est généralement ignoré par tout le monde. Le choix est entre le support de la version mobile de Safari et une bonne qualité vidéo. iOS Safari ne prend en charge que le codec vidéo H.264, tandis que libwebrtc autorise uniquement la diffusion simultanée avec les codecs VP8 (différents flux avec différentes fréquences d'images) et VP9 (prise en charge SVC). Mais vous pouvez lire et utiliser libwebrtc sur iOS en créant une application native. Ensuite, avec la diffusion simultanée, tout ira bien et les utilisateurs recevront la meilleure qualité vidéo possible avec une connexion Internet instable. Quelques exemples:

• Highfive - une application de bureau sur Electron (Chromium) avec diffusion simultanée H.264 (libwebrtc) et codecs sonores de Dolby;
• Attlasian - Une solution intéressante par le client sur React Native et libwebrtc pour la diffusion simultanée;
• Symphony - Electron pour le bureau, React Native pour les appareils mobiles et la diffusion simultanée sont pris en charge ici et là + des fonctionnalités de sécurité supplémentaires compatibles avec ce que veulent les banques;
• Tokbox - VP8 avec diffusion simultanée dans le SDK mobile, utilisez la version corrigée de libvpx dans libwebrtc.

Le futur

Il est déjà clair qu'il n'y aura pas de VP8 et VP9 dans Safari (contrairement à Edge, que VP8 prend en charge).

Bien qu'Apple ait soutenu l'inclusion de H.265 dans WebRTC, les nouvelles récentes et un certain nombre de signes indirects indiquent que AV1 est la «prochaine grande chose». Contrairement au reste de l'article, c'est mon opinion personnelle. La spécification pour la transmission de données AV1 est déjà prête, mais le travail est toujours en cours sur le codec. Maintenant, l'implémentation de référence de l'encodeur affiche un triste 0,3 images par seconde. Ce n'est pas un problème lors de la lecture de contenu pré-compressé, mais n'est pas encore applicable aux communications en temps réel. En attendant, vous pouvez essayer de lire des vidéos AV1 dans Firefox, bien que cela ne soit pas lié à RTC. L'implémentation est de l'équipe bitmovin, qui a développé MPEG-DASH et a reçu 30 millions d'investissements dans la création de l'infrastructure de nouvelle génération pour travailler avec la vidéo.