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.