• Die Einführung von AV1 für die Echtzeitkommunikation bei Meta war eine mehrjährige Anstrengung, die sich über die Auswahl des Codecs erstreckte, Geräteberechtigung, Geschwindigkeitskontrolle, und Fehlerresilienz.
• Wir teilen die technischen und betrieblichen Herausforderungen bei der Bereitstellung von AV1 und der Ausweitung der Abdeckung, und wie wir sie für die Echtzeitkommunikation angesprochen haben.
• Wir stellen verschiedene Technologien zur Verbesserung der AV1-Anrufqualität vor, einschließlich Ratenkontrolle und Fehlerresistenz.

Der AV1-Videocodec, erstmals von AOMedia standardisiert 2018, hat sich schnell weiterentwickelt und breite Unterstützung in der Industrie gefunden. Heute, führende Unternehmen wie YouTube, Netflix, und Meta-Stream-Video mit AV1 im großen Maßstab. Meta führte AV1 für Echtzeit-Videoanrufe auf High-End-Geräten ein 2023, Ziel ist es, eine überragende Anrufqualität zu liefern. Seitdem, Wir haben bemerkenswerte Fortschritte bei der Erweiterung der Reichweite von AV1 und der Verbesserung des Erlebnisses bei AV1-gestützten Anrufen gemacht. Heute, AV1 ist auf den meisten Mobilgeräten in der Meta-Echtzeitkommunikation aktiviert (RTC) Anwendungen wie Messenger und WhatsApp.

Warum ist Meta daran interessiert, AV1 für RTC einzuführen??

Die Motivation für den Wechsel zu einem fortschrittlicheren Video-Codec ist einfach: Er liefert die gleiche visuelle Qualität, verbraucht aber viel weniger Bandbreite. In Offline-Tests, Wir haben mindestens a beobachtet 20% Bitratenreduzierung mit AV1 im Vergleich zu H.264/AVC unter unseren Produkteinstellungen auf Geräten der unteren und mittleren Preisklasse. Wenn Geräte eine höhere Kodierungskomplexität bewältigen können, die Bitratenreduzierungen sind sogar noch größer. Für Echtzeit-Videoanrufe, Dies bedeutet, dass Menschen in langsameren oder eingeschränkten Netzwerken eine deutlich bessere Videoqualität genießen können. Dies ist für unsere Benutzer wichtig, weil, um Anforderungen an niedrige Latenzzeiten zu erfüllen, Das RTC-Produkt muss mit Bitratenschwankungen umgehen. In realen Netzwerken – insbesondere in Schwellenländern – liegen die Videobitraten für RTC-Produkte typischerweise zwischen 10 kbps zu 400 kbit/s. Behalten Sie unten die gute Videoqualität bei 100 kbps bleibt eine Herausforderung.

Um die Benutzererfahrung über Codecs hinweg zu bewerten, Wir haben AV1 in der Messenger-App aktiviert und einen direkten Vergleich mit zwei Android-Telefonen durchgeführt. In den Beispielen unten, Rechts wird AV1 und links H.264/AVC angezeigt, beides beschränkt auf 100 kbit/s. Das H.264/AVC-Video erscheint deutlich verschwommen, während das AV1-Video viel klarer bleibt – was den erheblichen Vorteil von AV1 für Videoanrufe unter Bandbreitenbeschränkungen unterstreicht.

Ein verstärkter Fokus auf Bildschirminhalte, benötigt Unterstützung durch hochwertige computergenerierte Inhaltskodierung. Traditionell, Video-Encoder eignen sich nicht so gut für komplexe Inhalte wie Texte mit vielen hochfrequenten Inhalten, und Menschen reagieren sehr empfindlich auf das Lesen von verschwommenem Text. AV1 verfügt über eine Reihe von Codierungstools – Palettenmodus und Intra-Block-Kopie –, die die Leistung für Bildschirminhalte drastisch verbessern.

Der Palettenmodus basiert auf der Beobachtung, dass sich die Pixelwerte in einem Bildschirminhaltsrahmen normalerweise auf die begrenzte Anzahl von Farbwerten konzentrieren. Es kann den Bildschirminhalt effizient darstellen, indem es die Farbcluster anstelle der quantisierten Transformationsbereichskoeffizienten signalisiert. Zusätzlich, für typische Bildschirminhalte, Wiederkehrende Muster sind normalerweise innerhalb desselben Bildes zu finden. Das Kopieren innerhalb eines Blocks erleichtert die Blockvorhersage innerhalb desselben Frames, so dass die Kompressionseffizienz deutlich verbessert werden kann. AV1 hat den Vorteil, dass diese beiden Tools im Hauptprofil bereitgestellt werden.

Die Herausforderungen bei der Einführung von AV1

