MotionJPEG-Codec-Vergleich

    Ich könnte da wohl nur entweder PICVideo 2 oder PICVideo 3 installieren. Da müsste ich alles noch mal umbauen dafür... Na ja; mal schauen, wo's den noch gibt - oder es weiß jemand, ob der V3 eher qualitativ besser geworden ist, oder schneller?

    Bei ffdshow würde ich sagen: Wirklich viel kann man da nicht einstellen, was die Geschwindigkeit beeinflussen würde. Sicherlich verwendet er einfach mehr Rechenzeit auf Qualitätsoptimierung, die sich andere Codecs durch Abkürzungen ersparen, wodurch aber die Qualität eben nicht optimal wird.

    Danke für den Test - 80% bei 1400 MHz sind schon mal ein guter Anhaltspunkt. Bei mir sind's gerade mal 8-11 fps bei Offline-Komprimierung, Capturing in D1/4CIF wäre mit meinem System nicht möglich.

    Zitat von grua

    LigH
    vielleicht kannst du auch den PICVideo MJPEG V2 noch mitaufnehmen, denn der wir vmtl. noch von sehr vielen verwendet?


    Da schließe ich mich an; ich habe noch eine Lizenz des V2 aus der Zeit, als er noch kostenlos war :D

    bb

    Okay - ich werde sehen, was sich machen läßt; am Ende werden die ganzen MJPEG-Codecs ja sowieso wieder bei mir runterfliegen, weil ich dafür eh keine Verwendung habe; hat mich nur mal selber interessiert, und da wollte ich eben meine Erfahrungen auch gleich teilen.

    Hab mir PICVideo 2 noch mal angeschaut.

    Die Videodateien wurden, soweit ich das getestet habe, (evtl. bis auf Flags im Header) exakt identisch erstellt. Nur der Decoder bringt dann ganz leichte Abweichungen in der Qualität, aber die bewegen sich bei PSNR und SSIM gerade mal im Promille-Bereich.

    Auch von der Geschwindigkeit geben sie sich anscheinend nichts. Zumindest, soweit ich das mit meinem AMD Duron feststellen konnte.

    Es scheint also, als wäre in V3 gegenüber V2 lediglich der Decoder geändert worden, eventuell noch ein paar zusätzliche Optionen in der GUI (z.B. die erwähnte Checkbox "normalised values"). Ob es vielleicht Verbesserungen für P4 / AMD64 gibt, müsste jemand testen, der eine solche CPU besitzt.

    Und genau in deren neuem Decoder liegt auch der bekannte Haken von V3, dass er prinzipiell den Colorspace übergibt, der angefragt wird. Und nicht erstmal versucht, ob die anfragende Appl. mit YUY2 klarkommt.
    So z.B. Avisynth, von Natur aus eigentlich YV12 nativ, kann aber genausogut mit YUY2 klarkommen. PicVideo3 dekodiert YUY2 mjpegs daher NACH Avisynth "stupide hin" in YV12, wenn Pixel_Type="YUY2" nicht gesetzt ist.

    Danke LigH für den extrem interessanten und aufschlussreichen Test!

    incredible:
    wie du ja dankenswerterweise auf http://forum.gleitz.info/showthread.php?t=18735 gezeigt hast.

    Zitat von incredible

    Am besten mal den ffdshow (libavcodec) mjpeg stream via FFdshows vfw mjpeg komponente in Vdub dekodieren lassen und nachsehen, wie die Farben sodann rüberkommen.



    Kannst du mir mal meinen Knoten aus dem Hirn nehmen. Was meinst du damit ?

    Gruß Gunnar

    Welchen Vorteil soll das denn haben den internen Vdub-MJPEG-Decoder zu verwenden ? Optimal ist doch immer den gleichen Codec zum Encoden und Decoden zu verwenden.

    Gruß Gunnar

    Um aber herauszufinden, ob die verschiedenen Encoder jeweils vielleicht unterschiedliche Luma/Chroma-Bereiche speichern (PC- vs. TV-Scale) oder ähnliches, muss man immer den selben Decoder verwenden. Schön wäre dann, wenn man wüsste, ob die Implementation auch referenzartig sei...

    Hallo,

    ich wollte den Test hier zuhause mal nachmachen. Leider ist mir auch aufgefallen, dass die Farben von ffdshow ganz anders sind als bei picvideo.

    Ich habe das testscript mit VD 1.6 geöffnet und dann die komprimierung eingestellt 1.) ffdshow mjpeg 2.) picvideo Q19, dann abgespeichert.
    Dann habe ich mit VDM die videos geladen und die screenshots als png gespeichert...

    Falls ich das richtig verstanden haben, war hir jetzt die rede davon, dass man den internen mjpeg decoder von VDM zu benutzen.

    Zitat von incredible

    Am besten mal den ffdshow (libavcodec) mjpeg stream via FFdshows vfw mjpeg komponente in Vdub dekodieren lassen und nachsehen, wie die Farben sodann rüberkommen.

    Jetzt weiß ich nicht genau, was damit gemeint ist... Wo genau stelle ich das ein ?

    Auch bei der Wiedergabe der Testvideos im MPC habe ich 2x andere Farben, wie kann ich das da umstellen ?

    ffdshow: [Blockierte Grafik: http://img97.imageshack.us/img97/5808/1testffshow4qw.th.png] -- picvideo: [Blockierte Grafik: http://img97.imageshack.us/img97/8862/2testpicvideo37gy.th.png]

    ---

    Exact!
    Picvideo geht hin und komprimiert die Luma via einem Faktor von 0-16 und 255-234, egal ob das reingehende YUY2 Signal bereits 16-234 aufweist.

    Bin seit einiger Zeit komplett von Picvideo auf FFdshows mjpeg umgestiegen.
    ABER wenn ein mjpeg via FFdshow decomprimiert wird, dann IMMER Pixel_Type="YUY2" nutzen. Sonst gibts die gleichen Probleme wie bei PicVideo3 ---> YV12 Output via Avisource()'s primären YV12 Request.

    Zitat von incredible

    Exact!
    Picvideo geht hin und komprimiert die Luma via einem Faktor von 0-16 und 255-234, egal ob das reingehende YUY2 Signal bereits 16-234 aufweist.


    Ok, ich denke das habe ich verstanden. Das ist doch wie in Avisynth die umwandlung von pc->tv richtig ?


    Zitat von incredible


    Bin seit einiger Zeit komplett von Picvideo auf FFdshows mjpeg umgestiegen.


    Würde ich auch gerne, wenn ffdshows mal ordentlich funktionieren würde bzw. das bild richtig decodiert würde.

    Zitat von incredible


    ABER wenn ein mjpeg via FFdshow decomprimiert wird, dann IMMER Pixel_Type="YUY2" nutzen. Sonst gibts die gleichen Probleme wie bei PicVideo3 ---> YV12 Output via Avisource()'s primären YV12 Request.


    Mjpeg wird bei mir auch mit ffdshow decodiert. Wo stelle ich da pixel_type="yuy2" ein ? Im decoder selber oder meinst du die ausgabe des avisynth-scripts ?


    Noch ein Problem it ffdshow habe ich. Links läuft ein vertikaler streifen. Der ist hellblau und nicht blau ! (grün markiert)
    Der Streifen ist nur bie ffdshows mjpeg Komprimierung. Bei PicVideo ist der nicht da.

    [Blockierte Grafik: http://img97.imageshack.us/img97/8391/1testffshowa4di.th.png]
    Click here to watch ffdshow_colorproblems

    // EDIT //
    Kann ich denn nirgends die Farbwandlung des PicVideo-Codecs verhindern ?

    ---

    Zitat von namor82

    Kann ich denn nirgends die Farbwandlung des PicVideo-Codecs verhindern ?

    Wie schon geschrieben:

    Zitat von LigH

    Modus: 4:2:2, "normalisierte Werte" aus!

    Und - es ist etwas schwierig, die FourCC-Verteilung so einzurichten, dass jeder Codec seine eigenen Ergebnisse bevorzugt. Es hängt davon ab, wann welcher Codec als "bevorzugter" registriert wird. Leider krieg ich das heute nicht mehr zusammen. Aber im Zweifelsfall:

    AVI in VirtualDub so öffnen, dass im Öffnen-Dialog die erweiterten Optionen aktiviert werden; dann den internen MJPEG-Decoder aktivieren. Der arbeitet mit Referenz-Code.

    Was die Decodierung in YUY2 angeht: Start - Programme - ffdshow - VFW Interface - Decoder...

    Danke erstmal für die Antworten.

    TEIL1:
    Ich habe das alles überpüft und dennoch keine Verbesserung feststellen können.
    Die ffdshow MJPEG aufnahme war immernoch nicht sauber, weil sowohl der ffdshow mjpeg decoder als auch der standart mjpeg decoder den gleichen fehler zeigten (rechts vertikal ist ein hellerer streifen, siehe post zuvor)...

    Auch die Änderung bei den picvideo einstellungen (normalized an oder aus) brachte gar nix, weil das ergebnis gleich aussah (mit ffdshow mjpeg decoder als auch mit dem standart.

    Nun wolle ich schon auf geben, habe dann nochmals den ffdshow-codec neu installiert und dann nochmal versuch, aber es hat sich nichts geändert.

    TEIL2:
    Dann habe ich bei VD 1.6 die Einstellungen bei
    VIDEO -> COLOR DEPTH geändert.
    Und zwar von
    * Decompression format = 4:2:2 YCbCr (YUY2) -- davor war autoselect
    * Output format = 4:2:2 YCbCr (YUY2) -- davor same as decoder.
    Dann ist der VD beim encodieren abgestürtzt.
    Als ich dann
    * Decompression format = 4:2:2 YCbCr (YUY2) -- davor war autoselect
    * Output format = same as decoder
    [Blockierte Grafik: http://img121.imageshack.us/img121/7493/vd1611settings6wp.th.jpg]
    einstellte lief alles wunderbar. ffdshow hat ein astreines Bild geliefert, sowohl mit ffdshow mjpeg decoder als auch mit dem standart.
    Auch konnte ich das beschriebene phänomän von dem picvideo codec beobachten
    (wenn ENCODE NORMALIZED YUV an ist => mach er das Bild heller
    ASSUME NORMALIZED YUV an ist => passiert gar nix).

    Die Ergebnisse habe ich hier in einem rar-file.

    Zitat von LigH


    AVI in VirtualDub so öffnen, dass im Öffnen-Dialog die erweiterten Optionen aktiviert werden; dann den internen MJPEG-Decoder aktivieren. Der arbeitet mit Referenz-Code.

    Was für einer Reference? MJPEG ist nirgent festgelegt. Erst MJPEG2000 ist spezifiziert. Von daher kann es für MJPEG keine reference geben.

    AC-Sama(Robert Vincenz)
    (werde für das -Chan zu alt :zunge: )

    Ich dachte bisher eigentlich, dass zumindest für einige der JPEG-Teilalgorithmen (wie DCT/iDCT, Quantisierung und Huffman-Komprimierung) bei der JPEG offizielle Sourcen zu bekommen seien. Wie konkret JPEG-Frames in einem MJPEG-Video verbunden werden, mag vielleicht von Hersteller zu Hersteller leicht abweichen - aber solange es auch Hardware-Encoder gibt, die MJPEG-Video erzeugen, dürfen die Abweichungen nicht zu stark ausfallen, weil sonst überhaupt gar keine Kompatibilität zwischen den Produkten möglich wäre; also wenigstens ansatzweise müssen die Hersteller sich untereinander schon geeinigt haben. Und VirtualDub ist in der Lage, auch Hardware-encodiertes MJPEG alleine per Software zu decodieren. Was solchen Videodaten fehlt, sind meist konkrete Huffman-Tabellen, wenn ich mich recht erinnere, da werden wohl Standardtabellen angenommen

    Nun es ist so das WENN MJPEG in einem avi ist, es OpenDML benutzt(wurde dafür extra Matrox entwickelt. Und auch das die eigentlichen Bilddaten enthalten sind ist überalll gleich, aber welche Header daten des JPEG im avi sind unterscheidet sich von encoder zu encoder.

    Zu MJPEG2000 kenne ich nur eine implementierung,die von Morgen Multimedia. Gibt es da noch mehr, wenn möglich opensource?

    AC-Sama(Robert Vincenz)
    (werde für das -Chan zu alt :zunge: )

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden