Anfang letzter Woche fragte mich ein Kollege bei Google: “Macht Meet irgendetwas Seltsames mit scalabilityMode?” Offenbar bin ich die erste Anlaufstelle, wenn es um ungewöhnliches Verhalten von Google Meet geht – was durchaus Sinn macht, da ich auf eine über ein Jahrzehnt lange Beobachtungsgeschichte der Meet-Implementierung zurückblicke.
Es stellte sich heraus, dass es eigentlich um das seltsame Verhalten von Microsoft Edge ging, wenn es darum ging, die Statistik-Eigenschaft scalabilityMode auf der Chromium-Seite webrtc-internals anzuzeigen. (Zur Information: Ich arbeite für Microsoft, daher kenne ich mich mit Edge und WebRTC etwas besser aus.) Zu diesem Zeitpunkt war es jedoch bereits zu spät, da ich bereits Chrome Canary und Edge gestartet hatte, um Google Meet genauer zu untersuchen. Dies erwies sich als interessant genug für einen Blogbeitrag, denn ich stieß auf eine unerwartete Überraschung: AV1 in Google Meet!
Da dies mein erster Beitrag seit Langem ist, werde ich meine Untersuchung zu AV1 in Google Meet mit einigen verwandten Anmerkungen zu VP9 SVC abrunden und auch die Vorteile der AV1-Bildschirmfreigabe erörtern.
AV1 Codec in Google Meet im Fokus
AV1-Hinweise in webrtc-internals
Hier ist der erste webrtc-internals-Dump, den ich gesammelt habe (Sie können den Roh-Dump herunterladen, falls Sie Ihre eigenen Schlussfolgerungen ziehen möchten):
Diagramm aus webrtc-internals mit Peaks im Zusammenhang mit AV1
Was meine Aufmerksamkeit erregte, noch bevor ich etwas las (dazu komme ich gleich), waren die vielen Spitzen im Diagramm. Ein möglicher Grund für diese Spitzen ist, dass viele der getStats-Zähler zurückgesetzt werden, wenn der Encoder aus irgendeinem Grund neu initialisiert wird – was die sägezahnartigen Spitzen erzeugt.
Dieser Fehler stört mich, seit ich ihn erstmals im Dezember 2015 während meiner Zeit bei Tokbox gemeldet habe, und er ist acht Jahre später immer noch nicht behoben:
getStats: switching the video codec resets the packetsSent/bytesSent counters on a ssrc report https://bugs.chromium.org/p/webrtc/issues/detail?id=5361
Während sich in dieser Zeit vieles geändert hat, ist dieses Problem bestehen geblieben. Das ist nicht unerwartet. Das Beheben von Problemen erfordert Zeit und Mühe, und das sind sehr knappe Ressourcen. Oder um es unverblümt auszudrücken: Solange ein Problem kein Problem für einen Entwickler ist, der dafür bezahlt wird, es zu beheben, sollte man nicht viel Fortschritt erwarten.
Beim Lesen des Textes oben sehen wir, dass die Encoder-Implementierung ganz oben libaom anzeigt, was bedeutet, dass dieser Anruf Video mit dem AV1-Codec kodierte. Es ist kein Geheimnis, dass Google auf AV1 setzt und daran arbeitet, es im Kontext von WebRTC zu verbessern. Bisher wurde dies jedoch hauptsächlich in Google Duo eingesetzt (Meta hat es auch in Messenger implementiert), und dies war Google Meet als die “Chrome WebRTC Flaggschiff-Anwendung”, die es nutzte. Dies verdient also einen genaueren Blick auf die Integration von AV1 in Google Meet!
Tiefergehend: Wie Google Meet AV1 nutzt
Das Lesen roher JSON-Dumps von webrtc-internals ist eher umständlich, aber glücklicherweise habe ich bereits den webrtc-dump-importer dafür erstellt. Ich habe dieses Tool aktualisiert, um sowohl die Encoder/Decoder-Implementierung als auch die scalabilityMode-Eigenschaften von getStats zu visualisieren.
Insgesamt ist der Anruf in drei Phasen unterteilt:
- Die erste Phase tritt ein, wenn sich niemand sonst im Raum befindet.
- Die zweite Phase beginnt, wenn der Codec zurück auf VP9 umgeschaltet wird.
- Die dritte Phase ist die Zeit danach.
Dies ist unten dargestellt:
Drei Phasen der Codec-Nutzung in Google Meet webrtc-internals
Was genau sehen wir auf dem Screenshot? Es scheint, ich hatte Glück und testete zu einem Zeitpunkt, als Google ein Experiment mit AV1 durchführte, da ich dieses Verhalten nicht mehr reproduzieren kann. Ich testete in Chrome Canary, das eine bessere Unterstützung für nahtloses Codec-Switching bietet, was möglicherweise dazu beigetragen hat, dass es als Teil eines experimentellen Rollouts betrachtet wurde.
Die wichtigsten Datenreihen sind die tatsächliche Bitrate, die Zielbitrate und die Frame-Breite & -Höhe. Betrachten wir die verschiedenen Phasen im Detail:
Detaillierte Analyse der AV1-Nutzung in Google Meet
AV1 wurde während der “Vor-Anruf-Phase” verwendet, als ich alleine wartete, um den zweiten Tab zu öffnen. Während dieser Zeit sendet AV1 (mit zeitlicher Skalierbarkeit) 320×180-Frames an den Server. Der Skalierbarkeitsmodus ist L1T2, d.h. AV1 mit zeitlicher Skalierbarkeit. Das Senden von Daten an den Server macht Sinn, um den Transport aufzuwärmen und eine gute Bandbreitenschätzung zu erhalten, aber ich mag die Datenschutzimplikationen nicht, einen Benutzer-Stream zu senden, bevor man tatsächlich einem Anruf beitritt. Ich habe dies bereits vor einem Jahrzehnt den Mitarbeitern des Hangouts-Teams mitgeteilt, aber ohne Erfolg. Höchstwahrscheinlich generiert der eingehende Verkehr, der dadurch verursacht wird, auch keine tatsächlichen monetären Kosten.
Um eine Bandbreitenschätzung zu erhalten, müssen einige RTP-Pakete gesendet werden. Dabei spielt es keine Rolle, welchen Codec man verwendet. Die Nutzung von AV1 während dieser Vor-Anruf-Phase erfüllt den Zweck, RTP-Daten an den Server zu senden und eine korrekte Bandbreitenschätzung von 2,5 Mbit/s zu erhalten, selbst aus den anfänglichen niedriger auflösenden AV1-Daten:
Bandbreitenschätzung durch AV1-Daten vor dem Anruf
Für Google Meet hat dieser sekundäre Zweck wahrscheinlich eine größere Bedeutung. Er setzt jeden AV1-bezogenen Codepfad in einer Produktionsumgebung in Betrieb. Zusätzlich liefert er Google Einblicke in die CPU-Auslastung und das Ausmaß der AV1-Unterstützung. Man muss bedenken, dass für einen Dienst wie Google Meet die Standards für die Bereitstellung von etwas in einer “Produktionsumgebung” außergewöhnlich hoch sind. Dies ermöglicht es ihnen, AV1 zu testen, ohne tatsächlich ein Video davon anzuzeigen. Es ist ein cleverer Weg, um die Integration von AV1 in Google Meet unter realen Bedingungen zu validieren.
Sobald der zweite Nutzer beitritt (auch wenn dieser Nutzer ebenfalls den AV1-Codec unterstützt), ändert sich die Codec-Implementierung auf libvpx mit einem Skalierbarkeitsmodus L1T1 und der Codec wechselt zu VP9.
Codec-Wechsel von AV1 zu VP9 nach dem Beitritt des zweiten Nutzers
Die Bitrate wird aufgrund des oben erwähnten Fehlers negativ und wird nicht angezeigt. Überraschenderweise ändert sich die Zielbitrate eine Sekunde nach der Auflösung, was ein Fehler sein könnte.
Die Nutzung von AV1 während der Vor-Anruf-Phase ist eine hervorragende Teststrategie und genau so, wie ich einen neuen Codec in die Produktion einführen würde. AV1 wurde im April 2020 in libWebRTC integriert. Seitdem wurde es erheblich optimiert, was in der rtc@scale-Sitzung 2022 gut zusammengefasst wurde.
Eine so lange Zeitspanne zwischen der Implementierung des Codecs und seiner Produktionseinführung ist nicht ungewöhnlich. Wir haben eine ähnliche Zeitlinie für VP9 SVC gesehen, das Ende 2014 oder Anfang 2015 in Chrome eingeführt wurde, und wir diskutierten SVC immer noch als etwas, das “ohne Flags noch nicht verfügbar” war, im Jahr 2017. Google täuschte hier alle, indem es VP9 K-SVC aktivierte, indem es den Codepfad für die VP8-Simulcast-SDP-Mungierung missbrauchte, was immer noch die Art und Weise ist, wie Google Meet es in der Produktion verwendet.
VP9 k-SVC
Videocodecs in WebRTC sind komplex. Wie weitere Tests gezeigt haben, verwendet Google Meet in der Produktion immer noch VP9 Scalable Video Coding (SVC, d.h. L3T3_KEY und ähnliche Modi), was angesichts des enormen Aufwands, der in hardwarebeschleunigtes VP9 Simulcast geflossen ist, überraschend ist. Als Nebeneffekt der Untersuchung der AV1-Änderungen macht der Dump-Importer nun deutlicher, wie Google Meet SVC dynamisch ein- und ausschaltet, abhängig von der Anzahl der Teilnehmer im Anruf:
Dynamische Anpassung von VP9 SVC in Google Meet
In einem anderen Dump sehen wir L1T1 (d.h. kein SVC) mit VP9 während des Pre-Call-Warm-ups, gefolgt von VP9 L1T1 mit hoher Auflösung, nachdem der zweite Teilnehmer beigetreten ist, und dann einen Wechsel zu L3T3_KEY. Der Grund, das Verhalten hier zu optimieren, ist, dass VP9 SVC derzeit einen Rückfall auf Software-Dekodierung erzwingt, da der Hardware-Dekoder es nicht dekodieren kann. Obwohl eine Behebung möglich sein könnte, sind die Korrekturen noch nicht implementiert oder verifiziert worden. Dies unterstreicht die anhaltenden Herausforderungen bei der optimalen Integration von Videocodecs in große Anwendungen wie Google Meet.
Die kontinuierliche Entwicklung im Bereich der Streaming-Dienste und Browser-Funktionen wie YouTube TV auf Chrome zeigt, wie wichtig die effiziente Verarbeitung von Videoinhalten ist.
AV1 Screen Content Coding ist besser
Allerdings erwartete ich nicht, dass AV1 zuerst in Google Meet für Webcam-Videos auftauchen würde. Während Meet VP9 und SVC für Webcam-Inhalte verwendet, nutzt die Bildschirmfreigabe (oder vielmehr die Tab-Freigabe, die datenschutzfreundlicher ist) weiterhin VP8 Simulcast über eine separate RTCPeerConnection. AV1 wäre hier ein viel natürlicherer Codec gewesen, da er eine Funktion namens “Screen Content Coding” besitzt, die einige Tricks anwendet, um die Bitrate drastisch zu reduzieren. libWebRTC aktiviert diesen speziellen Modus für MediaStreamTracks, die von der Bildschirmfreigabe stammen (oder mit einem contentHint auf “detail” gesetzt sind), schon seit einiger Zeit.
Anfang dieses Jahres versuchte ich, diese Funktion auf WebCodecs zu portieren, um eine gewisse Konsistenz in den verschiedenen von Chrome unterstützten Video-Encoding-Mechanismen zu erreichen. Das wurde schließlich anders implementiert, als ich erwartet hatte. Es wird nun durch das contentHint-Attribut gesteuert. Die unten gezeigten Ergebnisse sind ziemlich beeindruckend. WebCodecs macht sie leicht visualisierbar. Hinweis: Dies in WebRTC zu vergleichen ist viel schwieriger, da wir keinen einfachen Zugriff auf Frame-Größen haben und die Encoder-Bitrate durch die Bandbreitenschätzung bestimmt wird.
Demonstration der Frame-Größenreduzierung durch AV1 Screen Content Coding
Der obige Screenshot verwendet Chrome Canary mit einem jsfiddle, das zwei AV1-Encoder parallel mit demselben Inhalt ausführt – einem geteilten Tab mit langsam umgeblätterten Folien. Das Ergebnis ist eine Reduzierung der Frame-Größen und damit der Bitrate um über 25 %. Dies ist in einem Mehrparteien-Szenario noch wichtiger, da ein SFU die großen Frames, die bei jeder Änderung der aktuellen Folie als Spitzen auftreten, an viele Teilnehmer verteilen muss. Die Reduzierung der Frame-Größe hilft hier erheblich. Dies verdeutlicht, warum die Optimierung der Bildschirmfreigabe mit AV1 für Dienste wie Google Meet von entscheidender Bedeutung ist, um eine reibungslose und effiziente Kommunikation zu gewährleisten.
Erwarten Sie mehr AV1 im Jahr 2024
AV1 reift schnell genug, um produktionsreif zu werden. Zum Beispiel wurde die verbesserte Hardware-Codec-Unterstützung für AV1 gerade in Chrome M120 implementiert. Das Jahr 2024 wird spannend, da wir voraussichtlich eine breitere Akzeptanz und tiefere Integration von AV1 in wichtigen Anwendungen wie Google Meet und anderen WebRTC-Plattformen erleben werden. Bleiben Sie dran für weitere Einblicke in die Welt der WebRTC-Codecs und die sich ständig weiterentwickelnde Landschaft der Video-Kommunikation!