Der Vergleich verdeutlicht zwar deutlich die Vorteile von AV1, Es gibt erhebliche Herausforderungen bei der Einführung in RTC. Im Gegensatz zu Video-on-Demand (VOD), RTC-Systeme müssen die End-to-End-Videolatenz verwalten, die idealerweise darunter bleiben sollte 300 Millisekunden. Wenn die Latenz diesen Schwellenwert überschreitet, Die Leute beginnen, Verzögerungen im Gespräch zu bemerken.

Es ist eine Herausforderung, sowohl eine hohe Videoqualität als auch eine niedrige Latenz aufrechtzuerhalten. Zum Beispiel, Multi-Pass-Codierungstechniken – die die Qualität verbessern können – führen zu zusätzlicher Verzögerung. Auf der Decoderseite, Umfangreiche Pufferung erhöht die Latenz zusätzlich. Zusätzlich, Plötzliche Bitratenspitzen können dazu führen, dass das Video während eines Anrufs einfriert, Verschlechterung der Benutzererfahrung.

RTC-Produkte müssen sich außerdem während eines Anrufs dynamisch an die Netzwerkbedingungen anpassen. Zwei Herausforderungen sind Schwankungen der Netzwerkbandbreite und Paketverluste. Um mit Bandbreitenänderungen zurechtzukommen, Der Video-Encoder passt Parameter wie Auflösung und Bildrate an. Jedoch, Das Wechseln der Auflösung erfordert normalerweise einen neuen Schlüsselrahmen, Dies kann zu einem plötzlichen Anstieg der Bitrate und einem vorübergehenden Einfrieren des Videos führen. Ähnlich, Paketverlust kann Neuübertragungen auslösen oder den Encoder zwingen, einen weiteren Schlüsselrahmen zu senden, Beides kann zum Einfrieren des Videos führen. Die effektive Bewältigung dieser Probleme trägt dazu bei, eine qualitativ hochwertige Lieferung zu ermöglichen, ununterbrochene Videoanrufe.

Zusätzlich, Der RTC-Client muss sowohl Echtzeit-Kodierung als auch -Dekodierung durchführen, Beide verbrauchen viel Strom – daher ist die Energieeffizienz wichtig, insbesondere auf mobilen Geräten.

Encoder- und Decoderauswahl

Die Auswahl des richtigen Encoders und Decoders ist der wichtigste Schritt bei der Einführung eines neuen Codecs. Die Rechenkomplexität von Video-Codecs ist ein wichtiger Gesichtspunkt für mobile Geräte. Während AV1 durch fortschrittliche Codierungstools eine verbesserte Komprimierungseffizienz bietet, Diese Vorteile gehen mit einem erhöhten Rechenaufwand einher, insbesondere während der Kodierung.

Um diese erhöhte Komplexität einzuschätzen, In einem Offline-Experiment haben wir einen Open-Source-AV1-Encoder integriert und den Stromverbrauch auf einem Pixel gemessen 8 Gerät während eines Videoanrufs. Die Ergebnisse zeigten a 14% Anstieg des Stromverbrauchs im Vergleich zu H.264/AVC – eine erhebliche Herausforderung für den mobilen Einsatz. Um dies anzugehen, Wir haben einen internen Encoder mit geringer Komplexität eingeführt, der einen ähnlichen Stromverbrauch wie die H.264-Basislinie aufweist, wie im nächsten Abschnitt beschrieben.

Jenseits der Macht, Die AV1-Kodierung erhöht im Vergleich zu H.264/AVC auch die Speichernutzung, Dies führt zu Regressionen bei App-Abstürzen, die die Einführung von Mobilgeräten weiter erschweren.

Encoder mit geringer Komplexität

Ein starker Encoder sollte die visuelle Qualität mit der Rechenkomplexität in Einklang bringen. Die Kodierung mit geringer Komplexität ermöglicht die AV1-Kodierung auf Geräten der mittleren und unteren Preisklasse.

Im Vergleich zu älteren Codecs wie H.264/AVC, Neuere Codecs wie AV1 bieten eine bessere Komprimierungseffizienz. Jedoch, Man geht davon aus, dass diese Vorteile nur mit einer höheren Rechenkomplexität einhergehen – dies stellt ein Hindernis für die Ausweitung der AV1-Abdeckung auf Low-End-Geräte dar.

Jedoch, Ein neuerer Codec sollte nicht unbedingt einen Encoder mit höherer Komplexität erfordern. Weil moderne Codecs einen größeren Satz an Codierungstools unterstützen, Ein gut gestalteter Encoder bietet mehr Möglichkeiten, bessere Kompromisse zwischen Qualität und Komplexität zu finden. Diese Kompromisse werden auch als Voreinstellungen bezeichnet. Ideal, Der Encoder bietet mehrere Voreinstellungen, Es deckt einen Bereich von hoher bis niedriger Komplexität ab und sorgt gleichzeitig für einen konsistenten Effizienzgewinn bei der Komprimierung. Eine Voreinstellung mit extrem geringer Komplexität, vergleichbar mit H.264/AVC, könnte die Auslieferung von AV1 auf Low-End-Telefonen ermöglichen.

