MKV in WebM umwandeln

Ein Verein, eine Kanzlei oder ein kleiner Betrieb, der ein Video auf der eigenen Seite zeigen will, landet fast automatisch bei YouTube oder Vimeo — und damit bei einem eingebetteten Player, der beim ersten Laden Cookies eines fremden Anbieters setzt. Das zieht einen Consent-Banner nach sich, der vorher gar nicht nötig gewesen wäre, und eine Datenschutzerklärung, die den Drittanbieter erklären muss.

Ein selbst gehostetes WebM umgeht das komplett: Es liegt auf dem eigenen Server, im `<video>`-Element eingebunden, ohne dass beim Seitenaufruf eine Verbindung zu einer fremden Plattform aufgebaut wird. Der Preis dafür ist, dass man die Datei selbst in ein Format bringen muss, das der Browser abspielt — und genau das macht diese Seite.

WebM ist keine eigene Erfindung, sondern Matroska mit einer stark eingeschränkten Auswahl: nur VP8, VP9 oder AV1 für das Bild, nur Opus oder Vorbis für den Ton. Eine WebM-Datei ist technisch eine gültige MKV-Datei, nur mit der Zusicherung, dass der Inhalt aus dieser kleinen Liste stammt.

Diese Einschränkung ist der ganze Sinn der Sache. Ein Browser, dem eine beliebige MKV-Datei vorgelegt wird, kann nicht wissen, ob darin H.265, DTS oder ein Codec aus dem letzten Jahrzehnt steckt, und lehnt die Wiedergabe deshalb komplett ab. Bei WebM weiß er von vornherein, womit er es zu tun hat.

Wer ein Video mit yt-dlp oder einem ähnlichen Werkzeug herunterlädt, bekommt für die besten verfügbaren Streams häufig eine MKV-Datei, weil VP9 oder AV1 zusammen mit Opus-Ton nicht in eine MP4 passen. Die Datei trägt also schon fast das, was WebM verlangt — nur eben in einer Hülle, die kein Browser direkt einbettet.

Wer dagegen mit einer Kamera oder einem Bildschirmrekorder aufgenommen hat, bekommt in der Regel H.264 in der MKV, und dieser Fall ist der häufigere auf dieser Seite: aus H.264 wird hier VP9, nicht kopiert, sondern neu berechnet.

Selbst wenn die MKV bereits VP9-Bild und Opus-Ton enthält, wird hier nichts einfach durchgereicht: Jedes Bild wird decodiert und wieder neu kodiert. Das kostet eine zusätzliche Generation Bildqualität, auch wenn Quell- und Zielcodec identisch heißen — bei ruhigen Aufnahmen kaum sichtbar, bei Bewegtwasser oder starkem Filmkorn schon.

Steht MediaInfo oder ein ähnliches Werkzeug zur Verfügung und zeigt VP9 und Opus in der Quelle an, ist ein reiner Stream-Copy mit ffmpeg oder MKVToolNix in Sekunden fertig und verlustfrei. Diese Seite lohnt sich, wenn die Quelle etwas anderes ist, das Bild ohnehin verkleinert werden soll, oder kein Werkzeug installiert werden soll.

Matroska erlaubt mehrere Tonspuren gleichzeitig, und WebM erbt diesen Platz: Jede Spur, die der Browser decodieren kann, wird mitgenommen, in der Reihenfolge, in der sie in der Datei stand. Bei einer heruntergeladenen Aufnahme ist meist nur eine Spur vorhanden, bei einer zweisprachigen Aufzeichnung können es mehr sein.

Untertitelspuren dagegen werden nicht übernommen — nicht weil sie verweigert werden, sondern weil dieser Umwandler nur Bild- und Tonspuren liest. Für eine selbst gehostete Seite ist das kein echter Verlust: Eine WebVTT-Datei über ein `<track>`-Element ist ohnehin die bessere Lösung, weil sie durchsuchbar und gestaltbar ist.

Bevor irgendetwas umgewandelt wird, prüft der Browser für jede Tonspur, ob er sie decodieren kann. Kann er es nicht, wird die Spur verworfen, das Bild läuft trotzdem weiter, und am Ende steht eine WebM ohne Ton — ohne dass währenddessen etwas darauf hinweist.

