Welche Video-Codecs (nicht) verwenden Browser für Videoanrufe?

Eine typische Anfrage des technischen Supports von Voximplant: „Warum sieht ein Videoanruf zwischen zwei Chrome besser aus als ein Videoanruf zwischen MS Edge und einer nativen iOS-Anwendung?“ Kollegen reagieren normalerweise neutral - "weil die Codecs." Aber wir IT-Leute sind neugierig. Auch wenn ich kein neues Skype-for-Web entwickle, bereichert das Lesen von „Was kann ein Browser?“ Und wie sie ein Video in mehrere Streams unterschiedlicher Qualität aufteilen, das Bild der Welt und gibt ein neues Thema zur Diskussion im Raucherraum. Erfolgreich aufgetaucht Artikel aus weithin bekannten in engen Kreisen Dr. Alex (mit der besten Erklärung des Begriffs "Media Engine" aus allem, was ich gesehen habe), ein wenig unserer Erfahrung, ein paar Abende im "Dial" - und eine für Habr angepasste Übersetzung wartet unter dem Schnitt!

Codecs und Kanalbreite

Wenn es um Video-Codecs geht, wird meistens das Gleichgewicht zwischen Qualität und Breite des verwendeten Kanals erörtert. Und sie ignorieren gerne Probleme mit der Prozessorlast und wie man Videos technisch überträgt. Ziemlich vernünftig, wenn wir über die Codierung eines bereits aufgenommenen Videos sprechen.

Wenn Sie ein fertiges Video haben, gibt es keinen großen Unterschied, es wird ein paar Minuten, ein paar Stunden oder sogar ein paar Tage komprimieren. Alle Prozessor- und Speicherkosten sind gerechtfertigt, da dies eine einmalige Investition ist und Sie das Video dann an Millionen von Benutzern verteilen können. Die besten Video-Codecs komprimieren Videos in mehreren Durchgängen:

1. Pass Nr. 1: Das Video ist in Teile mit gemeinsamen Merkmalen unterteilt: Die Aktion findet auf demselben Hintergrund, in derselben schnellen oder langsamen Szene und dergleichen statt.
2. Pass Nr. 2: Sammeln Sie Statistiken zur Codierung und Informationen darüber, wie sich Frames im Laufe der Zeit ändern (um solche Informationen zu erhalten, benötigen Sie mehrere Frames).
3. Pass Nr. 3: Jeder Teil wird mit seinen eigenen Codec-Einstellungen und unter Verwendung der im zweiten Schritt erhaltenen Informationen codiert.

Streaming ist eine ganz andere Sache. Niemand wird bis zum Ende eines Podcasts, Streams oder einer Show warten, bevor er mit der Codierung des Videos beginnt. Sofort verschlüsseln und senden. Lebe davon und lenke, dass die minimale Verzögerung am wichtigsten wird.

Bei Verwendung von physischen Medien, DVDs oder Blu-ray-Discs ist die Videogröße festgelegt und der Codec steht vor der Aufgabe, die maximale Qualität für eine bestimmte Größe sicherzustellen. Wenn das Video über das Netzwerk verteilt wird, besteht die Aufgabe des Codecs darin, solche Dateien vorzubereiten, um die maximale Qualität bei fester Kanalbreite oder die minimale Kanalbreite bei fester Qualität zu erzielen, wenn Sie den Preis senken müssen. In diesem Fall können Netzwerkverzögerungen ignoriert und auf der Clientseite für so viele Sekunden Video wie nötig gepuffert werden. Für das Streaming müssen jedoch weder Größe noch Qualität festgelegt werden. Der Codec hat eine andere Aufgabe: Verzögerungen um jeden Preis zu reduzieren.

Schließlich haben die Codec-Hersteller lange Zeit nur einen Anwendungsfall im Auge behalten: Auf dem Computer des Benutzers wird nur ein einziges Video abgespielt. Was darüber hinaus fast immer durch die Kräfte eines Videochips dekodiert werden kann. Dann gab es mobile Plattformen. Und dann WebRTC, um die minimale Latenz sicherzustellen, für die die Entwickler wirklich Server der Selective Forwarding Unit verwenden wollten.

Die Verwendung von Codecs für Videoanrufe unterscheidet sich so stark von der herkömmlichen Verwendung beim Abspielen von Videos, dass ein Vergleich von Codecs „frontal“ sinnlos wird. Beim Vergleich von VP8 und H.264 zu Beginn von WebRTC ging es in einer der heißesten Diskussionen um Codec-Einstellungen: Sie sollten mit unzuverlässigen Netzwerken „realistisch“ oder für maximale Videoqualität „ideal“ sein. Die Kämpfer für einen „sauberen Codec-Vergleich“ argumentierten ernsthaft, dass Codecs verglichen werden sollten, ohne Paketverlust, Jitter und andere Netzwerkprobleme zu berücksichtigen.