Um dies anzugehen, Für die RTC-Anwendungsfälle haben wir eine Encoder-Implementierung von AV1 mit geringer Komplexität übernommen. Zusätzlich zur Optimierung der Qualität der hochkomplexen Voreinstellung, Wir haben eine Voreinstellung mit extrem geringer Komplexität entwickelt. Diese neue Voreinstellung bietet eine mit H.264/AVC vergleichbare Kodierungskomplexität. Damit es vorhanden ist, Wir haben einen Mechanismus entwickelt, der die Encoder-Voreinstellung an die Gerätefunktionen anpasst, Dadurch können wir AV1 an eine viel breitere Palette von Geräten liefern.

Decoder-Auswahl

Nach Auswahl des Encoders, Der nächste Schritt ist die Auswahl des Decoders. Obwohl Videodecoder im Allgemeinen weniger komplex sind als Encoder, Wir haben festgestellt, dass die Komplexität der Dekodierung auf mobilen Geräten und bei Videoanrufen weiterhin erheblich ist, vor allem Low-End-Modelle. In unseren ersten A/B-Tests, Einige Low-End-Geräte konnten keine Echtzeitdekodierung durchführen, Dies führt zu Video-Einfrierungen und Problemen mit der Audio-/Video-Synchronisierung.

Wir haben mehrere Open-Source-Decoder verglichen und, nach A/B-Tests, wir haben ausgewählt dav1d für seine überragende Energieeffizienz und Zuverlässigkeit. Unsere Experimente zeigten auch eine Verlängerung der Gesprächszeit mit dem dav1d-Decoder.

Binäre Größe

Die Integration des AV1-Encoders und -Decoders in die mobile App bringt eine weitere Herausforderung mit sich: binäre Größe. Am Beispiel von libAOM, AV1-Unterstützung hinzugefügt 1.7 MB zur Bewerbung (600 kB komprimiert). Auch wenn dies vernachlässigbar klingen mag, Es ist eine große Herausforderung für ein Unternehmen, das Milliarden von Benutzern bedient. Die Binärgröße beeinflusst die Aktualisierungserfolgsraten, Startzeit der Anwendung, und Software-Gesundheitsmetriken wie Speichernutzung und Absturzraten, die sich negativ auf die Benutzererfahrung auswirken können. Eine größere Binärdatei führt dazu, dass mehr Benutzer ältere App-Versionen nutzen und die Einrichtung eingehender Anrufe verzögert wird. Zum Beispiel a 600 Eine Erhöhung der KB könnte für eine große Organisation das Binärgrößenbudget eines ganzen Jahres verschlingen.

Wir haben verschiedene Ansätze zur Reduzierung der Binärgröße untersucht.

• Unser ursprünglicher Ansatz bestand darin, ein dynamisches Download-Framework zu verwenden, um AV1 als separate Komponente bereitzustellen. Jedoch, Download-Fehler – sei es aufgrund schlechter Netzwerkbedingungen, Geräteprobleme, oder zufällige Vorkommnisse – beeinträchtigten das Benutzererlebnis, Dies macht diesen Ansatz unzureichend.
• Anschließend konzentrierten wir uns auf direkte binäre Größenoptimierungen. Zum Beispiel, die Quantisierungsmatrix (QM) Werkzeug macht etwa aus 10% der Bibliotheksgröße des Encoders; Eine Optimierung könnte es halbieren. Wir haben auch Größenreduzierungsoptimierungen zum dav1d-Projekt beigetragen.

Diese Strategie erstreckt sich auf die End-to-End-Pipeline-Optimierung, Entfernen Sie nicht verwendete Tools vollständig aus der Bibliothek. Zum Beispiel, Entfernen von QM-Freigaben 60 kB binärer Speicherplatz. Auf Anwendungsebene, Wir können Codec-Bibliotheken funktionsübergreifend gemeinsam nutzen – wie zum Beispiel die Transkodierung von Videonachrichten – und die integrierte Codec-Unterstützung der Plattform nutzen, um die Bündelung zusätzlicher Bibliotheken zu vermeiden.

Erweiterung der AV1-Abdeckung

Nach Auswahl des Encoders und Decoders, Die nächste Herausforderung bestand darin, herauszufinden, welche Geräte für die Verwendung von AV1 geeignet sind. Aufgrund der begrenzten Anzahl an Varianten war die Zusammenstellung geeigneter iOS-Modelle unkompliziert, Allerdings stellte Android aufgrund der Vielzahl an Gerätemodellen eine weitaus größere Herausforderung dar.

