WebM- und MP4-Videoloops für Websites optimieren

Kurz als Merkhilfe für mich selbst, vielleicht aber auch für andere nützlich: Wenn ich kurze Videoloops auf einer Website einsetze, kodiere ich aus der Quelldatei in der Regel drei Versionen, damit das Ganze möglichst kompatibel zu vielen Browsern bleibt (wie auch hier kurz beschrieben): MP4 (AVC/H.264), OGV und WebM.

Doch selbst wenn man im Editor die Schnittstelle ideal setzt und der Loop, der nur aus einer Einstellung besteht, an sich absolut flüssig und ohne verräterischen Ruckler läuft, heißt das noch nicht, dass das auch für die aus dem Rohclip kodierte Webversion gilt. Gerade bei WebM kann es mit falschen Einstellungen zu deutlichen Blockartefakten kommen, die am Ende des Videoclips so stark sind, dass es sofort auffällt, wenn der Loop relativ artefaktfrei wieder von vorn anfängt.

Für WebM kann ich nach ausgiebiger Suche und reichlich Testerei folgende Settings mit dem Kommandozeilen-Tool ffmpeg empfehlen:

ffmpeg -i quelldatei.mov -framerate 25 -c:v libvpx-vp9 -b:v 0 -pix_fmt yuv420p -crf 40 -cpu-used 1 -tile-columns 2 -threads 8 -row-mt 1 -vf scale=850:478 zieldatei.webm

Fundstelle: .webm blocky in initial frames, terrible for looping :(

Aus einer ursprünglichen Beispiel-Quelldatei (Full HD, 6 Sekunden, Apple ProRes, keine Tonspuren) mit einer Größe von ca. 29 Megabyte wird der Clip mit den obigen Settings und dem VP9-Codec auf 210 Kilobyte reduziert. Die finale WebM-Videodatei hat eine Größe von 850 x 478 Pixel (16:9), bei der an keiner Stelle die für Loops problematischen Blockartefakte auftreten:

Vermutlich wird dieses WebM-Beispielvideo auf vielen mobilen Endgeräten nicht angezeigt.

Die einzelnen Parameter werden hier recht anschaulich erklärt. Ein Constant Rate Factor (CRF) von 40 scheint mir ein guter Kompromiss zwischen Qualität und tolerabler Größe zu sein. Kleinere Faktoren ergeben eine bessere Qualität, dafür aber größere Dateien. Ein CRF-Maximalwert von 63 würde das Video auf 34 Kilobyte quetschen, aber die visuelle Qualität wäre indiskutabel. Oder Kunst.

Für die MP4-Version nutze ich in der Regel ffmpeg mit diesen Parametern:

ffmpeg -i quelldatei.mov -vcodec h264 -vb 400k -pix_fmt yuv420p -vf scale=850:478 zieldatei.mp4

Vermutlich wird dieses MP4-Beispielvideo auf vielen mobilen Endgeräten nicht angezeigt.

Wegen der gewählten Bitrate von 400 KBit/s ist die MP4-Variante mit 222 Kilobytes von vergleichbarer Qualität. Bei Bildern ohne komplexe Hintergründe und mit wenig Bewegung reichen 200 KBit/s völlig aus.

Ogg Theora, WebM und MP4-Video für HTML5 mit FFmpeg kodieren

Als Notiz zum Nachschlagen an mich selbst (und für alle, die es auch gebrauchen können): Um selbst gehostete Videos in allen möglichen Browsern abspielen zu können, braucht man – wenn man es möglichst sauber umsetzen will – mehrere verschiedene Versionen, die aus ein und derselben Quelldatei generiert werden.

Wenn nicht schon geschehen, sollte man sich als MacOS-Nutzer zuerst einmal Homebrew installieren, anschließend FFmpeg mit zusätzlichen Bibliotheken. Also Terminal öffnen und

brew install ffmpeg --with-fdk-aac --with-ffplay --with-freetype --with-libass --with-libquvi --with-libvorbis --with-libvpx --with-opus --with-x265 --with-theora

eingeben. Nur falls FFmpeg bereits zuvor in einer minimalen Konfiguration installiert war, muss man es vor der erneuten Installation löschen mit

brew uninstall ffmpeg

Sollte die Installation also geklappt haben, werden die Videos wie folgt kodiert (in diesem Fall alle mit 5000 Kbps für den Videostream und 128 Kbps für den Audiostream)…

Ogg Theora:

ffmpeg -i quelldatei.mov -c:v libtheora -c:a libvorbis -b:v 5120k -b:a 128k -ar 44100 -vf scale=1920:1080 zieldatei.ogg

WebM:

ffmpeg -i quelldatei.mov -vcodec libvpx -b:v 5120k -c:a libvorbis -ac 2 -b:a 128k -ar 44100 -vf scale=1920:1080 zieldatei.webm

MP4:

ffmpeg -i quelldatei.mov -vcodec h264 -vb 5120k -acodec aac -ab 128k -pix_fmt yuv420p zieldatei.mp4

Um Homebrew und FFmpeg künftig auf dem laufenden zu halten:

brew update && brew upgrade ffmpeg

Anwendung natürlich auf eigene Gefahr.

Video-Uploads auf Twitter vom Desktop ist Raketenwissenschaft – Lösung: FFmpeg und Safari

Gerade Stunden damit zugebracht, ein Video vom Browser auf Twitter hochzuladen. Mit Firefox war es generell unmöglich, mit TweetDeck ebenfalls, mit Safari ging’s dann. Aber nur, wenn das Video sich in den sehr engen technischen Vorgaben bewegt, die Twitter vorgibt.

Als Notiz an mich selbst (und für alle, die ein ähnliches Problem haben und mit MacOS arbeiten):

  1. Video aus dem Schnittprogramm exportieren (in meinem Fall eine Masterdatei in FullHD mit ProRes422 in einem MOV-Container verpackt)
  2. Terminalfenster öffnen und ffmpeg mit folgender Kommandozeile nutzen

ffmpeg -i quelldatei.mov -r 25 -vcodec libx264 -b:v 2M -vf 'scale=1280:trunc(ow/a/2)*2' -pix_fmt yuv420p -strict -2 -acodec aac zieldatei.mp4

FFmpeg generiert nun aus dem ProRes422-Master eine mit H.264 enkodierte Datei, die mit 25 Bildern pro Sekunde läuft, skaliert sie herunter auf 1280 x 720 Pixel, nutzt für den Sound AAC und verpackt alles zusammen mit einer angemessenen Rate von 2000 Kbit/s. Wichtig ist, dass aus der Quelldatei eine Zieldatei mit YUV-Farbraum, 4:2:0 Chroma-Subsampling und 8 Bit Farbtiefe generiert wird – alles andere lehnt Twitter (Stand heute) ab.

Wer FFmpeg nicht installiert hat, dem empfehle ich, sich zunächst Homebrew und anschließend FFmpeg nach dieser Anleitung zu installieren. Wer viel mit Videokodierung zu tun hat, sollte nicht auf dieses Schweizer Messer verzichten. Vor allem, wenn man gelegentlich auf Twitter hochlädt und nicht auf iOS/Android-Apps angewiesen sein will.