Was ist jetzt mit Codecs?

• H.264 und VP8 sind hinsichtlich des Verhältnisses von Videoqualität und verwendeter Kanalbreite ungefähr gleich;
• H.265 und VP9 entsprechen ebenfalls in etwa einander und zeigen im Durchschnitt 30% bessere Ergebnisse im Vergleich zu Codecs der vorherigen Generation, da die Prozessorlast um 20% gestiegen ist.
• Der neue AV1-Codec, eine explosive Mischung aus VP10, Daala und Thor, ist besser als die Codecs der vorherigen Generation und besser als ihre Vorgänger.

Und jetzt eine Überraschung: Diese Unterschiede sind allen egal, wenn es um Videoanrufe und Videokonferenzen geht. Das Wichtigste ist, wie der Codec in einem Team mit dem Rest der Infrastruktur spielt. Die Entwickler befassen sich mit dem so genannten neuen Begriff Media Engine : Wie erfasst ein Browser oder eine mobile Anwendung Videos, codiert / decodiert sie, zerlegt sie in RTP-Pakete und geht mit Netzwerkproblemen um (erinnern Sie sich an das Video aus unserer vorherigen Erfahrung ? Also wurden Medien dort verglichen Motor - Anmerkung des Übersetzers). Wenn der Encoder nicht mit einer starken Verringerung der Kanalbreite arbeiten oder 20 Bilder pro Sekunde stabil halten kann, wenn der Decoder nicht mit dem Verlust eines Netzwerkpakets arbeiten kann, welchen Unterschied macht es dann, wie gut der Codec das Video komprimiert? Es ist leicht zu verstehen, warum Google Stanfords Forschung zur besten Interaktion zwischen Codec und Netzwerk unterstützt. Dies ist die Zukunft der Videokommunikation.

Codecs und Media Engine: Alles ist kompliziert

Videoanrufe und Videokonferenzen haben fast die gleichen Aufgaben wie herkömmliche Medien. Nur die Prioritäten sind völlig unterschiedlich:

1. Es dauert 30 Bilder pro Sekunde (Codec-Geschwindigkeit).
2. Benötigen Sie 30 Bilder pro Sekunde mit Interaktivität (minimale Verzögerung).

Wir haben auch das Internet zwischen den Teilnehmern, dessen Qualität wir nur erraten können. Normalerweise ist es schlimmer. Deshalb:

1. Sie müssen kleine Änderungen in der Breite des Kanals erfahren, wenn ein anderer Besucher zum Coworking kommt.
2. Sie müssen zumindest irgendwie starke Änderungen in der Kanalbreite feststellen, wenn dieser Besucher mit dem Herunterladen von Torrents beginnt.
3. Sie müssen sich um Jitter sorgen (zufällige Verzögerungen zwischen empfangenen Paketen, aufgrund derer sie nicht nur verzögern können, sondern in der falschen Reihenfolge ankommen, in der sie gesendet wurden).
4. Sorgen Sie sich um Paketverlust.

3.1. Hauptaufgaben der Media Engine

Was bedeutet "30 Bilder pro Sekunde benötigen"? Dies bedeutet, dass die Media Engine 33 Millisekunden Zeit hat, um Videos von der Kamera aufzunehmen, Ton vom Mikrofon zu hören, ihn mit einem Codec zu komprimieren, ihn in RTP-Pakete aufzuteilen, die übertragenen Daten zu schützen (SRTP = RTP + AES) und über das Netzwerk (UDP oder TCP) zu senden in den allermeisten Fällen UDP). All dies ist auf der sendenden Seite. Und auf der Empfangsseite - in umgekehrter Reihenfolge wiederholen. Da das Codieren normalerweise schwieriger ist als das Decodieren, fällt es der sendenden Seite schwerer.

Auf der technischen Seite ist das Ziel „30 Bilder pro Sekunde“ mit Verzögerungen erreichbar. Und je größer die Verzögerung ist, desto einfacher ist es, das Ziel zu erreichen: Wenn Sie auf der Sendeseite nicht mehrere Frames gleichzeitig, sondern mehrere gleichzeitig codieren, können Sie die Kanalbreite erheblich einsparen (Codecs komprimieren mehrere Frames besser, indem sie nicht nur die Änderungen zwischen allen analysieren zwischen aktuell und vorher). Gleichzeitig nimmt die Verzögerung zwischen dem Empfangen des Videostreams von der Kamera und dem Senden über das Netzwerk proportional zur Anzahl der gepufferten Frames zu, und die Komprimierung wird aufgrund zusätzlicher Berechnungen langsamer. Viele Sites verwenden diesen Trick und geben die Antwortzeit zwischen dem Senden und Empfangen von Netzwerkpaketen zwischen Teilnehmern an Videoanrufen an. Die Verzögerung beim Codieren und Decodieren, sie schweigen.