Wir haben zunächst versucht, Geräte basierend auf dem Speicher auszuwählen, Erscheinungsjahr, und Android-Betriebssystemversion, aber keine dieser Strategien erwies sich als ausreichend zuverlässig. Letztlich, Wir haben Metas hauseigenes ML-basiertes Gerüst zur Geräteberechtigung genutzt, um eine zuverlässige Liste berechtigter Android-Geräte zu erstellen.

Berechtigung für AV1-Geräte

Wir haben ein maschinelles Lernen entwickelt (ML)-based device eligibility framework to support advanced video and audio features based on device capability:

Die Idee besteht darin, groß angelegte statistische Daten aus der realen Welt zu verwenden, um die Gerätefunktionen zu kategorisieren, anstatt sich auf Labordaten zu verlassen. Dies hilft uns, unser Geräteberechtigungssystem zu skalieren und genauere Entscheidungen zu treffen. Wir schlagen einen ML-basierten Ansatz zur Geräteeignung vor, der über unsere Protokollierungspipeline gesammelte statistische Leistungsmetriken auf niedriger Ebene verwendet, um die AV1-Fähigkeit eines Geräts zu bewerten. Das Modell verwendet diese Messungen als Eingabemerkmale und gibt einen rtc_score aus, Dies quantifiziert die AV1-Gesamtleistung des Geräts. Diese Bewertung beeinflusst dann Entscheidungen wie die Optimierung von Anrufeinstellungen und die Bestimmung, ob ein Gerät den AV1-Codec effizient ausführen kann.

In 2025, Wir haben unser Modell mithilfe von AV1-spezifischen Daten und einer deutlich erweiterten Geräteunterstützung iterativ verfeinert. Unser erster Meilenstein, Modell V1.1, im August eingeführt 2025 und der AV1-Verkehr auf eine wachsende Anzahl von Geräten ausgeweitet. Dieser zusätzliche Datenverkehr trug zu einem dedizierten AV1-Datensatz bei, der mit der Zeit sowohl größer als auch repräsentativer wurde. Mit diesen reichhaltigeren Daten, Wir haben Modell V2 gebaut, Einführung eines zweistufigen Ansatzes, der zwischen High-End- und Low-End-Geräten unterscheidet – was die Realität widerspiegelt, dass Telefone der Einstiegsklasse und Flaggschiff-Geräte über sehr unterschiedliche AV1-Kodierungsfunktionen verfügen können. Über diese Iterationen hinweg, Wir haben die AV1-Aktivierung in der gesamten Gerätelandschaft erheblich erhöht, mit einem Ansatz, der darauf ausgelegt ist, sich weiter zu verbessern, wenn der Datenverkehr zunimmt und mehr Daten verfügbar werden.

Da der AV1-Verkehr weiter zunimmt, Wir gehen davon aus, dass die iterative Optimierung sowohl die Anrufdauer als auch die Qualität weiter verbessern wird.

Anpassung der Codec-Komplexität

Device eligibility lets us identify capable devices, Aber wir haben eine zusätzliche Herausforderung entdeckt: Bei A/B-Tests, Wir haben Anrufe mit erheblichen Rückgängen bei der Audio-/Videosynchronisierung beobachtet, Dies wird hauptsächlich durch Geräte verursacht, die Videos nicht in Echtzeit kodieren oder dekodieren können. Überraschenderweise, sogar ein 2023 Ein Smartphone mit einem Octa-Core-Prozessor konnte die Kodierung mit 320×180@15fps nicht bewältigen. Dieses Problem betraf sowohl H.264 als auch AV1, obwohl es bei AV1 häufiger vorkam. Wir vermuten, dass diese Geräte die CPU-Frequenz während Anrufen drosseln, Verringerung ihrer effektiven Leistungsfähigkeit.

Infolge, Die alleinige Aktivierung von AV1 basierend auf dem Gerätenamen reicht nicht aus. Wir brauchten einen robusteren Mechanismus, um die Codec-Komplexität basierend auf dem lokalen und Peer-Gerätestatus anzupassen. Wir haben drei Mechanismen entwickelt: adaptive Encoder-Voreinstellung, Kodierung latenzbewusster Codec-Umschaltung, und Dekodierung latenzbewusster Codec-Umschaltung.

Adaptive Encoder-Voreinstellungsanpassung

Wir haben mehrere Encoder-Voreinstellungen entwickelt, die von niedriger bis hoher Komplexität reichen. Ein Überwachungsmechanismus überwacht kontinuierlich die Codierungslatenz während Anrufen, um die entsprechende Voreinstellung auszuwählen. Wenn die Kodierungslatenz zu hoch wird – was bedeutet, dass das Gerät nahezu nicht mehr in der Lage ist, in Echtzeit zu kodieren – reduzieren wir die Komplexität des Kodierers. Umgekehrt, wenn das Gerät eine höhere Komplexität aushalten kann, Wir erhöhen die Voreinstellung, um eine bessere Qualität zu erzielen.

Latenzbewusster Codec-Switch für lokale Gerätekodierung

