Tja, ich mal wieder.
War ich doch tatsächlich der Meinung, man könne MJPEG-Codecs einfach mal so miteinander vergleichen. Leider war es nicht so einfach, wie ich am Anfang dachte. Aber dazu mehr im Laufe der Erklärungen...
__
Zunächst versuchte ich herauszufinden, welcher Codec mit welcher Geschwindigkeit encodieren kann. Dazu besorgte ich mir folgende Codecs:
- ffdshow 2005-07-03 von celtic-druid
- Lead Technologies MCMP/MJPEG Video Codec 1.0.0.16
- MainConcept MJPEG Codec 3.2.4
- Morgan M-JPEG Codec 3.0.0.9
- PICVideo M-JPEG Codec 3.0.0.12
Mit ein wenig Geschick kriegt man sie sogar alle parallel zum Laufen, PICVideo darf dafür nicht der primäre MJPG-Codec sein.
Um nun eine halbwegs brauchbare Videoquelle zu bekommen, ohne eine TV-Karte zu besitzen (ja, ja ...), verwendete ich folgendes AviSynth-Skript, das trotz seiner Einfachheit die Schwächen der Codecs überraschend gut zeigte:
ColorBars(704,576,"YUY2") # Testbild
KillAudio() # Tonspur - brauchen wir nicht
AssumeFPS(25.0) # PAL bitte
Trim(0,-1500) # 1 Minute reicht
AssumeFrameBased() # nur zur Sicherheit
AssumeTFF() # bei TV üblich, richtig?
Info() # damit noch ein paar feine Details im Bild sind
Ein sinnvolleres Skript mit wenig Rechenleistung ist mir nicht eingefallen; hätte ich ein anderes Video als Quelle genommen, hätte das erst mal decodiert oder von Platte gelesen werden müssen, was im Vergleich zur MJPEG-Komprimierung zu viel Zeit gekostet und die Werte zu stark verfälscht hätte.
Als "Referenz" für die Vergleiche diente zunächst der ffdshow mit seiner Implementation des MJPEG-Codec. Der erlaubt als Qualitätsoption für den Modus "1-pass, constant quantizer" Werte von 1 und 2 - größer muss nicht sein. Dann habe ich versucht, mit den jeweiligen anderen Codecs Dateien zu erzeugen, die in etwa gleiche Dateigröße erzeugen.
Grund: Jeder Codec definiert die Qualität irgendwie anders. Es würde also nicht viel Sinn machen, irgendwie zu erraten, welche Einstellungen die gleichen Quantisierer erzeugen würden, und dann Qualität und Dateigröße gleichzeitig zu vergleichen. Also war ich der Meinung, nach Möglichkeit die Dateigröße halbwegs gleich zu halten, und nur die Qualität zu vergleichen.
Dabei bin ich zu folgenden Ergebnissen gekommen (die jeweiligen Einstellungen erzeugen natürlich nur bei diesem künstlichen Test vergleichbare Dateigrößen, reale Aufnahmen dürften wohl leicht andere Verhältnisse bringen):
ffdshow
Preis: 0
Modus: 1-pass const. quant.
Quant.-Faktor: 1 | 2
Dateigröße: 94,34 | 75,34 MB
Geschwindigkeit: ~4250 px/MHz (*)
Qualität (auf die Smilies klicken): :eek: | :)
Lead Technologies
Preis: 9 EUR
Modus: JPEG 4:2:2
Quality/Size: 19 | 29
Dateigröße: 94,25 | 75,62 MB
Geschwindigkeit: ~4200 px/MHz (*)
Qualität (auf die Smilies klicken): :) | :hm:
Lead Technologies
Preis: 9 EUR
Modus: LEAD proprietary - ACHTUNG: Anscheinend nicht voll MJPEG-Kompatibel!
Quality/Size: 27 | 39
Dateigröße: 95,58 | 75,18 MB
Geschwindigkeit: ~3760 px/MHz (*)
Qualität (auf die Smilies klicken): :( | :nein:
MainConcept
Preis: 19 EUR
Modus: Standard
Qualität: 92 | 84 - ACHTUNG: Dieser Codec verwendet den Qualitätswert aus dem VfW-Dialog!
Dateigröße: 94,72 | 73,99 MB
Geschwindigkeit: ~4800 px/MHz (*)
Qualität (auf die Smilies klicken): :) | :hm:
Morgan MM
Preis: 20 EUR
Modus: 4:2:2
Forced quality: 92 | 84
Dateigröße: 95,20 | 74,27 MB
Geschwindigkeit: ~4720 px/MHz (*)
Qualität (auf die Smilies klicken): :) | :hm:
Pegasus PICVideo3 - aktualisiert!
Preis: 28 USD
Modus: 4:2:2, "normalisierte Werte" aus!
Quality: 19 | 18
Dateigröße: 97,67 | 73,94 MB
Geschwindigkeit: ~4810 px/MHz (*)
Qualität (auf die Smilies klicken): :) | :hm:
(*) Pixel/Megahertz - ist natürlich höchst prozessorabhängig (je nach unterstützter CPU/FPU-Befehlserweiterungen), und sicher auch vom Gesamtsystem stark beeinflußt. Aber mal so als Rechenbeispiel:
704*576 Pixel/Frame * 1500 Frames / 3:00 Minuten / 800 MHz = 4224 px/MHz
Wie man sehen kann, sind die Unterschiede zwischen den Encodern hinsichtlich der Geschwindigkeit gar nicht mal so hoch. Wer also die Chance hat, der sollte meiner Meinung nach doch mach Qualität wählen!
Und dabei sind das nur direkte Screenshots. Eigentlich hatte ich ja vor, Original und Kopie miteinander über Differenz und PSNR zu vergleichen. Aber das stellte sich als sinnlos heraus, denn einige Codecs haben wohl unterschiedliche Ansichten davon, was ihnen beim Encodieren vorgesetzt wurde, und wie es wieder zu decodieren sei: Manche Codecs gehen von PC-Scale aus, andere von TV-Scale. Zumindest einer erzeugte sogar Ergebnisse, bei denen ich nicht wusste, wie ich die wieder hätte korrigieren sollen...
Und noch eines war sehr merkwürdig: Ich habe sämtliche Screenshots (ausgenommen das proprietäre LEAD-Video, hier kam der VfW-Codec zum Einsatz) nach dem Ergebnis erzeugt, das der VirtualDub-interne MJPEG-Decoder erstellt (File - Open: show extended options - Use internal M-JPEG decoder). Dabei musste ich beim Öffnen des MainConcept- und des Morgan-Videos zusätzlich die Option "Swap fields" wählen. Ich finde es recht sonderbar, dass die Field-Reihenfolge nicht korrekt erkannt wird.
Bei PICVideo ist außerdem eine leichte Kontrasterhöhung festzustellen. Ich werde später noch mal testen, ob das an der Encoder-Einstellung "Encode normalized YUV" liegen kann. Oder es weiß zufällig jemand, was das bedeutet und ob/wann man es ein-/ausschalten sollte.
__
P.S.: Sehe gerade, dass die verlinkten PNG-Bilder in Opera total kaputt aussehen, in IrfanView dagegen einwandfrei. Werde sie noch mal recodieren...
