@ Kika - Bzgl. Luma bei PicVideo

    Hier meine Tests.

    Also, ... wenn ich ein via PicVideo enkodiertes mjpeg wiederum via PicVideo dekomprimiere und NICHT mit pixel_type=rgb24 öffne, entspricht der Output exakt dem Original raw YUY2. Habe nur gemerkt, dass in FFdshow/FFvfw ein Bug exisitiert, wenn via Pixel-Type=rgb24 ein mjpeg geöffnet wird. Bei Pixel-Type=yuy2 ists ebenso mit dem raw YUY2 identisch.

    Entweder ich habe da was misverstanden oder .... hmmmm. Denn sodann würde PicVideo vollkommen richtig arbeiten?!

    Bitte checkt das mal.

    Hier die Streams die mit Picvideo komprimiert wurden:

     [Blockierte Grafik: http://img72.imageshack.us/img72/2570/cpicvideoanddpicvideopixeltype.jpg]



     [Blockierte Grafik: http://img105.imageshack.us/img105/2570/cpicvideoanddpicvideopixeltype.jpg]


     [Blockierte Grafik: http://img72.imageshack.us/img72/4697/cpicvideoanddffdshowpixeltypey.jpg]


    (hier ist der bug von FFdshow bei nutzung von "PixelType=rgb24" zu sehen, ohne ists ok - siehe hier drüber )
     [Blockierte Grafik: http://img105.imageshack.us/img105/5535/cpicvideoanddffdshowpixeltyper.jpg]



    Und hier die Streams, welche mit FFdshow komprimiert wurden:

     [Blockierte Grafik: http://img210.imageshack.us/img210/844/cffdshowanddffdshowpixeltypeyu.jpg]



    Hier ist wieder der Bug zu sehen, wenn der ffdshow decompressor in Zusammenhang mit Pixel_Type=rgb24 genutzt wird (rechte Kante blauer Balken).
     [Blockierte Grafik: http://img220.imageshack.us/img220/5270/cffdshowanddffdshowpixeltyperg.jpg]


     [Blockierte Grafik: http://img217.imageshack.us/img217/3738/cffdshowanddpicvideopixeltypey.jpg]


     [Blockierte Grafik: http://img217.imageshack.us/img217/3049/cffdshowanddpicvideopixeltyper.jpg]



    Kika, die Histogramme sagen mir, dass vorab ein Pixel_Type=rgb24 zu einem verfälschten Ergebnis führt. Oder habe ich da was übersehen?


    @ Ligh & Fr_An .. etc.
    Dieser forced RGB Output bug beim Dekodieren von mjpeg via FFdshow ist vor allem für Programmierer wichtig!
    Wenn hier ein Avi eingeladen wird und sodann der Videostream via WinAPI mit dem im System installierten Codec als RGB32/RGB24 zwecks Anzeige dekodiert wird .... gibts solche Luma Fehler wie oben zu sehen. Ich denke das ist Programmierumgebungs unabhängig, da alle beim Dekodieren von Videostreams auf den im System entspr. installierten Decoder zugreifen. Und da immer mehr Nutzer FFdshow installiert haben, kanns da zu helle oder verfälschte Anzeigen in Applikationen geben wenn mjpegs dekodiertund angezeigt werden.

    Da müsste man jetzt erstmal nachsehen, welche Versionen von PicVideo Du und ich benutzt haben. Kann ich im Moment nicht, da schaue ich aber mal nach.

    Es gab ja mal vor längerer Zeit hier und auch im englischen Doom9 mehrere Diskussionen zur Lumarange. In der Tat ist es so, dass PicVideo bei RGB24 die Range von 16-235 liefert (zumindest meine Version) - was verkehrt ist. In diesem Fall möchte ich das aber auch so haben. Denn es erspart später das Komprimieren der Range mit TMPGEnc (Output YUV Data as basic YCbCr ist dann aktiviert).

    Mein PicVideo MJPEG Codec ist Version 2.10.029.

    Aber ...

    Wenn dein Eingabegerät mit vollen 0-255 aufnimmt, ist das sodann mit Pixel_type=rgb24 auch ok. Nur hast du am Ende mehrere Cspace Konvertierungen und vor allem von YUY2 hin zu rgb und sodann zurück zu YUV, wo es am Ende wiederum als rgb in TmpgEnc reingeht, was imho schlimmer ist als YUY2<->YV12.
    Würde eher hingehen und YUY2 als YUY2 dekodieren, Filter etc. anwenden und am Ende ConverttoRgb(xxxx) nutzen. Wenn dein eingehendes YUY2 wirklich 0-255 belegt, kannst du als xxx die Werte nutzen, welche die Luma bei YUV 0-255 sodann in rgb bei 0-255 belassen. Somit vermeidest du neben der Farbraumwandlung ein hin und her komprimieren der Lumarange, was fix zu Abrissen im Histogramm führen kann, was wiederum zu Treppchen führt, die wiederum bei stärkerer Quantisierung in Verläufen richtig verstärkt rüberkommen.

    Wie immer: Alles Vermutungen ;)

    Merde, meine Antwort von gestern Abend ist irgendwo ins Nirwana verschwunden ... :(

    Also, die Karte liefert 16-235, PicVideo liefert 16-235 - im RGB-Mode. Das ist eigentlich verkehrt, für meine Zwecke aber richtig. Der damalige Thread ist leider nicht mehr auffindbar, aber drauf gekommen bin ich vor längerer Zeit, als ich TMPGEnc mit CCE verglich. Zum Test hatte ich MJPEG-Videos, die direkt in den Encodern geöffnet wurden, und die wurden in TMPGEnc von den Farben her immer viel flauer. Das lag halt daran, dass TMPGEnc RGB anfordert und in der Standard-Einstellung davon ausgeht, dass die Range 0-255 ist.
    CCE hingegen nimmt YUY2 und geht von 16-235 aus, daher wurden die Videos dann auch korrekt encodet.
    Diese Erkenntnisse habe ich dann eben auch in all meine AVISynth-Scripte übernommen.

    Kommt auch auf den Treiber der Karte an. Meine SAA7134er gibt 0-255 weiter und manche Sender gehen auch Teilwiese über 16-235 hinaus, gerade was den Bereich Dokumentationen angeht, da clippt sehr oft der Weisswert bei jenen Übertragungen von Videokamer-Aufnahmen. Anarchotron im doom9 hat mit Beispielen belegt, dass seine SAA7134 mit seinem Treiber (ich glaube Philips Generic) lediglich 16-235 überträgt.

    Viell. sollte man den Workout anders angehen um eben jene von dir erwähnten Wandlungen zu minimieren.

    Meine Beispiele oben zeigen mir, dass bei einer Weitergabe von YUY2 via Picvideo das Bild in seiner Lumarange nicht verändert wird. Gehst du also unten hin und setzt ein ConverttoRGB24() rein, wird dein 16-234 Luma auf 0-255 expandiert, was sodann innerhalb von TmgEnc wieder auf 16-235 gebracht und encodiert wird (Output YUV as CCIR 16-235). Das ist die Theorie, muss ich mal testen. Es wurde oft gesagt, TmpgEnc croppt die Lumarange, was aber nicht stimmt, es nimmt lediglich Wandlungen vor, wie in Avisynth auch. Wenn also ein YUY2 mit 0-255 vorliegt und es via simplem ConverttoRgb24() gewandelt wird, schieben sich die Lumawerte von 0-16 und 235-255 natürlich ins Nirvana, da ja die YUY2 16-235 auf RGB 0-255 gebracht werden.

    Zitat

    Es wurde oft gesagt, TmpgEnc croppt die Lumarange, was aber nicht stimmt, es nimmt lediglich Wandlungen vor, wie in Avisynth auch.

    Richtig, das war damals der Auslöser für die ganze Geschichte - keiner wollte mir glauben *snif* ;)
    Allerdings ist das jetzt schon wieder so lange her, dass ich die Details auch nicht mehr im Kopf habe. Ich muss mal ein paar meiner Archiv-CDs zu Hause durchsuchen, vielleicht habe ich die Beispiel-Bilder und -Clips sowie die Texte dazu aufgehoben - das wäre sehr nützlich.

    Wenn du Lust hast könnten wir mal eine Seite konzepieren, in der genau diese Encoder/Decoder Eigenheiten dokumentiert und beschrieben werden.
    So auch die entspr. Dinge bei bestimmten mpeg2/ASP/ACV Encodern.

    Solch eine Seite wäre dann viell. eine kleine Referenz (ich erinnere an deine GOP-Bibel auf der EDV-Tip Seite von Stephan). Habe Golive hier und könnte das technisch adequat umsetzen.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden