[gelöst] Diashow mit ffmpeg erstellen

[ralli]

Nach der Anpassung läuft es perfekt in HD sowie auch FULL HD. Leider werden wohl nicht alle Bilder erfaßt, was wohl irgendwie am Ausgangsmaterial liegt und nicht an ffmpeg.

Habe dazu noch zwei Fragen.

Welches Bildformat sollte bevorzugt werden? Png oder jpg bzw. jpeg? Oder ist das für das gerenderte Video egal?

Stellt die unterschiedliche Größe der Bilder als Ausgangsmaterial ein Problem dar? Was passiert, wenn 1 Bild das die Größe des Videoausgangsformat übersteigt?

Danke!

Gruß ralli

[wanne]

Leider werden wohl nicht alle Bilder erfaßt, was wohl irgendwie am Ausgangsmaterial liegt und nicht an ffmpeg.

Ich würde eher auf den Dateinahmen tippen...

Png oder jpg bzw. jpeg? Oder ist das für das gerenderte Video egal?

Am Ende ist es egal. Im Zweifelsfall wird bei jedem konvertieren zu jpeg die Qualität schlechter. In sofern ist es schädlich pngs in jpegs umzuwandeln aber nicht immer in die andere Richtung. Optimal nimmt man immer was kommt ohne zu konvertieren.
Daneben habe ich in meinem Script dasda stehen:

Code: Alles auswählen

for bild in *.png

Das frisst natürlich nur png willst du auch jpeg, JPG und jpgs haben brauchst du da stattdessen:

Code: Alles auswählen

for bild in *.png *.jpg *.jpeg *.JPG

Stellt die unterschiedliche Größe der Bilder als Ausgangsmaterial ein Problem dar? Was passiert, wenn 1 Bild das die Größe des Videoausgangsformat übersteigt?

Nein. ffmpeg konvertiert sowieso in ein neues Format (AVC) mit passender Größe. In dem Fall versucht er 7,3kiB pro Bild. zu erreichen. Da kommst du weder mit jpeg noch mit png hin . Er trickst aber eben ach ein bisschen weil er jedes Bild 75 mal einfügt und Ähnlichkeiten (also in dem Fall sogar Gleichheit) ausnutzt. In dem Fall versucht er also eher 550kiB pro sich änderndem Bild so riesig kann er das aber gar nicht. Real sind es deswegen deutlich weniger.

[ralli]

Danke wanne, sehr hilfreich und informativ.

Gruß ralli

[wanne]

Gerade festgestellt: ffmpeg ist sauer wenn abwechselnd pngs und jpegs kommen.

Also doch eher alles zuerst nach png konvertieren:

Code: Alles auswählen

#!/bin/bash
i=0
for bild in *.png *.jpg *.JPG *.jpeg
  do i=$((i+1))
  ffmpeg -y -i "$bild" $(printf "image%02d.png" $i)  
done
ffmpeg -r "1/3" -i image%02d.png -t $(($i*3)) -f lavfi -i anullsrc -c:v libx264 -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2" -pix_fmt yuv420p -r 25 -profile:v high -level 3.1  -b:v 1500k out.mp4

[ralli]

Hab jetzt gerade eine Verständnisschwierigkeit. Werden hier alle jpg ... ins echte png Format umgewandelt? Das kann doch sonst nur convert von ImageMagick, oder irre ich mich?

Gruß ralli

[ralli]

Ich mach das immer so:

Code: Alles auswählen

for i in *.jpeg; do convert $i $(basename $i .jpeg).png; done

Hier kommt convert von ImageMagick zum Einsatz und konvertiert alle jpeg Dateien zu png Dateien. Sie werden nicht nur umbenannt, sonder ins neue Format konvertiert.

Gruß ralli

[Lord_Carlos]

Das kann doch sonst nur convert von ImageMagick, oder irre ich mich?

Du irrst dich. Warum sollte nur ImageMagick das koennen?

