MOV in WebM umwandeln

Ein YouTube- oder Vimeo-Player auf der eigenen Seite lädt beim Aufruf Skripte einer fremden Plattform nach, die Cookies setzt und die IP-Adresse der Besucherin an einen Server in den USA schickt — noch bevor irgendjemand auf Play gedrückt hat. Für einen einfachen Hintergrundloop auf einer Landingpage oder ein kurzes Showreel ist das ein unnötiger Cookie-Banner für etwas, das genauso gut eine eigene Datei sein könnte.

Diese Seite macht aus dem Schnittexport oder dem Kameraclip eine WebM-Datei, die direkt im eigenen HTML liegt: kein Drittanbieter, kein Consent-Layer nur fürs Video, keine Anfrage, die vor jeder Einwilligung losläuft. Die Umwandlung läuft dabei im Browser-Tab, sodass ein unveröffentlichter Schnitt gar nicht erst irgendwohin geschickt wird.

Das muss zuerst gesagt werden, weil es der Grund ist, den die meisten Gestalter nennen. Ein Logo-Sting, eine animierte Bauchbinde, ein Produkt, das über der Seite zu schweben scheint — solche Clips liegen als ProRes 4444 mit Alphakanal in einer QuickTime-Datei vor, und der naheliegende Gedanke ist, daraus ein transparentes VP9 in WebM zu machen.

Das geht hier nicht. Die Umwandlung verwirft den Alphakanal, das Ergebnis ist also deckend; und in der Praxis lässt sich eine ProRes-4444-Datei im Browser meist ohnehin nicht dekodieren, sodass die Umwandlung schon vorher scheitert. Transparentes WebM braucht ein Werkzeug, das den Kanal schreiben kann — einen eigenen ffmpeg-Aufruf oder ein Exportprofil mit WebM-Erweiterung. Das MOV bleibt der Master, das transparente WebM kommt aus der Software, die es geschnitten hat.

Bild und Ton werden immer zu VP9 und Opus. Statt einer Zahl in Kilobit wird eine Qualitätsstufe gewählt — niedrig, mittel oder hoch —, und die Umwandlung übersetzt das intern in eine Bitrate, die für VP9 passt. Welche Kilobit-Zahl hinter welcher Stufe steckt, ist nicht öffentlich dokumentiert und wird hier deshalb auch nicht behauptet.

Diese Ersparnis ist real, und sie ist kleiner als die Ersparnis, die eine niedrigere Auflösung bringt — der Regler, den die meisten unangetastet lassen. Ein 4K-Master auf 1080p heruntergerechnet entfernt drei Viertel der Pixel, bevor der Codec überhaupt anfängt; ein Loop, der auf der Seite nur 400 Pixel hoch angezeigt wird, gewinnt nichts davon, in 2160p vorzuliegen.

Das ist die praktische Hürde bei dieser Aufgabe. Die kostenlose Stufe nimmt Dateien bis 100 MB — ein ProRes-Master eines dreißigsekündigen Titels kann mehrere Gigabyte groß sein, und selbst ein H.264-Kameraoriginal in 4K liegt bei rund 350 MB pro Minute.

Die Lösung ist ein kleinerer Zwischenexport aus dem Schnittprogramm: ein 1080p-H.264-Export mit moderater Bitrate ist ein Bruchteil des Masters, lässt sich im Browser zuverlässig dekodieren und gibt dem VP9-Encoder ein gutes Ausgangsbild. Den Clip auf die tatsächlich loopenden Sekunden zu kürzen, spart meist mehr als jede Encoder-Einstellung.

Beide Dateien in ein video-Element setzen, WebM zuerst und MP4 danach, und der Browser wählt selbst. Browser nehmen die erste Quelle, die sie dekodieren können — ein aktueller Browser nimmt das WebM, alles andere fällt auf das MP4 zurück. Das ist eine Zeile Markup mehr und der Unterschied zwischen einer echten Ersparnis und einem Video, das bei manchen Besuchern gar nicht lädt.

Bei einem Hintergrundloop zählen die übrigen Attribute genauso: muted, playsinline, loop, und preload auf metadata statt auto, damit das Video nicht mit dem Text um die erste Sekunde der Verbindung konkurriert. Ein Vorschaubild — ein Standbild aus demselben MOV — zeigt sich, während all das im Hintergrund geregelt wird.

Am Handy gedrehte Aufnahmen tragen ein Rotationsflag statt gedrehter Pixel, und Matroska-basierte Container wie WebM haben keinen Platz für ein solches Flag. Die Umwandlung dreht das Bild deshalb wirklich und schreibt ein aufrechtes Video — genau das, was gebraucht wird, wenn die Datei auf einer Seite landet, deren Wiedergabe man nicht selbst steuert.

Zu prüfen bleibt danach das Seitenverhältnis im CSS. Ein Clip, der sich als 1920 mal 1080 mit Rotationsflag meldete, wird zu einem echten 1080-mal-1920-WebM, und ein für Querformat gestylter Container zeigt es dann mit hässlichen schwarzen Balken. Die Maße der fertigen Datei nachprüfen, nicht die, die die Kamera behauptet hat.

Einen VP9-Encoder liefert das Betriebssystem, nicht diese Seite. Auf so gut wie jedem aktuellen Rechner haben Chrome, Edge und Safari einen; manche Firefox-Installationen, besonders unter Linux, nicht — und die Seite sagt das, bevor eine Datei gewählt wird, statt mitten in der Kodierung abzubrechen.

Die andere Hälfte betrifft die Quelle. Ein ProRes- oder 10-Bit-Log-MOV braucht einen Decoder, den der Browser sehr wahrscheinlich nicht hat, und die Umwandlung stoppt mit einer Meldung, dass nichts in der Datei umgewandelt werden konnte. Es gibt keine Software-Ausweichlösung: ein zu WebAssembly kompilierter Codec ist mehrere Dutzend Megabyte groß und um ein Vielfaches langsamer als die Hardware direkt daneben.

Bild und Ton, sonst nichts. Ein QuickTime-Export kann eine Timecode-Spur, Kapitelmarken, Untertitelspuren und Schnitt-Metadaten tragen, und keins davon wird gelesen. Für einen Hintergrundloop spielt das keine Rolle; für einen selbst gehosteten Vortrag mit Kapiteln bedeutet es, dass die Kapitel als Daten auf der Seite neu aufgebaut werden müssen.

Untertitel sind der Punkt, den man einplanen sollte. Ein selbst gehostetes WebM verdient ein track-Element mit einer VTT-Datei, was ohnehin die bessere Praxis ist als eine eingebettete Spur — es lässt sich indexieren, übersetzen und bearbeiten, ohne das Video neu zu kodieren.

Dekodierung und VP9-Kodierung laufen beide in diesem Tab, mit den Codecs, die das Gerät ohnehin hat. Nichts, was das Video trägt, geht nach außen, und der Netzwerk-Tab bestätigt es während der Umwandlung.

Für ein Material, das noch nicht öffentlich ist — ein Produkt vor dem Launch, eine Kundenpremisse, ein Showreel unter Sperrfrist —, ist das kein Nebeneffekt. Der übliche Weg wäre, die Datei bei einem aus einer Suche gewählten Konverter hochzuladen, was ein unveröffentlichtes Gut auf einen ungeprüften Server bringt. Hier bleibt es auf dem eigenen Gerät, und die Kodierung läuft mit der Geschwindigkeit des eigenen Prozessors statt der der Upload-Leitung.