WebM in AVIF umwandeln

Ein Shopware-Theme, ein selbst gebautes Shop-Frontend, eine Landingpage mit einem Erklärvideo als Poster-Bild — überall dort, wo jemand in der Google Search Console auf eine Kennzahl für Ladezeit oder Layoutverschiebung starrt, ist AVIF die richtige Antwort. Der Unterschied zu WebP ist real, aber er kostet: Encodierzeit auf dem eigenen Rechner und ein Fallback im Markup, den WebP nicht braucht.

Ohne dieses Budget lohnt sich der Umweg nicht. Ein WebP aus demselben Frame ist kleiner als ein JPG, entsteht sofort und läuft überall ohne `<picture>`-Konstrukt. Wer nur einmal ein Vorschaubild für eine interne Präsentation braucht, ist mit WebP schneller fertig und hat am Ende praktisch dieselbe Datei in der Hand.

AVIF ist kein eigenständiges Bildformat, sondern ein einzelnes AV1-Schlüsselbild in einer HEIF-ähnlichen Hülle. AV1 wiederum ist einer der Codecs, die ein WebM tragen kann — moderne Bildschirmaufnahmen und viele Screencast-Tools aus dem Open-Source-Umfeld schreiben inzwischen direkt AV1 statt VP9.

Steckt im WebM also schon AV1, wird ein Bild decodiert, das AV1 erzeugt hat, und derselbe Codec kodiert es als Standbild neu. Das ist kein verlustfreier Rundweg — dazwischen liegt ein vollständig dekodiertes Pixelraster —, aber die Artefakte des ersten Durchgangs sind genau die Muster, die der zweite Durchgang am effizientesten beschreibt.

Ein JPG oder ein WebP erscheint praktisch augenblicklich. Ein AVIF braucht Sekunden, und bei einem 4K-Frame auf einem älteren Notebook eher mehrere. Das liegt nicht am Browser, sondern daran, wie AV1 arbeitet: Der Encoder probiert eine große Zahl möglicher Beschreibungen für jeden Bildblock aus, bevor er die günstigste wählt.

Für eine Datei, die millionenfach ausgeliefert wird, ist das eine gute Investition. Für dreißig Frames, die man nacheinander umwandelt und dabei zusieht, ist es eine schlechte — dann ist WebP für die Masse der richtige Weg und AVIF bleibt dem einen Bild oben auf der Seite vorbehalten.

Der Frame kommt in der originalen Pixelgröße des Videos heraus, nicht skaliert, bei einer fest eingestellten Qualität von 82. Eine 1080p-Aufnahme ergibt ein AVIF mit 1920 mal 1080 Pixeln, eine 4K-Aufnahme entsprechend die vierfache Fläche und eine deutlich längere Wartezeit.

Die einzige Einstellung auf dieser Seite ist die Sekunde, ab der das Bild genommen wird. Verkleinern lässt sich später besser — die eigene Build-Pipeline kennt die Breiten, die das Layout tatsächlich braucht, und arbeitet von einem vollen Frame aus präziser als von einem bereits verkleinerten.

Aktuelle Versionen von Chrome, Edge, Firefox und Safari zeigen AVIF an, aber die Unterstützung kam Jahre nach WebP, und ältere Geräte ohne Updates bleiben im Umlauf — gerade bei Firmenrechnern, die selten aktualisiert werden.

Die übliche Lösung ist ein `<picture>`-Element mit einer AVIF-Quelle, einer WebP-Quelle und einem JPG als `<img>` am Ende. Drei Zeilen, kein JavaScript, der Browser wählt selbst die erste Variante, die er versteht. Wer diese Struktur ohnehin für andere Bilder pflegt, reiht den Frame einfach ein.

Ein Standbild aus einem komprimierten Video trägt alles mit, was der Videocodec ihm angetan hat: Bits, die in Bewegung investiert wurden statt in Schärfe, Farbe, die nur mit halber Auflösung gespeichert ist, und ein Moment mitten in einer Kamerafahrt, der nie scharf kodiert wurde. AVIF verpackt das alles sehr effizient — es holt nichts davon zurück.