Die erste for schleife in Wannes script konvertiert mit Hilfe von ffmpeg, gepeichert wird es gleich mit passenden Namen.

[ralli]

Aha, gut zu wissen, lerne auf diesem Gebiet täglich hinzu. Hatte vorher nicht viel mit ffmpeg gemacht. Das ist ja wie ein Schweitzer Messer, unglaublich und unfasssbar, was das alles kann. Auf jeden Fall lohnt es sich, sich damit zu beschäftigen.

Gruß ralli

[MaGe]

Die erste for schleife in Wannes script konvertiert mit Hilfe von ffmpeg [...]

Frage ist das normal das die Dateien .JPG so aufgepumpt werden

CIMG0387.JPG - Größe - 1,4 MiB (1.502.043)
image01.png - Größe - 9,4 MiB (9.827.176)



gruss MaGe

[MSfree]

Frage ist das normal das die Dateien .JPG so aufgepumpt werden

CIMG0387.JPG - Größe - 1,4 MiB (1.502.043)
image01.png - Größe - 9,4 MiB (9.827.176)

Ja. PNG verwendet "nur" eine verlustfreie Kompression, die der ähnelt, die auch ZIP verwendet. Die JPEG-Kompression ist deutlich effizienter aber nicht verlustfrei.

[ralli]

Hab das gerade mal bei mir kontrolliert, ja die erzeugten png Dateien (auch mit convert) werden tatsächlich ca 8 bis 10 fach größer. Einen bedeuteten Qualitätsunterschied kann ich jetzt auf Anhieb nicht erkennen. Das spricht doch dafür, das jpg Format zu benutzen. Und tatsächlich geschieht das auch heute noch überwiegend in der Praxis. Jetzt kennen wir auch den Grund, obwohl Speicherplatz ja nicht mehr rar ist. Werde mal ein Video mit mehreren png und mehreren jpg Bildern rendern und mir dann die Videogröße anschauen und dann berichten. Dieser Unterschied ist ja nicht mehr wenig. Nur TIFF ist ca. 25 fach größer.

Gruß ralli

[MSfree]

Einen bedeuteten Qualitätsunterschied kann ich jetzt auf Anhieb nicht erkennen.

Wenn man JPEG in PNG konvertiert, entsteht kein Verlust, PNG ist verlustfrei. Umgekehrt, PNG nach JPEG, resultiert in Verlusten, die aber nicht unbedingt sichtbar sein müssen.

Werde mal ein Video mit mehreren png und mehreren jpg Bildern rendern und mir dann die Videogröße anschauen

Das wird keinen großen Unterschied ergeben. Das Videoformat nutzt auf jeden Fall eine verlustbehaftete Kompression, im Grunde ist MPEG nur einer weiterentwicklung von JPEG unter Ausnutzung von Bildgleichheiten bei aufeinander folgenden Bildern.

Nur TIFF ist ca. 25 fach größer.

Auch das ist nicht ganz richtig. TIFF ist im Grunde ein Bildcontainer, der viele unterschiedliche Kompressionsverfahren unterstützt. Man kann TIFF-Bilder auch mit dem JPEG-Algorythmus komprimieren, was dann wieder zu ähnlichen Bildgrößen führt wie das native JPG-Format.

[MaGe]

Wenn man JPEG in PNG konvertiert, entsteht kein Verlust, PNG ist verlustfrei.[...]

müssen dann die Bilder nicht identisch sein?

Original: CIMG0387.JPG - Größe: 1,4 MiB (1.502.043)
[Parsed_ssim_0 @ 0x55aa9cebc440] SSIM Y:1.000000 (inf) U:1.000000 (inf) V:1.000000 (inf) All:1.000000 (inf)

Konvertieren mit ffmpeg in png: Größe: 9,4 MiB (9.827.176)

Code: Alles auswählen

 i=0; for bild in *.JPG; do i=$((i+1)); ffmpeg -y -i "$bild" $(printf "image%02d.png" $i); done 