Wenn die Reduzierung der Encoder-Voreinstellung die Codierungslatenz immer noch nicht auf ein angemessenes Niveau reduziert, Wir wenden Codec-Umschaltung an. In diesem Fall, Das Gerät wechselt zu H.264/AVC, which may be less computationally intensive than AV1 for that specific content. Um dies zu ermöglichen, Wir verhandeln beim Anrufaufbau über die Unterstützung beider Codecs, und der Client überwacht kontinuierlich die Gerätebedingungen, um den am besten geeigneten Codec zu ermitteln. Die Encoder-Voreinstellung und die Codec-Auswahl werden gemeinsam festgelegt, um die Anrufqualität zu optimieren und Schwankungen bei der Codec-Auswahl zu verhindern.

Latenzbewusster Codec-Switch für die Dekodierung von Peer-Geräten

Weil AV1 auch eine höhere Dekodierungskomplexität aufweist, Wir möchten sicherstellen, dass das Peer-Gerät AV1-Frames in Echtzeit dekodieren kann. Dies ist besonders wichtig, wenn ein High-End-Telefon ein Low-End-Telefon anruft: Der Absender kann möglicherweise AV1 kodieren, während der Empfänger möglicherweise nicht in der Lage ist, es in Echtzeit zu dekodieren.

Um dies anzugehen, Jedes Gerät gibt während des Anrufs kontinuierlich seine Videodekodierungslatenz zurück. Wenn der Absender erkennt, dass der Peer AV1 nicht in Echtzeit dekodieren kann, es wechselt zurück zu H.264/AVC.

Zusammen, Diese Mechanismen passen sowohl die Encoder-Voreinstellung als auch den Codec basierend auf der Codierungs- und Decodierungslatenz adaptiv an. Jenseits der Latenz, Wir berücksichtigen auch andere Gerätezustandssignale, wie zum Beispiel den Batteriestand. Zum Beispiel, wenn die Batterie schwach ist, Wir wechseln zu H.264/AVC. Dies trägt dazu bei, die Anrufqualität aufrechtzuerhalten und die Anrufdauer zu verlängern.

Asymmetrisches Codec-Design

Mit der verbesserten Codec-Auswahlstrategie, Wir haben die AV1-Unterstützung auf Android-Geräten der mittleren und unteren Preisklasse eingeführt. Während einige Mittelklassegeräte keine Echtzeit-AV1-Kodierung durchführen können, viele können AV1 in Echtzeit dekodieren. Dies ermöglicht ein asymmetrisches Codec-Design: Mittelklassegeräte kodieren und senden weiterhin H.264/AVC, kann aber AV1 von High-End-Kollegen empfangen. Infolge, Wir haben die AV1-Abdeckung auf allen Android-Geräten deutlich erhöht.

Verbesserung der AV1-Anrufqualität

In den vorangehenden Abschnitten wurde unser Framework zur Aktivierung von AV1 auf einer Vielzahl von Geräten beschrieben. Mit diesem System, AV1 versorgt mittlerweile die meisten Mobilgeräte in Meta RTC mit Strom (Echtzeitkommunikation) Anwendungen. . Die nächste Herausforderung besteht darin, die AV1-Anrufqualität weiter zu verbessern.

Wie bereits besprochen, RTC-Produkte müssen sich während eines Anrufs dynamisch an die Netzwerkbedingungen anpassen. Zwei bemerkenswerte Herausforderungen sind Schwankungen der Netzwerkbandbreite und Paketverluste. Eine genaue Geschwindigkeitskontrolle hilft bei der Bewältigung von Bandbreitenänderungen. Fehlerresistente Strategien spielen eine wichtige Rolle bei der Gewährleistung zuverlässiger Qualität bei Paketverlusten.

Präzise Geschwindigkeitskontrolle

Im RTC, Aufrechterhaltung einer konstanten Bitrate (CBR) ist wichtig. Jede plötzliche Überschreitung der Bitrate kann zu einer Überlastung und einem Einfrieren des Videos auf der Peer-Seite führen. RTC-Anwendungen reagieren empfindlich auf sofortige Bitratenüberschreitungen, Daher reicht es nicht aus, einfach die durchschnittliche Bitrate zu überprüfen. Wir verwenden Video Buffering Verifier (VBV) Verzögerung als Maß zur Bewertung der CBR-Genauigkeit.

VBV-Verzögerung

Der Videopufferungsprüfer (VBV) ist eine Leaky-Bucket-basierte Messung, mit der sichergestellt wird, dass ein codierter Videostream korrekt gepuffert und am Decoder wiedergegeben werden kann.

Wir verwenden eine ähnliche Methode, um die Genauigkeit der CBR-Ratensteuerung zu messen. Die folgende Abbildung zeigt ein Beispiel:

