Chrome 70 unterstützt [Funktionsliste] und AV1 - warum ist die Codec-Unterstützung so wichtig?

Die 69. Version von Chrome war ein großes Update zeigte eine neue Oberfläche für Desktop- und mobile Versionen. Chrome 70 ist nicht so radikal, aber seine neuen Funktionen sind sehr wichtig. Wir haben eine angepasste Übersetzung erstellt und Material hinzugefügt, das unserer Meinung nach das Wichtigste in der neuen Version ist - die Unterstützung des AV1-Codecs, der neue Maßstäbe für die Leistung setzt. Bisher wird der Codec nur beim Abspielen von Videos verwendet, wir hoffen jedoch, dass er bei WebRTC ankommt. Dies gibt uns die Möglichkeit, die erweiterte Codierung in Videoanrufen und Konferenzen zu verwenden (z. B. mithilfe unseres Web SDK ).

Unterstützt AV1

Vor fast 10 Jahren hat Google seinen eigenen Mitbewerber-Codec für H.264 eingeführt - es war VP8 . Während die technologischen Konkurrenten nicht sehr unterschiedlich waren, war VP8 kostenlos und H.264 benötigte eine Lizenz. Android unterstützte VP8 sofort, beginnend mit 2.3 Gingerbread. Außerdem können alle gängigen Browser (mit Ausnahme von Safari) VP8-Videos abspielen.

Google ist jetzt Teil der Alliance for Open Media, einer Unternehmensgruppe, die einen VP8 / VP9-Nachfolger namens AV1 entwickelt. Facebook hat den Codec bereits an Tausenden von beliebten Videos getestet und festgestellt, dass die Komprimierung im Vergleich zu VP9 um mehr als 30% zunimmt, und zwar um 50,3%, 46,2% und 34% (im Vergleich zum x264-Hauptprofil hoch). x264-Profil bzw. libvpx-vp9).

Ab Chrome 70 unterstützt der AV1-Codec die Standardeinstellung für Desktop und Android. Und obwohl es einige Zeit dauern wird, bis der Codec weit verbreitet ist, ist dies immer noch ein wichtiger Schritt, denn Kein anderer Browser unterstützt AV1.

AV1 im Detail

Erläuterung: Dieser Abschnitt enthält Auszüge aus dem Artikel Video der nächsten Generation: Einführung in AV1 .

Chroma von Luma

Das Chroma aus der Luma-Vorhersage (im Folgenden - CfL) ist eine der neuen Prognosemethoden, die in AV1 verwendet werden. CfL sagt Farben in einem Bild (Chroma) basierend auf einem Luma-Wert voraus. Zuerst werden Luminanzwerte codiert / decodiert, dann versucht CfL, Farben vorherzusagen. Wenn der Versuch erfolgreich ist, wird die Menge an Farbinformationen, die codiert werden müssen, reduziert. Dadurch wird Platz gespart.

Es ist erwähnenswert, dass CfL zum ersten Mal nicht in AV1 erschien. Das Gründungsdokument zu CfL stammt aus dem Jahr 2009; Gleichzeitig schlugen LG und Samsung eine frühzeitige Implementierung von CfL unter dem Namen LM Mode vor , was jedoch während der Entwicklung von HEVC / H.265 eingeschränkt wurde. Der Thor-Codec von Cisco verwendet eine ähnliche Technik, und HEVC hat eine verbesserte Version namens Cross-Channel Prediction (CCP) implementiert.

Verbesserte Intra-Vorhersage

Bis vor kurzem basierte die Videokomprimierung auf der Vorhersage zwischen Bildern , d.h. über den Unterschied des Rahmens zu anderen, wenn die Vorhersage auf Referenzrahmen basiert. Trotz der Tatsache, dass sich diese Technik schnell entwickelt hat, sind immer noch Referenzrahmen erforderlich, die nicht auf anderen Rahmen beruhen. Infolgedessen verwenden die Referenzrahmen nur eine Intra-Frame-Vorhersage.

Die ersten 60 Bilder des Testvideos. Das Histogramm beginnt mit einem Referenzrahmen, der ~ 20-mal größer ist als der Rest.

Die Referenzrahmen sind viel größer als die Zwischenrahmen - daher versuchen sie, sie so wenig wie möglich zu verwenden. Wenn jedoch viele Referenzrahmen vorhanden sind, erhöht dies die Videobitrate. Um dies zu bewältigen und die Größe der Referenzrahmen zu verringern, konzentrierten sich die Codec-Forscher auf die Verbesserung der Intra-Frame-Vorhersage (die auch auf Zwischenrahmen angewendet werden kann).