[Parsed_ssim_0 @ 0x55a736c4ba00] SSIM Y:0.994990 (23.001598) U:0.969569 (15.166880) V:0.978440 (16.663563) All:0.987995 (19.206344)



gruss MaGe

[ralli]

Und hier ein kleiner Praxistest:

Ausgangsmaterial: 140 jpg Bilder aus meiner Heimatstadt im Sauerland.

Die gleichen Bilder wurden dann ins png sowie tiff Format konvertiert und gerendert.

140 gerenderte jpg Bilder Videogröße 1280x720 mp4 - Videogröße 60 MB

140 gerenderte png Bilder Videogröße 1280x720 mp4 - Videogröße 62 MB

140 gerenderte tiff Bilder Videogröße 1280x720 mp4 - Videogröße 60 MB

Das Ergebnis hat mich dann doch etwas überrascht.

[MaGe]

Das Ergebnis hat mich dann doch etwas überrascht.

mit dem Sript von @wanne?

wenn ja kein großer unterschied hast alle mit -b:v 1500k konvertiert
du hast deine Bilder ( Videos ) mit -b:v 1500k angepasst.



gruss MaGe

[ralli]

Das Ergebnis hat mich dann doch etwas überrascht.

mit dem Sript von @wanne?

wenn ja kein großer unterschied hast alle mit -b:v 1500k konvertiert
du hast deine Bilder ( Videos ) mit -b:v 1500k angepasst.



gruss MaGe

Genau so ist es. deshalb ist die gleiche Größe nicht wirklich verwunderlich. Das meiste Bildmaterial (eigentlich alles) ist bei mir jpg und ich werde das zukünftig nicht mehr konvertieren, weil ich darin keinen SInn und Mehrwert erkennen kann. Bin auf diesem Gebiet allerdings auch kein Experte, und laß mich deshalb gerne belehren.

Gruß ralli

[MSfree]

ich werde das zukünftig nicht mehr konvertieren, weil ich darin keinen SInn und Mehrwert erkennen kann.

Du hast schon recht, es ergibt keinen besonderen Sinn, die Bilder zu konvertieren. ffmpeg muß die Bilder ohnehin beim Laden dekomprimieren und hat dann ein unkomprimiertes Bild im RAM, bevor es neu in das Zielformat MP4 komprimiert wird.

[wanne]

müssen dann die Bilder nicht identisch sein?

Ja. Fast. Es gibt am Ende Rundungsfehler beim Decodieren vom jpeg. Btw. rundet ffmpeg gerne mal etwas "flotter" (Nutzt intels avx, dass es gerne mal nicht so genau beim Rechnen nimmt.)

Code: Alles auswählen

SSIM Y:0.994990 (23.001598) U:0.969569 (15.166880) V:0.978440 (16.663563) All:0.987995 (19.206344)

Das ist ein Bug im ffmpeg. Der kann nicht verschiedene Bilder mit unterschiedlichen pix_fmts vergleichen. Da kommt normalerweise totaler Müll raus. Ich nehme an, dein Bild ist in erster Linie schwarz und deswegen sieht das einigermaßen gut aus.
Leder kann png nur rgb24 rgba rgb48be rgba64be pal8 gray ya8 gray16be ya16be monob
Und jpeg nur yuvj420p yuvj422p yuvj444p
Damit ist ffmpeg zu blöd pngs mit jpegs zu vergleichen. Ausdrückliche Empfehlung der Entwickler: Zuerst alles nach rgb24-png umwandeln und dann vergleichen. Am ende macht spätestens deine Grafikkarte Konversion+Rundung eh. Imagemagick kann ssim erst in neueren Versionen als die aus Debian. Auch da würde ich aber tippen, dass die Genauigkeit für die SSIM Berechnung nicht ausreicht um die Rundungsfehler beim Koverteiren von jpeg zu png festzustellen.

Frage ist das normal das die Dateien .JPG so aufgepumpt werden

Kommt auf jpeg an. Bei jpeg kannst du vor allem die Qualität zu Gunsten der Dateigröße runterschrauben. Das kann man auch mit png. Gedacht ist es so nicht und es gibt auch weit weniger Möglichkeiten.
Steuern kannst du das mit -q im ffmpeg oder -quality im imagemagick. Schraub mal an den Parametern -q 50 und auch du wirst den Qualitätsunterschied merken. Dafür reichen die qualtitiven Möglichkeiten von pngs weit über die von jpegs raus. So kann png z.B. bis zu 281 Billionen Farben. 16Millionen mal mehr als jpeg. (Auch hier ist die Frage, was das bringt wenn die neusten Bildschirme gerade mal eine Milliarde Farben darstellen können.) Noch weniger nutzen hast du davon, wenn dein Ursprungsbild ein jpeg ist und deswegen eh schon viel weniger Farben enthält. Der zweite fette Parameter ist wie lange du dir zeit lässt nach einem kleinen Bild zu suchen, dass deinen Inhalt darstellt. Pngcrush ist ein tool das sich da für pngs deutlich mehr Arbeit macht und kleinere exakt gleiche Bilder produziert.
Der fette Vorteil ist, dass png-Konvertierungen nicht verlustbehaftet sein müssen. Du magst den unterschied bei ein mal konvertieren nicht sehen. Aber du konvertierst jetzt schon 2 mal. Wenn du dann das Xte mal konvertierst und jedes mal die Qualität abnimmt hast du irgend wann wirklich Müll. Deswegen hält man seine Zwischenergebnisse immer möglichst verlust- und rechenarm (und nimmt dafür in größeren Dateigrößen in kauf) die werden später ja eh gelöscht. Danach wird konvertiert

Das spricht doch dafür, das jpg Format zu benutzen. Und tatsächlich geschieht das auch heute noch überwiegend in der Praxis.

Nein. jpeg ist Qualität vs. Dateigröße beschissen. jpeg2000 oder webp sind bei gleicher Qualität so um den Faktor 5 kleiner. AVIF soll nochmal deutlich besser sein. jpeg wird so gerne verwendet, weil es überall funktioniert. Siehe dein Fernseher: Kann kein png. Kann kein webp. Kann kein jpeg2000.

Das Ergebnis hat mich dann doch etwas überrascht.

Ich gar nicht. Ich habe da -b:v 1500k angegeben. Damit bestimme ich die Dateigröße. Bei 7min Film gibt das nach Adam Riese 75MiB. Das hat der ffmpeg jetzt etwas verfehlt. Aber nicht zu schlimm. Du könntest mit -minrate wohl nochmal etwas nachhelfen das wirklich zu erreichen.
Btw. fühle ich mich da ein bisschen verarscht: Dein Fernsher hat wohl Probleme mit kleinen Dateien. Den ganzen "Klateradatsch" den ich da dran gehängt habe bläst die Datei nur "unnötig" auf damit das Ding irgend wie auf dem TV abspielt. (Habe ich mir vom Imagination abgeguckt das macht das auch so. TV macht das selbe und baut absichtlich "nullen" in den Stream ein, weil Decoder wohl Probleme mit zu kleinen Streams haben. Dass das für Dateien auch gilt war mir neu.)
Die folgenden Kommandos werden dir ein Video in deutlich besserer Qualität liefern und dabei so ca. 1.5MiB statt 60MiB groß ist (crf peilt nur eine gewisse Qualität an und erlaubt dem ffmpeg die Datei möglichst klein zu machen auch hier kann man wie bei pngcrush mit -speed bzw. -preset einstellen wie lange gesucht werden soll um kleinere Ergebnisse bei gleicher Qualität zu erreichen.):

Code: Alles auswählen

ffmpeg -r "1/3" -i image%02d.png  -c:v vp9 -pix_fmt yuv420p -crf 18 out.mkv
ffmpeg -r "1/3" -i image%02d.png  -c:v libx264 -pix_fmt yuv420p -crf 18 out.mp4