Gehen Sie davon aus, dass die aktuelle Netzwerkbandbreite, die dem Video zugewiesen ist, beträgt 100 kbps und wir bitten den Encoder, Frames mit zu kodieren 100 kbit/s. Der Encoder codiert Frame (Frm) N bei 20 kbit. Gleichzeitig, Rahmen (Frm) N-1 wurde nicht vollständig übertragen, Und 5 kbit verbleiben im Puffer (wahrscheinlich aufgrund eines Überschwingens bei Bild N-1).

Das Senden von Frame N würde daher mindestens dauern (20 kbit + 5 kbit) / 100 kbit/s = 0.25 s = 250 MS. Betrachten Sie ein System, in dem die gewünschte VBV-Verzögerung für RTC beträgt unten 200 MS. In diesem Beispiel, Beispielsweise führen Encoder-Überschwingen und eine große VBV-Verzögerung wahrscheinlich zu einer schlechten Benutzererfahrung, höhere Latenz, Netzwerküberlastung, oder das Video friert ein. Dies unterstreicht die Bedeutung einer genauen Ratenkontrolle für RTC-Anwendungsfälle.

Optimierung der Ratensteuerung

Wir haben mehrere Verbesserungen bei der Geschwindigkeitssteuerung vorgenommen, um sicherzustellen, dass der Encoder nicht überschießt. Während der Kodierung, Der Encoder verfolgt den VBV-Pufferstatus und verwendet ihn zur Steuerung der Bitratenzuweisung. Wenn eine Überschreitung auftritt, Es reduziert die Rate nachfolgender Frames, um die VBV-Verzögerung unter Kontrolle zu halten. Unserer Erfahrung nach, Viele Video-Encoder kommen damit nicht gut zurecht, Dadurch kann die VBV-Verzögerung zunehmen und möglicherweise zu einer Überlastung des Netzwerks führen.

Ähnlich, Encoder weisen Intra-Only häufig eine hohe Bitrate zu (Schlüssel) Frames, um die Qualitätskonsistenz zwischen Schlüsselbildern und Zwischenbildern aufrechtzuerhalten. Einige Encoder „steigern“ sogar die Qualität von Schlüsselbildern, um die Qualität von Referenzbildern zu verbessern. Im RTC, Jedoch, Wir wollen Bitratenspitzen vermeiden. Der Encoder kontrolliert daher streng die Bitrate der Schlüsselbilder und reduziert die Rate nachfolgender Bilder, um etwaige Überschwinger auszugleichen.

Auch die Geschwindigkeitskontrolle in RTC stellt Herausforderungen dar:

• Häufige Änderungen der Zielbitrate. Der Client aktualisiert möglicherweise häufig die Zielbitrate des Encoders. Ein robuster Encoder muss die VBV-Verzögerung unter Kontrolle halten – insbesondere wenn die Zielbitrate stark abfällt.
• Häufige Auflösungsänderungen. Der Kunde kann während eines Anrufs auch häufig die Lösung ändern. Ein Ratenkontrollalgorithmus sollte daher auch bei häufigen Auflösungsänderungen stabil und effektiv bleiben. Zusätzlich, AV1 unterstützt eine nützliche Funktion zur Behebung dieses Problems, Dies wird als Referenzbild-Resampling bezeichnet (RPR), Dadurch sind Auflösungsänderungen möglich, ohne dass ein Schlüsselbild generiert werden muss. Dies kann Bitratenspitzen erheblich reduzieren und das Einfrieren des Videos verbessern.

Weil der Video-Encoder eng mit dem Modul zur Netzwerküberlastungskontrolle interagiert, Wir haben herausgefunden, dass die Verhinderung von Unterschreitungen ebenso wichtig ist wie die Verhinderung von Überschreitungen. In unseren frühen Versionen des Ratenkontrollalgorithmus, Wir nutzten eine konservative Zinsallokation, um Überschreitungen zu vermeiden, aber dadurch verstärkte sich die Tendenz zur Unterschreitung. Eine Unterschreitung kann die Bandbreitenschätzung verfälschen, langsamer Anstieg der Bitrate, und letztendlich die Videoqualität verschlechtern. Wir haben daher den Algorithmus überarbeitet, um Unterschreitungen zu beheben und die Bitratengenauigkeit zu verbessern.

Gesamt, Ein präziser Ratensteuerungsalgorithmus, der eine stabile Bitrate ohne nennenswerte Über- oder Unterschreitung erzeugt, kann die Qualität von Videoanrufen erheblich verbessern.

Fehlerresilienz