Zusammenfassend kann argumentiert werden, dass CfL genau die fortschrittliche Technik der Intra-Frame-Vorhersage ist, weil Es funktioniert basierend auf der Helligkeit innerhalb des Rahmens .

Farbige Buntstifte

CfL ist im Kern die Färbung eines monochromen Bildes basierend auf einer vernünftigen, genauen Vorhersage. Die Vorhersage wird durch die Tatsache erleichtert, dass das Bild in kleine Blöcke schlägt, in denen die Codierung unabhängig erfolgt.

Blockieren, um die Codierungsgenauigkeit zu maximieren.

Da der Encoder nicht mit dem gesamten Bild, sondern mit seinen Fragmenten arbeitet, reicht es aus, Korrelationen in kleinen Bereichen aufzudecken - dies reicht aus, um Farben für eine gesegnete Helligkeit vorherzusagen. Nehmen Sie einen kleinen Bildblock:


Basierend auf diesem Fragment stellt der Encoder fest, dass hell = grün und je dunkler, desto geringer die Sättigung. Und so auch mit dem Rest der Blöcke.

CFL zu AV1

CfL hat nicht begonnen, den PVQ- Algorithmus zu verwenden, daher sind die Kosten für die Pixel- und Frequenzdomänen ungefähr gleich. Außerdem verwendet AV1 diskrete Sinus- und Pixeldomänen-Identitätstransformationen, sodass es nicht sehr einfach ist, AV1 CfL im Frequenzbereich durchzuführen. Aber - eine Überraschung - AV1 benötigt im Frequenzbereich kein CfL, weil Die grundlegenden CfL-Gleichungen funktionieren in beiden Bereichen gleich.

CFL in AV1 soll die Rekonstruktion so weit wie möglich vereinfachen. Dazu müssen Sie α explizit codieren und β auf seiner Basis berechnen, obwohl ... Sie können β nicht berechnen, sondern stattdessen die vom Encoder bereits vorhergesagte DC-Farbverschiebung verwenden (sie ist weniger genau, aber immer noch geeignet):

Vergleich der Standard-DC-Vorhersage (Berechnung basierend auf benachbarten Pixeln) mit dem berechneten β-Wert (Berechnung basierend auf Pixeln im aktuellen Block).

Somit wird die Komplexität der Approximation auf der Codiererseite durch die Verwendung von Vorhersage maximal optimiert. Wenn die Prognose nicht ausreicht, werden die verbleibenden Transformationen ausgeführt. Wenn die Vorhersage keine Vorteile in Bits bietet, wird sie überhaupt nicht verwendet.

Einige Tests

Die Open Media Alliance verwendet eine Reihe von Tests , die auch in Are We Compressed Yet?

Unten finden Sie eine Tabelle mit einer Bitrate im Kontext verschiedener Indikatoren. Achten Sie auf CIE Delta-E 2000, dies ist eine Metrik für einen wahrnehmungsgleichmäßigen Farbfehler. Es fällt auf, wie die Bitrate gespeichert wird. Bis zu 8%!

	Bd-Rate
	PSNR	PSNR-HVS	SSIM	CIEDE2000	PSNR Cb	PSNR Cr	MS SSIM
Durchschnitt	-0,43	-0,42	-0,38	-2,41	-5,85	-5,51	-0,40
1080p	-0,32	-0,37	-0,28	-2,52	-6,80	-5,31	-0,31
1080p-Bildschirm	-1,82	-1,72	-1,71	-8,22	-17,76	-12,00	-1,75
720p	-0,12	-0,11	-0.07	-0,52	-1.08	-1,23	-0,12
360p	-0,15	-0,05	-0,10	-0,80	-2,17	-6,45	-0.04

... und andere neue Elemente in Chrome 70

PWA unter Windows

Obwohl die Unterstützung für Progressive Web Apps hauptsächlich auf mobilen Plattformen implementiert ist, vergisst Google den Desktop nicht. In Desktop Chrome 67 wurde die Schaltfläche für die PWA-Installation angezeigt, und Chrome 70 brachte bereits einige Verbesserungen für Windows-Benutzer.


Jetzt zeigt Chrome das Popup "App installieren?" für PWA (nachdem Sie eine Weile mit ihnen interagiert haben). Wenn Sie PWA installieren, erstellt der Browser im Startmenü eine Verknüpfung für PWA. Ähnlich wie bei der mobilen Erfahrung wird die Browseroberfläche in der offenen PWA ausgeblendet.

Google verspricht, diese Funktionalität für Mac und Linux in Version 72 einzuführen.