Genau so ist es. deshalb ist die gleiche Größe nicht wirklich verwunderlich. Das meiste Bildmaterial (eigentlich alles) ist bei mir jpg und ich werde das zukünftig nicht mehr konvertieren, weil ich darin keinen Sinn und Mehrwert erkennen kann. Bin auf diesem Gebiet allerdings auch kein Experte, und laß mich deshalb gerne belehren.

Es gibt eigentlich keinen Sinn. Den Grund habe ich genannt:

Gerade festgestellt: ffmpeg ist sauer wenn abwechselnd pngs und jpegs kommen.

ffmpeg hat halt das Problem dass er auf der Kommandozeile (in der C API schon) nicht aus abwechselnd png UND jpeg einen Film machen kann. Du musst als entweder alle jpeg in png umwandeln oder alle png in jpeg. Beim Umwandeln von png in jpeg wird die Qualität schlechter in die andere Richtung bleibt sie (weitestgehend). Deswegen habe ich mich für die andere Richtung entschieden. wenn wirklich ALLE Bilder jpegs sind macht die Umwandlung natürlich keinen Sinn.

[wanne]

Die Diskussion um JPEG nach TID 178201 abgetrennt.

[ralli]

So ich habe noch weiter experimentiert. Herausgekommen ist folgendes Script:

Code: Alles auswählen

 
printf "file '%s'\n" *.JPG > list.txt 

ffmpeg -r 0.2 -f concat -i list.txt -target pal-dvd -s 1280x720 video.mpg

Das meiste Bildmaterial ist nicht so üppig von der Größe und Auflösung, das reicht mir völlig und die Qualität ist akzeptabel.

Wer tiefer eintauchen möchte, kommt um die Original Dokumentation nicht herum.

https://ffmpeg.org/ffmpeg.html

Damit kann man sich Monate beschäftigen .... Für mich reicht es erst mal. Mehr wollte ich nicht.

Gruß ralli

[MaGe]

ffmpeg -r 0.2 -f concat -i list.txt -target pal-dvd -s 1280x720 video.mpg

PAL DVD ist immer 720x576 mit einem 4:3 oder 16:9-Seitenverhältnis

Es sind andere Rahmengrößen zulässig: 704x576, 352x576, 352x288. Aber werden selten verwendet.



gruss MaGe

[ralli]

Ist mir schon klar, aber tatsächlich erstellt er mit dem zusätzlichen Parameter -s 1280x720 ein Video mit genau dieser Auflösung. Und es läuft einwandfrei auf meinem Smart TV mit annehmbarer Qualität. Warum das so funktioniert, kann ich Dir nicht beantworten. Ob er das dann interpoliert? Kann ja mal den Parameter weglassen und schau mir dann die Videogröße an.

Gruß ralli

[ralli]

Wenn ich den Parameter -s 1280x720 weg lasse ist die Videogröße 120 MB, mit erzwungener HD Auflösung 247 MB. Bei meiner bevorzugten Lösung habe ich auch links und rechts keine schwarzen Trauerränder und der Bildschirm ist ganz ausgefüllt.

Gruß ralli

[MaGe]

Und es läuft einwandfrei auf meinem Smart TV

Ich dachte eher an eine DVD ( -target pal-dvd ), und ob die
mit der einstellung 1280x720 vom Dvd player erkannt wird ?



gruss MaGe

[wanne]

Ist mir schon klar, aber tatsächlich erstellt er mit dem zusätzlichen Parameter -s 1280x720 ein Video mit genau dieser Auflösung. Und es läuft einwandfrei auf meinem Smart TV mit annehmbarer Qualität. Warum das so funktioniert, kann ich Dir nicht beantworten. Ob er das dann interpoliert? Kann ja mal den Parameter weglassen und schau mir dann die Videogröße an.

Das war ziemlich genau mein erster Vorschlag und du hast behauptet, dass er dann das Seitenverhältnis verzieht. Deswegen habe ich die Ränder dran gepackt.
Kann es sein, dass wir jetzt nicht mehr über das gleiche Ausgangsmaterial reden?