RTC legt strenge Latenzbeschränkungen fest, während moderne Video-Codecs auf lange angewiesen sind, enge Ketten von Abhängigkeiten zwischen Frames. Wenn ein Paket verloren geht, Der Empfänger muss ein NACK senden und einen Roundtrip auf die erneute Übertragung warten. Wenn das fehlschlägt, Die Abhängigkeitskette wird unterbrochen und das Video friert ein. Der Empfänger fordert dann einen Keyframe an, was eine weitere Hin- und Rückfahrt kostet, sondern weil Keyframes etwa zehnmal größer sind als typische P-Frames, Sie können das Netzwerk überlasten und den Paketverlust erhöhen, einen problematischen Kreislauf schaffen. Um dies abzumildern, Wir haben AV1 für eine schnelle Wiederherstellung und Eindämmung von Drifts bei Paketverlust durch die Nutzung zeitlicher Schichten optimiert (TL) und Langzeitreferenz (LTR) Rahmen.

Zeitliche Ebene (TL)

Temporale Schichten sind eine Form der zeitlichen Skalierbarkeit, die in modernen Video-Codecs verwendet wird (einschließlich AV1) Dabei organisiert der Encoder Frames in einer zeitbasierten Hierarchie. Die Basisschicht (zeitliche Schicht 0) sorgt allein für eine niedrigere Bildrate, während Verbesserungsschichten (zeitliche Schicht N) Fügen Sie Zwischenbilder hinzu, um höhere Bildraten zu erreichen, wenn die Bedingungen dies zulassen. Figur 4 zeigt die zweischichtige Struktur, die wir für AV1 verwenden.

Eine bemerkenswerte Eigenschaft dieser Struktur besteht darin, dass die Basisschicht die Kontinuität beibehält, ohne auf Enhancement-Layer-Frames angewiesen zu sein. Wenn Enhancement-Layer-Pakete verloren gehen oder zu spät ankommen, Die Dekodierung kann weiterhin mit der Basisschicht erfolgen, ohne dass es zu Verzögerungen kommt. Wir machen uns dies zunutze, indem wir die Robustheit nach Schicht priorisieren: Wir wenden FEC an, um Basisschichtdaten zu schützen, anstatt Redundanz für Erweiterungsdaten aufzuwenden. Wir behandeln Neuübertragungen auf der Erweiterungsschicht auch konservativer – wenn es um die Roundtrip-Zeit geht (RTT) ist niedrig, Das erneute Übertragen eines fehlenden Erweiterungspakets kann hilfreich sein; wenn RTT hoch ist, Wir können erneute Übertragungen überspringen, ohne den Decodierungsfluss zu unterbrechen.

Es gibt einen Kompromiss: Im Vergleich zu einer stark abhängigen Vorhersagekette (wobei jeder Frame auf den unmittelbar vorhergehenden Frame verweist), Eine temporale Schichtstruktur ist typischerweise weniger komprimierungseffizient, Wenn Sie also TL ständig aktiviert lassen, kann dies bei einer bestimmten Bitrate zu einer Verschlechterung der Qualität führen. Die Vorteile von TL zeigen sich jedoch hauptsächlich bei verlustbehafteten oder instabilen Netzwerken, Dabei handelt es sich nur um eine Teilmenge realer Anrufe. Aus diesem Grund, Wir aktivieren TL adaptiv. Der Absender überwacht das Netzwerk-Feedback, schaltet TL ein, wenn der Verlust steigt, und schaltet es wieder aus, sobald sich die Bedingungen erholen. Dies gibt uns Resilienz, wenn wir sie brauchen, ohne Einbußen bei der Effizienz, wenn wir sie nicht brauchen.

Langzeitreferenz (LTR)

LTR ist eine Fehlerresistenzfunktion, die es einem Video-Encoder ermöglicht, Referenzbilder länger als normale Referenzbilder im Puffer zu speichern und LTR-vorhergesagt zu senden (LTRP) Rahmen wie gewünscht. Wenn die Decodierungskette aufgrund eines Frameverlusts unterbrochen ist, Ein eingehender LTRP-Frame – vorhergesagt aus einem zuvor dekodierten LTR-Frame – synchronisiert Sender und Empfänger sofort neu, sich von dem Verlust erholen. Figur 5 veranschaulicht, wie LTR- und LTRP-Frames in verlustfreien und verlustbehafteten Szenarien funktionieren.

Die Implementierung von LTR erfordert eine enge Abstimmung mit der Netzwerkschicht. Figur 6 zeigt, wie der AV1-Encoder mit der Netzwerkschicht interagiert. Der Encoder sendet regelmäßig LTR-Frames aus und fixiert sie in seinem begrenzten Referenzpuffer der Größe 4, Entfernen des ältesten angehefteten LTR, wenn ein neuer hinzugefügt wird. Aus Sicht der Netzwerkschicht, Jedoch, Ein codierter LTR-Frame sieht genauso aus wie jeder andere Frame, Daher kann das Netzwerk nicht erkennen, wann eine Bestätigung an den Encoder zurückgesendet werden muss. Um dies zuverlässig zu machen, Der Encoder sendet einen expliziten LTR-Indikator, wenn er den Frame an die Netzwerkschicht übergibt. Dies unterscheidet sich von H.264, wobei LTR- und Nicht-LTR-Referenzrahmen durch die Bitstromsyntax unterschieden werden – die Netzwerkschicht kann den H.264-Slice-Header analysieren, um einen LTR-Rahmen zu erkennen und den Absender beim Empfang zu bestätigen.

