Die Entwicklung von Serendipity im Zeitraffer und Optimierungsversuche mit Gource

Drüben bei gnulinux.ch bin ich über Gource gestolpert. Gource braucht man nur ein Git-Repository zu geben, damit es aus der der dort gespeicherten Aufzeichung ein Video mit einer Visualisierung der Entwicklung erstellt. Tatsächlich kannte ich die Visualisierung aus einem Youtubevideo, aber ich hatte keine Ahnung, dass sie mit frei verfügbarer Linxusoftware erstellt wurde. Und mir gefiel die Konfiguration der Darstellung, die im Artikel vorgeschlagen wird.

Das ist die nicht ganz komplette Entwicklung von Serendipity:

Ich finde es toll zu sehen, wie viele Entwickler da am Wirken waren und wie Garvin von der Software ins Zentrum gestellt wird. Und natürlich bereitet es ganz besonders Freude, wenn der eigene Name auftaucht und den Dateibaum verändern beginnt.

So ein Video zu erstellen ist einfach. Gource war auch bei Void Linux in den Quellen. Einmal installiert, muss nur das Git-Verzeichnis erstellt, darein gewechselt, Gource gestartet und die Ausgabe an FFmpeg übergeben werden:

git clone git@github.com:s9y/Serendipity.git Serendipity.git
cd Serendipity.git
gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 18 gource.mp4

Tatsächlich habe ich aber viel Zeit in den Versuch versenkt, das zu optimieren. Ich wollte FFmpeg statt .mp4 erst .ogv und dann .webm mit VP9 erstellen lassen. Denn das mit H.264 gebaute und oben eingebundene .mp4 ist immerhin 77 MB groß.

Übrigens das erste mal seit langer Zeit, dass ich mir einen stärkeren Prozessor gewünscht habe. Videos zu enkodieren ist einfach heftig. Aber auch beeindruckend, dass die 4GB große .ppm problemlos auf unter 100MB gebracht werden kann.

Beim Versuch, eine kleinere Datei als die obige für diesen Artikel zu erhalten, orientierte ich mich an der Dokumentation von FFmpeg und den Hinweisen von Google. Aber die Videos waren entweder größer oder mit mehr sichtbaren Kompressionsartefakten. Und das selbst bei der Two-Pass-Enkodierung, die ich so versuchte:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o gource.ppm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 1 -row-mt 1 -an gourceq37.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 2 -row-mt 1 -an gourceq37.webm

Das produzierte relativ große Dateien (hier 130MB), während die Google-Vorgaben sehr kleine (22MB), aber deutlich sichtbar komprimierte Videos erstellten:

ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4-y gource_google.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4 gource_google.webm

Kein guter Startpunkt.

Die Single-Pass-Kodierung ist laut der Dokumentation nicht empfohlen, und tatsächlich lässt sich mit ihr zwar etwa die gleiche Größe erreichen:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libvpx-vp9  -preset medium -pix_fmt yuv420p -crf 30 -row-mt 1 gource.webm

Aber das Video sieht ein bisschen schlechter aus. Und mit schlechterer Qualitätsstufe (hier 35) leidet die Darstellung dann deutlich:

Wenn ich mir die Dateigrößen und die Qualität von ja oft deutlich längeren Youtube-Videos anschaue glaube ich, dass das besser gehen müsste.

Kommt VP9 generell schlecht mit dem Blur zurecht? Oder ist der Kodierer in FFmpeg subobtimal? Gibt es doch einen Weg, die Komprimierung des .mp4-Video bei visuell gleicher Qualität zu schlagen?