Eine heruntergeladene MKV mit Opus oder AAC ist davon nie betroffen. Eine MKV von einer DVD oder Blu-ray trägt dagegen häufig AC-3, DTS oder Dolby TrueHD, und für diese Codecs bringt kein Browser einen Decoder mit. Wer Material dieser Herkunft konvertiert, sollte die WebM vor der Veröffentlichung einmal mit Ton abspielen.

Für ein eingebettetes Video zählt die Auflösung mehr als die Qualitätsstufe. Eine 4K-Quelle auf 1080p verkleinert entfernt drei Viertel der Pixel und mit ihnen den Großteil der Bytes — und für ein Video, das ohnehin nur in einer 700 Pixel breiten Spalte angezeigt wird, sind alle Pixel darüber verschenkte Übertragung.

Die Einstellung verkleinert dabei ausschließlich; wird eine größere Auflösung angefordert als die Quelle hat, bleibt sie unverändert. Bei einem dekorativen Hintergrundvideo genügt oft 720p in der kleinsten Qualitätsstufe, ohne dass der Unterschied auf der Seite auffällt.

Decodierung und VP9-Kodierung laufen vollständig im Browser-Tab; nichts, was das Video enthält, wird irgendwohin gesendet. Das lässt sich im Netzwerk-Tab des Browsers während der Umwandlung nachprüfen. Es gibt kein Konto, keine Warteschlange fremder Nutzer und keinen Server, der die Datei je zu Gesicht bekommt.

Genau das ist die Voraussetzung dafür, dass die fertige Seite mit dem selbst gehosteten Video ohne Consent-Abfrage für ein Drittvideo auskommt — die Umwandlung selbst hat schon keinen Drittanbieter im Spiel, und die Auslieferung später ist reine Serverkonfiguration.

VP9 verlangt dem Prozessor mehr ab als H.264, und Hardware-Encoder dafür sind seltener verbaut, sodass der Browser häufiger auf eine Software-Kodierung ausweicht — die Wartezeit fällt entsprechend länger aus, als es die Dateigröße vermuten lässt.

Dafür braucht VP9 bei gleicher sichtbarer Qualität meist spürbar weniger Bytes als H.264, und ein Video auf einer Vereins- oder Kanzleiseite wird in der Regel weit öfter abgerufen als es kodiert wird. Die einmalige Wartezeit kauft man sich bei jedem weiteren Seitenaufruf zurück.

Bis zu 100 Dateien lassen sich gleichzeitig ablegen, mit einer Obergrenze von 100 MB je Datei in der kostenlosen Stufe, und alle Ergebnisse kommen als ein ZIP zurück. Bei einem Vereinsarchiv mit mehreren älteren Mitschnitten spart das, jede Datei einzeln durchzugehen.

Eine Warteschlange gibt es nicht, weil kein fremder Nutzer denselben Server belastet — jede Datei wird auf dem eigenen Prozessor kodiert, nacheinander, mit sichtbarem Fortschritt je Datei. Bei einer Serie langer Aufnahmen bedeutet das schlicht eine längere Wartezeit, keine Warteposition hinter anderen.

Ein bei YouTube oder Vimeo eingebettetes Video kostet die Bandbreite nichts, weil die Plattform sie trägt — im Gegenzug bekommt sie die Werbe- und Nutzungsdaten der Besucher. Ein selbst gehostetes WebM verschiebt diese Rechnung auf den eigenen Webspace, und bei einem vielbesuchten Video mit mehreren Megabyte ist das ein Posten, den man kennen sollte, bevor man sich dafür entscheidet.

Für ein Vereins- oder Kanzleivideo mit überschaubarer Besucherzahl ist das selten ein Problem, zumal WebM ohnehin kleiner ausfällt als eine MP4 gleicher Qualität. Bei einem Video, das viral gehen könnte oder dauerhaft stark frequentiert wird, lohnt sich vorher ein Blick auf das eigene Datenvolumen-Kontingent beim Hoster.

Ein `<video>`-Element kann mehrere `<source>`-Einträge auflisten, und der Browser nimmt den ersten, den er abspielen kann. Wer die WebM zuerst und eine MP4 danach angibt, bekommt für aktuelle Browser die kleinere Datei und verliert trotzdem niemanden, dessen Browser VP9 nicht beherrscht.

Aktuelle Versionen von Chrome, Edge, Firefox und Safari spielen VP9 und Opus in WebM problemlos ab; ältere Safari-Versionen auf älterer Hardware sind die zuverlässige Ausnahme. Für eine öffentliche Seite lohnt sich die zusätzliche Zeile im Markup fast immer.