Deshalb entscheidet der Zeitpunkt mehr als das Format. Ein Frame aus einem ruhigen Moment als AVIF schlägt einen Frame mitten in Bewegung in jeder Hinsicht, auch bei der Dateigröße, weil eine verwischte Aufnahme voller Details ist, die der Encoder erst mühsam beschreiben muss. Den Moment zu wählen ist die eigentliche Optimierung.

Alles, was keine Webseite ist. E-Mail-Programme rendern es nicht, Office-Anwendungen meist auch nicht, Druckvorstufen ebenso wenig. Upload-Formulare fremder Seiten lehnen die Endung häufig direkt ab, und ein Kollege, dem man eine AVIF-Datei schickt, fragt in der Regel zurück, was das für ein Format sei.

Der ganze Nutzen von AVIF hängt daran, von einem Browser dekodiert und über eine bezahlte Netzwerkverbindung ausgeliefert zu werden. Für eine Folie, ein Dokument oder eine Nachricht bleibt das JPG die richtige Wahl, für ein Archiv oder einen Druckauftrag das TIFF.

AVIF definiert einen verlustfreien Modus, aber diese Seite fragt ihn nie an — die feste Qualität von 82 gilt für jedes Bild, egal wie flach oder detailreich es ist. Das ist beim Konvertieren eines Videostandbilds ohnehin kein Verlust: Der Frame war bereits verlustbehaftet komprimiert, bevor er das WebM verließ, und eine verlustfreie AVIF-Datei davon wäre nur eine größere Kopie derselben Ungenauigkeit.

Für ein grafisches Element ohne fotografischen Inhalt — ein Icon, ein Screenshot einer Oberfläche mit wenigen Farben — liefert PNG in diesem Fall das ehrlichere Ergebnis, weil es tatsächlich verlustfrei ist und bei flachen Flächen oft kleiner bleibt als ein AVIF bei Qualität 82.

Eine Bildschirmaufnahme, die eine neue Funktion vorführt, liefert selten nur einen brauchbaren Moment. Für ein Changelog oder eine Ankündigungsseite braucht man oft drei oder vier Standbilder aus derselben Aufnahme — den Ausgangszustand, den Klick, das Ergebnis.

Jede Umwandlung ist ein eigener Durchlauf mit eigenem Zeitstempel, und weil nichts hochgeladen wird, kostet ein Versuch nur Sekunden auf dem eigenen Rechner statt eine Warteschlange bei einem fremden Dienst. Für eine ganze Bildstrecke aus vielen einzelnen Momenten ist dennoch ein Kommandozeilenwerkzeug mit fester Bildrate die passendere Wahl — diese Seite ist für den einen gewählten Moment gebaut, nicht für hundert automatisch entnommene.

Die Bildpipeline dieser Seite decodiert jedes Quellbild zu einem reinen Pixelraster und übergibt an den Encoder ausschließlich diese Pixel und die Qualitätszahl — kein ICC-Profil geht mit hinein. Das AVIF kommt deshalb ohne eingebettetes Farbprofil an, unabhängig davon, was das WebM selbst an Farbraum-Information trug.

Für eine gewöhnliche Bildschirmaufnahme in sRGB fällt das nicht auf. Bei Videomaterial aus einer professionellen Kamera mit einem breiteren Farbraum kann ein Betrachter ohne Profil die Farben etwas anders zeigen, als sie gemeint waren — ein Punkt, der selten den Screencast betrifft, für den diese Seite meistens genutzt wird, aber es wert ist, einmal genannt zu werden.

Decodierung und AVIF-Encodierung laufen vollständig im Tab, mit den Codecs, die der Browser ohnehin mitbringt. Es gibt keinen Server, an den die Bildschirmaufnahme geschickt wird, und im Netzwerk-Tab lässt sich das in ein paar Sekunden selbst nachprüfen.

Das ist mehr als eine Formalität, wenn die Aufnahme ein internes Dashboard, ein Kundenprojekt oder eine noch unveröffentlichte Oberfläche zeigt — genau das Material, das üblicherweise als WebM-Screencast entsteht und das niemand versehentlich bei einem fremden Anbieter landen lassen möchte, nur um ein einzelnes Vorschaubild zu bekommen.