Damit Videoanrufe wie persönliche Kommunikation aussehen, lehnen die Ersteller von Kommunikationsdiensten alle Einstellungen und Codec-Profile ab, die zu Verzögerungen führen können. Es stellt sich heraus, dass sich moderne Codecs zu einer Einzelbildkomprimierung verschlechtern. Eine solche Situation erregte zunächst Ablehnung und Kritik bei Codec-Entwicklern. Aber die Zeiten haben sich geändert, und jetzt haben moderne Codecs zusätzlich zu den traditionellen Voreinstellungen "minimale Größe" und "maximale Qualität" eine Reihe von "Echtzeit" -Einstellungen hinzugefügt. Gleichzeitig ist „Bildschirmfreigabe“ auch für Videoanrufe vorgesehen (es hat seine eigenen Besonderheiten - große Auflösung, sich leicht änderndes Bild, verlustfreie Komprimierung, sonst schwebt der Text).

3.2. Media Engine und öffentliche Netzwerke

Kleine Änderungen in der Kanalbreite

Bisher konnten Codecs die Bitrate nicht ändern: Zu Beginn der Komprimierung nahmen sie die Zielbitrate als Einstellung und gaben dann eine feste Anzahl von Megabyte Video pro Minute aus. In jenen alten Tagen waren Videoanrufe und Videokonferenzen die Menge lokaler Netzwerke und redundanter Bandbreite. Bei Problemen wurde der Name des Administrators genannt, der die Reservierung der Kanalbreite auf tsiska korrigierte.

Die erste evolutionäre Änderung war die Technologie der "adaptiven Bitrate". Der Codec verfügt über viele Einstellungen, die sich auf die Bitrate auswirken: Videoauflösung, leichte Verringerung der fps von 30 auf 25 Bilder pro Sekunde, Quantisierung des Videosignals. Das letzte auf dieser Liste ist die „Vergröberung“ des Übergangs zwischen Farben, deren geringfügige Änderungen für das menschliche Auge kaum wahrnehmbar sind. Meistens war die präzise Quantisierung die Hauptabstimmung für die adaptive Bitrate. Und die Media Engine teilte dem Codec die Kanalbreite mit.

Große Änderungen in der Kanalbreite

Der adaptive Bitratenmechanismus hilft der Media Engine, die Videoübertragung mit geringfügigen Änderungen der Kanalbreite fortzusetzen. Wenn Ihr Kollege jedoch mit dem Herunterladen von Torrents begonnen hat und der verfügbare Kanal zwei- oder dreimal eingetaucht ist, hilft die adaptive Bitrate nicht weiter. Das Verringern der Auflösung und der Bildrate hilft. Letzteres ist vorzuziehen, da unsere Augen weniger empfindlich auf die Anzahl der Bilder pro Sekunde als auf die Auflösung des Videos reagieren. Normalerweise überspringt der Codec ein oder zwei Frames und reduziert die Framerate von 30 auf 15 oder sogar auf 10.

Wichtiges Detail: Die Media Engine überspringt Frames auf der sendenden Seite. Wenn wir eine Videokonferenz für mehrere Teilnehmer oder eine Sendung haben und der Absender kein Netzwerkproblem hat, verschlechtert ein „schwaches Glied“ die Videoqualität für alle Teilnehmer. In dieser Situation hilft eine Reihe von Simulcasts (die Sendeseite gibt mehrere Videostreams unterschiedlicher Qualität gleichzeitig ab) und SFU (Selective Forwarding Unit, der Server gibt jedem Teilnehmer eine Videokonferenz oder sendet einen Stream der gewünschten Qualität). Einige Codecs können mehrere Simulcast-Streams erstellen, SVCs, die sich gegenseitig ergänzen: Clients mit dem schwächsten Kanal erhalten einen Stream von minimaler Qualität, Clients mit einem besseren Kanal erhalten denselben Stream plus das erste „Upgrade“, Clients mit einem noch besseren Kanal bereits zwei Streams von "Upgrade" und so weiter. Diese Methode ermöglicht es Ihnen, nicht dieselben Daten in mehrere Streams zu übertragen, und spart etwa 20% des Datenverkehrs im Vergleich zur Codierung mehrerer vollwertiger Videostreams. Es vereinfacht auch den Betrieb des Servers - es besteht keine Notwendigkeit, den Datenfluss zu wechseln, es reicht aus, keine Pakete mit einem „Upgrade“ an Clients zu übertragen. Trotzdem kann jeder Codec für Simulcasts verwendet werden. Er ist eine Funktion der Media Engine und der Organisation von RTP-Paketen, kein Codec.