Formerkennungs-API

Webanwendungen können Barcodes lesen und Gesichter auf unterschiedliche Weise erkennen, normalerweise mithilfe von JS-Bibliotheken für maschinelles Lernen. Dies kann jedoch sehr langsam funktionieren. Um diese Funktion zugänglicher und produktiver zu machen, führt Google eine eigene Funktionalität für die Chrome-Formerkennung ein.

Die Formerkennungs-API in Chrome 70 ist ein Ursprungsversuch, d. H. es ist noch nicht für den weit verbreiteten Gebrauch bereit. Die API kann drei Arten von Objekten / Bildern definieren - Gesichter, Barcodes und Text. Derzeit variiert die Kompatibilität zwischen den Plattformen, da das Betriebssystem Funktionen zum Definieren von Objekten benötigt. Sie können die Demo hier ausprobieren.

TLS 1.3

Transport Layer Security ist ein Protokoll, mit dem Sie Daten sicher über das Internet übertragen können. Wenn Sie die Site unter HTTPS verwenden, werden die Daten höchstwahrscheinlich über TLS gesendet. Chrome 70 unterstützt TLS 1.3, das im letzten Monat veröffentlicht wurde.

Die Liste der Änderungen ist hier verfügbar, aber im Allgemeinen verbessert Version 1.3 sowohl die Effizienz als auch die Sicherheit (z. B. BREACH und CRIME „gewonnen“, dank derer Sie dank menstenebris die Komprimierung für https - Übersetzerkommentare wieder sicher verwenden können ). Es sind weniger Schritte erforderlich, um eine Verbindung herzustellen, sodass Sie eine leichte Verbesserung der Zeit feststellen können (wenn die von Ihnen besuchte Site natürlich TLS 1.3 unterstützt). Hier ist ein klarer Vergleich der Unterschiede zu CloudFlare :



Mit der Veröffentlichung von TLS 1.3 wird auch die Unterstützung für alte Funktionen wie SHA1 und MD5 eingestellt. Google hat dies auf der Statusseite angekündigt:

TLS 1.3 war ein mehrjähriges Projekt, bei dem Unterstützer aus verschiedenen Branchen, Forschungsgruppen und anderen Teilnehmern zusammenkamen, während sie an dem Standard arbeiteten. Früher haben wir mit Entwurfsversionen des Standards experimentiert, aber wenn der Standard vollständig implementiert wurde, können wir ihn endlich in Chrome implementieren.

Firefox 60 fügte Unterstützung für TLS 1.3 (Entwurf 23) hinzu, das im Mai dieses Jahres eingeführt wurde. dann begann CloudFlare damit.

Weitere Funktionen

Wie immer enthält Chrome 70 Innovationen für Benutzer und Entwickler. Hier ist eine Liste anderer Änderungen in diesem Update:

• Die Sprachsynthese-API funktioniert erst, wenn die Seite mindestens einmal mit dieser API interagiert hat. Diese API wird häufig für Spammer-Popups auf Mobilgeräten bis zur neuen Autoplay-Richtlinie in Chrome 66 verwendet.
• Touch ID auf Macbook Pro kann als Anmeldemethode in der Webauthentifizierungs-API verwendet werden.
• Wenn sich die Seite im Vollbildmodus befindet, wird die Seite durch das Erscheinen eines Popups aus dem Vollbildmodus entfernt.
• AppCache funktioniert nicht mehr auf NICHT https-Seiten.
• Auf Android-Geräten ist die OC-Build-Nummer (z. B. „NJH47F“) nicht mehr im Benutzeragenten enthalten, um die Identifizierung des Browsers zu verhindern. Chrome unter iOS belässt die Build-Nummer "15E148", anstatt sie vollständig zu entfernen, um die Implementierung in Safari zu verfolgen.
• Opus-Audio wird jetzt für MP4-, Ogg- und WebM-Container unterstützt.
• WebUSB verwendet jetzt den Kontext eines einzelnen Mitarbeiters, was die Produktivität steigern sollte.
• Web Bluetooth funktioniert jetzt unter Windows 10.
• neuer Desktop-Synchronisationsdialog;
• Servicemitarbeiter können benannt werden;
• Die Credential Management API unterstützt jetzt PublicKeyCredential .
• Die ersten Implementierungen von benutzerdefinierten Elementen, HTML-Importen, navigator.getGamepads und der Shadow DOM-API sind jetzt veraltet.
• Lazy Loading kann jetzt mit den Flags # enable-lazy-frame-load und # enable-faul-image-load aktiviert werden .