WebM in WebP umwandeln

Ein Bild, das auf einer Webseite landet, wird nach anderen Maßstäben beurteilt als eines, das jemand in einem Betrachter öffnet. Niemand schaut es sich einzeln an; es ist eines von zwanzig Dingen, die ein Browser lädt, während jemand entscheidet, ob er bleibt. Seine Größe in Kilobyte ist ein realer Preis, den jeder Besucher zahlt, und das Format muss eines sein, das das CMS, der Build-Schritt und der Browser ohne Sonderbehandlung annehmen.

Das ist das ganze Argument für WebP statt JPG an dieser Stelle: dasselbe sichtbare Ergebnis, rund dreißig Prozent weniger Bytes, und universelle Unterstützung in aktuellen Browsern. Bei einem Raster von einem Dutzend Video-Vorschaubildern ist das ein Drittel des Bildgewichts weniger, ohne sichtbaren Unterschied.

WebP und WebM stammen aus demselben Projekt. Google veröffentlichte beide um 2010 als lizenzfreie Antworten auf patentbelastete Formate, und die Standbild-Kompression von WebP wuchs aus der Intra-Frame-Kodierung von VP8 heraus — dem Videocodec, auf dem WebM aufbaut. Ein Standbild aus einer WebM-Datei zu ziehen und als WebP zu schreiben, ist damit eher eine Familienähnlichkeit als eine Übersetzung.

Verlustfrei macht das die Umwandlung trotzdem nicht: Der Frame wird bis auf die Bildpunkte dekodiert und mit fester Qualität von 82 neu kodiert. Was die Verwandtschaft bringt, ist, dass die Art Detail, die der Videocodec behalten hat, genau die Art ist, in der der Standbild-Encoder gut ist.

Mobiles Internet ist in Deutschland regional sehr unterschiedlich, und viele Tarife sind für Verhältnisse großer Datenmengen eher knapp bemessen. Wer außerhalb einer Großstadt oder im Zug unterwegs ist, spürt dreißig Prozent weniger Bilddaten direkt in der Ladezeit — und in manchen Tarifen im verbleibenden Datenvolumen.

Für ein Vorschaubild, das ohnehin nur einen kurzen Eindruck vermitteln soll, ist das ein klarer Vorteil ohne Nachteil: Der Besucher sieht dasselbe Bild, nur schneller und mit weniger verbrauchtem Datenvolumen. Das ist der Grund, warum sich die dreißig Prozent hier lohnen, obwohl das einzelne Bild klein wirkt.

Das Naheliegendste mit dieser Umwandlung: ein Frame aus der WebM-Datei nehmen und als deren poster-Attribut einsetzen. Ein Browser zeigt das Poster, bis die Wiedergabe beginnt, also sieht der Besucher zuerst ein echtes Standbild aus dem Video statt eines schwarzen Rechtecks oder eines unpassenden Platzhalters.

Am besten wird der Frame etwa eine Sekunde nach dem Start genommen, nicht bei null. Das allererste Bild einer Aufnahme ist oft eine Überblendung, ein leerer Zustand oder eine noch ladende Seite — und genau das Bild, das das Video ohnehin als Erstes zeigt. Ein Poster aus einem späteren Moment gibt dem Betrachter etwas zu sehen, ohne einen sichtbaren Sprung beim Start.

Der Frame kommt in den eigenen Pixelmaßen des Videos heraus, ohne Skalierung. Eine 1080p-Aufnahme ergibt ein 1920 mal 1080 Pixel großes WebP, eine 4K-Aufnahme entsprechend 3840 mal 2160. Das ist beabsichtigt — ein Frame hat eine reale Auflösung, und diese Umwandlung soll ihn unverändert übergeben, statt eine Anzeigegröße zu erraten.

Das Skalieren gehört weiter unten in die Kette. Was auch immer das srcset erzeugt, die Bildpipeline des CMS oder der Build-Schritt weiß bereits, welche Breiten das Layout braucht, und macht daraus mit einer Vollauflösungsquelle bessere Arbeit als mit einer bereits verkleinerten.

Das Bild in einer WebM-Datei wurde für Bewegung kodiert. Ein Videocodec setzt seine Bits dort ein, wo sich etwas bewegt, und spart, wo nichts sich ändert, in der Annahme, dass niemand ein einzelnes Bild anstarren wird. Wird eines herausgegriffen, passiert genau das, was der Codec nicht erwartet hat.