Jitter und Paketverlust

Verluste sind am schwierigsten zu bewältigen. Jitter ist etwas einfacher - erstellen Sie einfach einen Puffer auf der Empfangsseite, in dem Sie verspätete und verwirrte Pakete sammeln können. Kein zu großer Puffer, sonst können Sie die Echtzeit unterbrechen und ein pufferndes YouTube-Video werden.

Paketverlust wird normalerweise mit Re-Forwarding (RTX) bekämpft. Wenn der Absender eine gute Kommunikation mit der SFU hat, kann der Server ein verlorenes Paket anfordern, es abrufen und trotzdem 33 Millisekunden einhalten. Wenn die Netzwerkverbindung unzuverlässig ist (mehr als 0,01% Paketverlust), benötigen wir komplexe Algorithmen für die Verlustarbeit, wie z. B. FEC .

Die bisher beste Lösung ist die Verwendung von SVC-Codecs. In diesem Fall werden zum Empfangen von mindestens einigen Videos nur "Referenz" -Pakete mit einem Stream von minimaler Qualität benötigt. Diese Pakete sind weniger. Daher ist es einfacher, sie erneut zu senden. Dies reicht aus, um selbst bei einem sehr schlechten Netzwerk "zu überleben" (mehr als 1% Paketverlust). Wenn Sie mit Simulcast + SFU mit Kanalsenkungen umgehen können, löst Simulcast mithilfe des SVC-Codecs + SFU sowohl die Kanalbreite als auch Probleme mit verlorenen Paketen.

Welche Browser unterstützen jetzt

Firefox und Safari verwenden die Media Engine von Google und aktualisieren libwebrtc von Zeit zu Zeit. Sie tun dies viel seltener als Chrome, dessen neue Version alle 6 Wochen veröffentlicht wird. Von Zeit zu Zeit bleiben sie weit zurück, synchronisieren sich dann aber wieder. Mit Ausnahme der Unterstützung des VP8-Codecs in Safari. Fragen Sie nicht einmal.

Vor kat eine Tabelle mit einem vollständigen Vergleich, wer was unterstützt, aber im Allgemeinen ist alles ganz einfach. Edge wird normalerweise von allen ignoriert. Sie haben die Wahl zwischen der Unterstützung der mobilen Version von Safari und einer guten Videoqualität. iOS Safari unterstützt nur H.264-Videocodec, während libwebrtc nur Simulcasting mit VP8-Codecs (verschiedene Streams mit unterschiedlichen Bildraten) und VP9 (SVC-Unterstützung) zulässt. Sie können libwebrtc jedoch unter iOS lesen und verwenden, indem Sie eine native Anwendung erstellen. Mit Simulcast ist dann alles in Ordnung und die Benutzer erhalten die höchstmögliche Videoqualität mit einer instabilen Internetverbindung. Einige Beispiele:

• Highfive - eine Desktop-Anwendung auf Electron (Chromium) mit H.264-Simulcast (libwebrtc) und Soundcodecs von Dolby;
• Attlasian - Eine interessante Lösung des Clients für React Native und libwebrtc für Simulcast;
• Symphony - Electron für den Desktop, React Native für mobile Geräte und Simulcast werden hier und da unterstützt + zusätzliche Sicherheitsfunktionen, die mit den Wünschen der Banken kompatibel sind;
• Tokbox - VP8 mit Simulcast im mobilen SDK, verwenden Sie die gepatchte Version von libvpx in libwebrtc.

Die Zukunft

Es ist bereits klar, dass es in Safari kein VP8 und VP9 geben wird (im Gegensatz zu Edge, das VP8 unterstützt).

Obwohl Apple die Aufnahme von H.265 in WebRTC unterstützte, deuten die jüngsten Nachrichten und eine Reihe indirekter Anzeichen darauf hin, dass AV1 das „nächste große Ding“ ist. Im Gegensatz zum Rest des Artikels ist dies meine persönliche Meinung. Die Spezifikation für die Datenübertragung AV1 ist bereits fertig, am Codec wird jedoch noch gearbeitet. Jetzt zeigt die Referenzimplementierung des Encoders traurige 0,3 Bilder pro Sekunde. Dies ist kein Problem beim Abspielen vorkomprimierter Inhalte, gilt jedoch noch nicht für die Echtzeitkommunikation. In der Zwischenzeit können Sie versuchen , AV1-Videos in Firefox abzuspielen, obwohl dies nicht mit RTC zusammenhängt. Implementierung durch das Bitmovin-Team, das MPEG-DASH entwickelt und 30 Millionen Investitionen in die Schaffung der Infrastruktur der nächsten Generation für die Arbeit mit Videos erhalten hat.