Der explizite LTR-Indikator ist ein binäres Flag, das in unserer proprietären RTP-Header-Erweiterung enthalten ist, mit dem wir Metadaten pro Frame auf dem Primärkanal transportieren. Wir enthüllen auch die Frame_ID an die Netzwerkschicht über die LTR-Bitstream-Syntax. ACK-Feedback wird über eine separate proprietäre RTP-Header-Erweiterung gesendet. Jedes ACK enthält das entsprechende Frame_ID, Dadurch kann der Absender eindeutig identifizieren, welches LTR empfangen wurde. Bei der Bearbeitung einer LTRP-Anfrage, Der Encoder verwendet immer den zuletzt bestätigten LTR als Vorhersagereferenz.

Die Netzwerkschicht fordert in zwei Fällen einen LTRP-Frame vom Encoder an. Das erste ist reaktive Erholung, wenn der Empfänger einfriert und ein RPSI sendet, um ein LTRP anzufordern. Das zweite ist proaktiver Schutz, wenn der Absender über einen Rückkopplungskanal einen erhöhten Paketverlust erkennt und den Encoder auffordert, regelmäßig LTRPs zu senden. Während der proaktive Weg etwas überflüssig sein kann, Es verbessert die Zuverlässigkeit erheblich und reduziert das Einfrieren. Aus der Sicht des Encoders, Der Grund spielt keine Rolle – es empfängt einfach eine LTRP-Anfrage und antwortet basierend darauf, ob es eine bestätigte LTR-Referenz im Puffer hat. Wenn ein LTR verfügbar ist, Der Encoder erzeugt einen LTRP-Frame. Wenn nicht, Es geht davon aus, dass eine Neusynchronisierung erforderlich ist, und sendet stattdessen einen Schlüsselrahmen.

Während LTR für die Wiederherstellung von Verlusten effizienter ist, als einen Schlüsselrahmen zu erzwingen oder sich auf erneute Übertragungen zu verlassen, Dies kann die Gesamteffizienz der Codierung verringern, da ein LTRP-Frame möglicherweise auf einen älteren LTR mit schwächerer zeitlicher Korrelation verweist, Dadurch wird die Bewegungsvorhersage weniger genau. Wir mildern dies, indem wir eine bestehende Wahl des Encoder-Designs nutzen – der Encoder gibt bereits ein periodisches Signal aus, etwas hochwertigerer Rahmen zur Verbesserung der Gesamtqualität. Wir markieren diesen Frame einfach als LTR, So behält der LTR auch im Alter seine hohe Qualität.

Metas weitere Reise mit AV1

Die Einführung von AV1 für die Echtzeitkommunikation bei Meta war eine mehrjährige Anstrengung, die sich über die Auswahl des Codecs erstreckte, Geräteberechtigung, Geschwindigkeitskontrolle, und Fehlerresilienz. Durch die Kombination eines Encoders mit geringer Komplexität mit ML-basierter Geräteberechtigung, adaptive Codec-Umschaltung, und robuste Mechanismen zur Fehlerresilienz, Wir haben AV1 auf den meisten Mobilgeräten aktiviert und damit bedeutende Qualitätsverbesserungen erzielt, insbesondere für Benutzer in Netzwerken mit eingeschränkter Bandbreite. Diese Initiative ergänzt unsere laufenden Bemühungen, AV1 für VOD-Anwendungen zu erweitern. Da sich die Gerätefunktionen weiter verbessern und ML-Modelle mehr Daten nutzen, Wir gehen davon aus, dass sich die AV1-Abdeckung und die Anrufqualität weiter verbessern werden.

In der Zwischenzeit, Wir arbeiten daran, AV1 auf Gruppenrufe auszudehnen. Im Gegensatz zu 1:1 Anrufe, Teilnehmer an Gruppenanrufen müssen mehrere Videostreams dekodieren, was die Erhöhung der AV1-Abdeckung bei Gruppenanrufen schwieriger macht. Während Software-AV1-Implementierungen die stetige Erweiterung der AV1-Abdeckung unterstützen, Höhere Qualität und verbesserte Funktionen erfordern wahrscheinlich AV1-Hardwareunterstützung.

Die Vorteile von AV1 liegen auf der Hand, und die meisten Inhalts- und RTC-Dienstanbieter wechseln zu AV1 als ihrem Flaggschiff-Codec. Wir ermutigen SoC-Anbieter, auf allen Geräteebenen in HW AV1 zu investieren, um die AV1-Anforderungen zu erfüllen und ein verbessertes Zuschauererlebnis zu bieten, Einsparungen bei der Gerätebatterie und verbesserte Effizienz der Netzbetreiber-Infrastruktur.