Vielleicht erinnert ihr euch noch, als ich im Januar 2025 über meine Erfahrungen mit Handbreak für die Archivierung von Videodateien berichtet habe.
Einleitung
Für die Archivierung von Videos, insbesondere für YouTube-Projekte, brauche ich eine Methode, die nicht nur die Videoclips verkleinert Da man keine Korrekturen vornehmen kann oder auch auch das Video später noch austauschen kann werden die Projekte praktisch nie wieder bearbeitet.
Dies führt dazu , dass einzelne Videoprojekte je nach Aufnahmegröße bis zu 40–60 Gigabyte belegen können, was sich dann über die Jahre gewaltig aufsummiert.
Ansatz Handbrake
Damals habe ich Handbrake verwendet, um Videos mit guter Qualität zu verkleinern, sodass sie bequem archiviert werden konnten. Ein Problem war jedoch, dass Handbrake nicht automatisch zwischen Dateien im 8-Bit-Format und solchen im 10-Bit-Format unterscheiden konnte.
Dies erforderte den Einsatz anderer Tools wie MediaInfo in einem Skript, um zu ermitteln, ob ein Video im 8- oder 10-Bit-Format vorliegt, um das passende Preset auszuwählen. Daher habe ich dieses Projekt de facto nie umgesetzt und es kamen aus Zeitgründen auch andere Projekte dazwischen.
Neuer Versuch mit FFmpeg
Nun habe ich jedoch einen neuen Versuch gestartet, diesmal a) mit FFmpeg und b) unter Linux gestartet. Dies liegt daran, dass das Schreiben von Skripten hier einfacher fällt als beispielsweise in der Windows-Shell. Betrachtet man die Effizienz sowohl hinsichtlich der erreichbaren Dateigrößen als auch des Energieverbrauchs, bleiben die Ansichten von damals bestehen.
Der kleine Raxda X4 ist aufgrund seines geringen Stromverbrauchs immer noch am effizientesten, auch wenn er eine lange Laufzeit hat. Der Vorteil von FFmpeg ist, dass es unabhängig vom Format oder Subsampling (420 oder 422) bei der Konvertierung nichts verändert. So bleibt die Farbtiefe erhalten, und man muss lediglich selbst entscheiden, welche Qualitätsstufe für seine Ansprüche ausreichend ist.
Ich habe bereits Experimente mit FFmpeg durchgeführt und bin mittlerweile auf die Qualitätsstufe 16/17 gekommen. Dies erzeugt zwar geringfügig größere Dateien, verlangsamt jedoch den Konvertierungsprozess nicht so sehr wie eine höhere Qualitätsstufe. Trotzdem sind die Ersparnisse immer recht groß.
Von 13 GB für das Projekt runter auf 1.1 GB ist schon beachtlich. Und in der Qualität wird man eine leichte Reduktion der Qualität sehen, die aber in keinem Fall so groß ist, wie die Größenreduktion vermuten lassen würde.
Das Script
Eigentlich war dass dazu erforderliche Script recht einfasch, bis auf einen Punkt.
Wenn man mit Windows oder dem Smartphone aufnimmt, kommt man immer wieder in den Genuss von Dateinamen, die Leerzeichen enthalten. Das führt dazu, dass die Liste der Dateinamen dann unweigerlich falsch aufgeteilt wird, da die Linux Shell per IFS (Internal Field Separator) Variable bestimmt, wie Strings aufzuteilen sind. Da die Dateiname aber in Zeilen kommen musste ich den IFS mit „\n“ auf Zeilenvorschub setzen und vor dem eigentliche ffmpeg Aufruf wieder zurücksetzen.
Ich habe das so eingestellt, dass ich beispielsweise ein Jahrgang 2023 auf dem kleinen Raxda X4 spiele und die Konvertierung mit dem Skript auf eine externe SSD durchlaufe. Anschließend kann ich mir die resultierenden Dateien stichprobenartig anschauen und entscheiden, ob die recht großen Originale durch die viel kleineren Dateien ersetzt werden können.
Fazit
Ich bin noch dabie zumindest stichprobenartig Originalclips und die von ffmpeg in der Größe reduzierten Clips zu vergleichen und habe bis noch keinen entdeckt, wo ich sagen würde, dass das qualitativ nicht in Frage kommt. Dafür ist aber die Speicherreduktion schon beachtlich, immerhin von 4,1 TB runter auf 984 GB und das ist dann schon ein Unterschied für Videoclips, die man eigentlich nicht mehr anfasst, weil man ja auf Youtube auch nichts mehr korrigieren kann.
ciao tuxoche