Ich habe einige GigaByte an „Raw“-Filmdateien aus meiner Nikon D3200 (720p, 50 fps, AVC) – Will man diese Daten als Backup sichern, stellt sich zumindest bei einem zusätzlichen Cloud-Backup die Frage, ob es nicht Sinn macht, die Raw-Daten in ein verlustbehaftetes Format zu (re-)encoden.
Folgende Codecs kommen in Frage:
h264 (AVC)
Dies ist der derzeit geläufigste Codec. Vorteile sind seine Schnelligkeit und sehr hohe Kompatibilität. Der Codec ist schon ziemlich alt (fast 20 Jahre) und dadurch im Vergleich nicht sehr effizient.
h265 (HEVC)
wie schon der Name verrät, ist das der Nachfolger von h264. Im Jahr 2013 erschienen und durch seine höhere Komplexität viel effizienter. Allerdings dauert das encoden auch länger.
av1 (av1-AOM und av1-SVT)
Der relativ neue Codec aus dem Jahr 2019 schlägt in Effizienz wiederum h265, die Encode-Zeiten sind je nach Setting und verwendetem Encoder allerdings noch einmal deutlich länger. Youtube und Netflix benutzen diesen Codec schon bei ausgewähltem Content und auf ausgewählten Devices.
Testvideo
Als Testmaterial habe ich ein Video, das ich 2019 in den USA gemacht habe, ausgewählt: Das sehr wackelige 720p 50-fps Video zeigt einen Buckelwal, der aus dem Wasser springt – und ist wohl recht anspruchsvoll, was die Encodierungsqualität angeht. Aufgrund der niedrigen Auflösung gehe ich allerdings davon aus, dass viele Vorteile der neuesten Codes, die ja ihre Stärken bei UHD-Content ausspielen, nicht zur Geltung kommen werden.
Die Originaldatei (31.340 KB, 1280×720, 50 fps, yuvj420, AVC/h264 .mov, 20.321 kb/s)
Ziel war es, die Datenmenge auf ca. 1/3 zu reduzieren. Für die obige Datei bedeutet das also von 30 MB auf 10 MB. Dass das mit h264 ohne allzu große Abstriche möglich ist, wusste ich bereits aus einem früheren Versuche: Vor einigen Jahren hatte ich ohne große Einarbeitung in die Materie mit einem FFMpeg-Script alle meine Daten in h264 umgewandelt. Mit dem Ergebnis war ich sowohl bezüglich der Dateigröße (ca. 1/3) als auch der Qualität zufrieden. Die Encoder-Settings konnte ich durch herumprobieren rekonstruieren: x264, Preset slower, CRF 21.
Wie schlägt sich der in die Jahre gekommene Codec aber gegen die beiden neueren Codecs h265 und av1?
Zum Vergleich der Qualität wurde das Tool FFMetrics in der Version 1.3.1b2 benutzt, insbesondere die VMAF-Scores waren für mich von Interesse. VMAF ist eine von Netflix entwickelte und oft für Streaming-Qualitätsvergleiche herangezogene objektive Metrik.
Fazit / Anmerkungen
Wie erwartet gilt: neuer Codec=bessere Qualität bei gleicher Dateigröße=längere Encode-Dauer. Überrascht hat mich allerdings, dass Preset-Werte von > 3 (AOM) bzw. > 4 (SVT) schlechtere VMAF-Werte als bei der h265-Referenz produzierten – Erst bei schmerzhaft niedrigen Preset-Werten, welche eine entsprechend lange Encode-Zeit bedeuten, wurde h265 in dieser Metrik geschlagen. Meine Vermutung ist, dass das an der niedrigen Auflösung (720p) liegt. Der neuere Codec spielt seine Stärken wohl erst bei sehr hohen Auflösungen aus. Allerdings sind die beiden anderen Metriken (PSNR und SSIM) durch die Bank bei den neuen Codecs höher. Diese Metriken sind allerdings in ihrer Aussagekraft umstritten.
Für meinen use-case bedeutet das nun, dass sich der av1-Codec angesichts der astronomisch langen Encode-Zeiten nicht lohnt, und ich stattdessen mit dem bewährteren h265-Codec (preset slow) ins Rennen gehen werde.
Eine vollständige Tabelle mit PSNR, SSIM und VMAF-Werten gibt es hier.
batch reencode
Dieses Bash-Script durchsucht alle Unterordner des aktuellen Verzeichnisses nach .mov-Dateien und encoded diese dann mit ffmpeg, die Zieldatei landet im selben Ordner:
find . -type f -name '*.mov' -exec sh -c '
name="${1%.*}"
echo "$name"
ffmpeg -i "$1" -map 0 -c:v libx265 -crf 21 -preset slow -vf scale=in_range=limited:out_range=limited -pix_fmt yuv420p10le -c:a libopus -b:a 192k -vbr on "${name}.mp4"
' find-sh {} \;
#für die beiden anderen Codecs würde die Befehlszeile so aussehen: ./ffmpeg -i .\wal.mov -map 0 -c:v libsvtav1 -preset 4 -crf 25 -svtav1-params tune=0 -pix_fmt yuv420p10le -vf scale=in_range=limited:out_range=limited -c:a libopus -b:a 192k -vbr on av1-svt-4-25.mp4 ./ffmpeg -i .\wal.mov -map 0 -c:v libaom-av1 -cpu-used 3 -crf 22 -b:v 0 -pix_fmt yuv420p10le -vf scale=in_range=limited:out_range=limited -c:a libopus -b:a 192k -vbr on av1-aom-3-22.mp4
Nachtrag
Wie man gesehen hat, ist der VMAF-Score Abstand zwischen dem in die Jahre gekommenen h264-Codec und den beiden neueren Codecs bei gleicher Dateigröße doch recht hoch (93.4 zu ~ 95.0). Rein aus Interesse habe ich getestet, wie groß ein h264-Encode sein muss, um auch einen VMAF-Score von ~ 95.0 zu erreichen:
h264 encode (HandBrake, x264-10 bit, Preset: slower, CRF: 19.5)
Encode runterladen (.mkv)
VMAF-Score: 94.9632
Dateigröße: 13.906 KB
Im Vergleich zur h265-Referenz ist der h264-Encode bei etwa gleicher Qualität also ca. 30% größer.