Für eine kleine Vorschau bleibt der Effekt gering, weil sie ohnehin verkleinert dargestellt wird. Wichtig wird es, wenn das Standbild groß eingesetzt wird — als Titelbild oder als volle Illustration —, wo ein während eines Schwenks aufgenommener Frame sichtbar unscharf wirkt. Die Lösung ist der Zeitpunkt: einen ruhigen Moment im Video suchen und von dort nehmen.

Browser sind nicht mehr das Problem, der Rest ist es an den Rändern. Manche E-Mail-Programme stellen WebP nicht dar, weshalb ein Newsletter-Vorschaubild besser ein JPG bleibt. Einzelne ältere Desktop-Anwendungen, Druckabläufe und manche Uploadformulare lehnen das Format noch ab. Windows und macOS zeigen es inzwischen problemlos in der Vorschau an, was vor ein paar Jahren noch nicht galt.

Innerhalb eines Browsers gilt WebP als sicher universell, weshalb es hier die pragmatische Wahl ist und nicht AVIF. Geht die Datei woandershin — eine E-Mail, ein Dokument, ein Drucker, ein Formular —, ist das JPG die richtige Wahl und die Überlegung erledigt.

Eine Sammlung von Tutorials braucht je ein Vorschaubild, und das heißt eine Umwandlung pro Video statt pro Bild. Umwandeln, den passenden Zeitpunkt notieren, weiter zur nächsten Datei. Der ganze Zyklus dauert Sekunden, weil zwischen den Versuchen nichts hochgeladen wird und keine Warteschlange existiert.

Es lohnt sich, die Zeitpunkte bewusst zu wählen, statt bei jedem Video null zu übernehmen. Ein Raster aus Vorschaubildern, die alle einen leeren Editor oder einen Ladekreis zeigen, sagt einem Besucher nichts darüber, welches Video welches ist — und genau das liefert die Voreinstellung.

Der Frame taugt für mehr als nur den Poster-Slot. Als og:image im Kopf der Seite hinterlegt, ist es das Bild, das erscheint, wenn ein Link zu einer Seite mit eingebettetem Video in einem Chat oder sozialen Netzwerk geteilt wird — ohne dieses Bild zeigen die meisten Plattformen entweder gar nichts oder ein zufälliges Bild von der Seite.

Wichtig dabei: Nicht jede Plattform, die eine Linkvorschau erzeugt, liest WebP zuverlässig. Für dieses eine Bild lohnt sich deshalb ein Blick in die eigene Analyse-Auswertung oder ein Testlink, bevor man sich darauf verlässt — und im Zweifel bleibt für die Vorschau ein JPG die robustere Wahl, während die WebP-Version auf der Seite selbst bleibt.

Wer regelmäßig Videos veröffentlicht, will diesen Schritt nicht jedes Mal von Hand erledigen. Weil die Umwandlung im Browser läuft, lässt sie sich nicht direkt in einen Server-Build einbinden — wohl aber lässt sich der Zeitpunkt einmal festlegen und dokumentieren, sodass jeder im Team beim Veröffentlichen eines neuen Videos denselben Schritt macht statt bei null zu bleiben.

Für eine echte Automatisierung ohne Browser braucht es ein anderes Werkzeug in der eigentlichen Build-Kette — diese Seite ist der richtige Ort für den einzelnen Fall, für die eine neue Aufnahme, die schnell ein Vorschaubild braucht, ohne dass dafür eine ganze Pipeline aufgesetzt werden muss.

Die Aufnahmen, die ein Vorschaubild brauchen, sind meist noch nicht öffentlich: eine Produktdemo, eine noch nicht angekündigte Funktion, ein Kursmodul. Die ganze Videodatei an einen Konverter zu schicken, nur damit ein 60-Kilobyte-Vorschaubild zurückkommt, ist ein großes Risiko für sehr wenig Arbeit.

Dekodierung und Kodierung laufen beide im Tab, mit Codecs, die der Browser ohnehin für die WebM-Wiedergabe mitbringt. Es wird nichts gesendet, es gibt kein Konto und kein Tageslimit — dreißig Videos umzuwandeln ist damit einfach dreißigmal dieselbe Aufgabe, kein Grund für ein Upgrade auf irgendetwas.