Welches YUV ist richtig bei AVISource?

  • Hallo,

    habe seit langem mal wieder einen reencode machen müssen.
    Quelle ist ein XVID-Avi mit B-Frames und Qpel.
    Das habe ich mit megui nach h.264 gewandelt.
    Danach habe ich mit VDubMod screenshots verglichen.
    Dabei ist mir aufgefallen, das mein h.264 heller ist als die Quelle. Es handelt sich um die typischen YUV-Helligkeitsschwankungen, die auch nur bei einigermaßen eingestelltem Bildschirm sichtbar sind.
    Mit dem Ergebnis kann ich leben, jedoch interessiert mich welches Bild richtiger ist?

    Mein Wissensstand:
    - AVISource() verwendet seit Avisynth 2.5 YV12 als Standard wenn nichts anderes übergeben wird.
    - Beim XVID decoder habe ich bei Farbraum "no Force" gewählt und ffdshow sagt mir beim abspielen das es YUY2 vom XVID-decoder bekommt.

    Meine Frage, wird in Avi's mit "h.263 ASP" denn 4:2:0 (YV12) oder 4:2:2 (YUY2) gespeichert?

    Denn ich wüsste gern ob AVISource einfach nur falsch erkennt oder falsch von YUY2 nach YV12 wandelt. Bei korrekter Wandlung der Farbräume sollte der Helligkeitsunterschied doch nicht so auffällig sein?

    Was meinen die Profis?

    P.S.: Wenn ich in AVISource YUY2 übergebe oder ein ConvertToYUY2 angebe im script habe ich keinen Helligkeitsunterschied zum original avi.

    MfG
    Supermario

  • Ehrlich gesagt ist mir nicht so ganz klar, was du mit "typischen YUV-Helligkeitsschwankungen" meinst. Normalerweise sollte es überhaupt keine Unterschiede zwischen YV12 und YUY2 in der mittleren Helligkeit geben, da die Helligkeitswerte bei beiden Varianten volle Auflösung haben, nur die Farbigkeitsdifferenzen werden unterschiedlich fein aufgelöst. Selbst Rundungsfehler zwischen RGB und YUV sollten nicht wirklich auffallen.

    MPEG-4 ASP und MPEG-4 AVC speichern beide im "Main Profile" normalerweise YUV 4:2:0 (ähnlich YV12). Im "High Profile" ist auch YUV 4:2:2 möglich, wird aber weder von XviD für ASP noch von x264 für AVC angeboten.

    Für mich kann es eigentlich nur zwei Ursachen für Helligkeitsunterschiede geben:

    a) VirtualDub verwendet zur Ansicht von planarem YV12-Video einen VfW-Codec, der YV12 in RGB24 konvertiert, weil im Vorschaubild nur Packed-Pixel-Formate funktionieren, und dieser Vorschau-Codec berechnet die Konvertierung ungenau (oder mit TV/PC-Scale-Konvertierung, also auf vollen statt reduzierten Kontrast).

    b) Ein DirectShow-Mediaplayer stellt YV12 als Hardware-Overlay dar, und das Overlay hat falsch eingestellte Helligkeitsregler im Grafiktreiber.
    __

    AviSource liefert ohne Vorgabe übrigens das Grafikformat, für das sich der VfW-Codec zur Decodierung entscheidet. Nach welchen Kriterien diese Entscheidung stattfindet, kann ich nicht mit Sicherheit sagen. Es kann Codecs geben, die grundsätzlich ein bestimmtes Format bevorzugen (vielleicht: progressiv => YV12, interlaced => YUY2 -- ohne Gewähr, interlaced YV12 ist auch möglich!); es kann auch sein, dass das Format bevorzugt wird, das beim Encodieren in den Codec übergeben wurde (wenn beim Encodieren YUY2 verwendet wurde, steht im AVI-Header "durchschnittlich 16 bit/Pixel", wenn YV12 verwendet wurde, "durchschnittlich 12 bit pro Pixel" - aber beides hat nicht das geringste mit der komprimierten Bitrate zu tun).

    Es gibt ansonsten nur den Ausschlussfall - dass man in AviSource ein Wunsch-Format angibt, das der zum Decodieren verwendete Codec nicht liefern kann (z.B. gab es wohl mal DV- oder MJPEG-Codecs, die kein YV12 erzeugen konnten, weil planare Formate eher unüblich waren). Dann gibt es in AviSynth eine Fehlermeldung.

  • Hallo Ligh,

    also nach deinen Angaben müsste meine Quellmaterial in 4:2:0 vorliegen. Somit ist die Entscheidung die AVISource trifft richtig und übergibt YV12.

    Mich wundert dann nur das der XVID decoder es beim abspielen als YUY2 ausgibt. Das hab ich überprüft indem ich das Originalvideo im Zoomplayer abspiele und ffdshow hinter den XVID-decoder schalte. Der zeigt mir dann im Info-Fenster welchen Farbraum die Quelle hat.
    Ich kann im XVID-decoder auch YV12 erzwingen, aber die Option "no Force" gefällt mir besser, da dann keine Farbraumkonvertierung stattfindet wenn nicht nötig.

    Der Fehler scheint also an VDubMod zu liegen. Nur ist mir das bei anderen Vergleichen von Früher nie aufgefallen.
    Ich probiere noch ein bißchen rum, vielleicht finde ich heraus wer das Bild heller oder besser dunkler macht, denn scheinbar ist das hellere Bild das richtige.

    Was ich mit typischen YUV-Helligkeitsschwankungen meine ist irgendwie in meinem Kopf gespeichert das verschiedene YUV-Farbräume unterschiedliche Helligkeitsauflösung verwenden. Aber wenn du sagst das 4:2:0 dieselbe Helligkeitsauflösung hat wie 4:2:2 dann weis ich auch nicht :(
    Die unterschiede die ich meine sind auch wirklich gering, vielleicht können einige Menschen es gar nicht sehen.
    Ligh es ist auch nicht PC/TV-Scale, das wäre überdeutlich zu sehen.

  • Als decompressor in VDubMod steht XVID, da ich keinen extra vfw xvid decoder in meinem system finde, nehme ich an das es der selbe decoder ist wie für directshow. Außerdem wollte ich damit nur sagen, das bei "no force" YUY2 übergeben wird und nicht YV12, wobei YV12 richtiger wäre, da das AVI ja in 4:2:0 vorliegt.
    Habe aber bemerkt, wenn ich in XVID YV12 erzwinge dann sagt ffdshow bei input "IYUV" also inverses YUV. Ich wollte mit dieser vorgehensweise nur herausfinden, ob YUY2 oder YV12 in dem AVI steckt.
    Da du aber sagtest in h.263 ASP gibts nur 4:2:0 kanns doch nur YV12 sein und mich wunderte dann, das bei "no Force" YUY2 übergeben wird.

    Edit

    Ich wollte nochmal was zu meinen "YUV-Helligkeitsschwankungen" sagen. Wahrscheinlich nehme ich es nur als Unterschied in der Helligkeit war, in wirklichkeit ist es aber ein Farbunterschied. Da du ja sagtest die Helligkeit ist gleich aufgelöst und nur die Farbdifferenzen sind unterschiedlich. Jetzt kam ich gerade auf die Idee, dass es für das bestimmen der RGB-Werte von U und V ja unterschiedliche algorithmen gibt, z.B. YUV und YCBCR. Vielleicht findet irgendwo ein falscher algorithmus anwendung und verschiebt die Farbe minimal. Nur so'n Gedanke.

    Einmal editiert, zuletzt von Supermario (7. September 2009 um 15:39)

  • @ Supermario:

    VirtualDub (und seine Modifikationen) als AVI-Editoren verwenden den XviD-VfW-Codec zum Decodieren.

    Die "XviD Decoder configuration" dürfte allerdings nur den XviD-DirectShow-Decoder betreffen.

    MPEG-4 ASP muss übrigens nicht zwangsläufig mit der parametrischen H.263-Quantisierung (ITU-Standards haben einen Großbuchstaben vor dem Punkt!) verwendet werden, die MPEG-Matrix-Quantisierung ist auch erlaubt (sogar mit eigenen Matrizen).

    H.264 ist nicht wirklich nur ein direkter Nachfolger von H.263, sondern eine ganze Menge mehr; so wird dafür meist nicht einmal die für H.261/H.263 (ISDN-Telefonie), M-JPEG, DV, MPEG-1, MPEG-2 und MPEG-4 ASP typische Diskrete Cosinus-Transformation für 8x8-Sample-Blöcke verwendet, sondern eine davon abgeleitete Integer-Transformation für 4x4-Sample-Blöcke...
    __

    @ Goldi:

    Warum? Er fragt doch "Welches YUV: YV12 (4:2:0) oder YUY2 (4:2:2)?" - also "Streuselkuchen mit Apfel oder mit Pflaume"?

  • Sorry das ich mich erst jetzt wieder melde.

    Habe leider noch nicht rausgefunden woran meine Bildunterschiede liegen.
    Aber zufällig hat das Quell-AVI eine custom Matrix.

    LigH:
    Da du dies ja expliziet erwähnt hast, meine Frage, hat denn eine Custom-Matrix etwas mit dem verwendeten YUV-Farbraum zu tun? Also das durch die Custom-Matrix eine falsche Annahme vom vfw-codec oder von Avisynth gemacht wird und dadurch die Wandlung von dem Quell-YUV-Farbraum nach RGB falsch gemacht wird. Es muss ja für den Screenshot nach RGB gewandelt werden.

    Beim abspielen meine ich auch keinen unterschied zu sehen. Habe beide Videos (Quell-AVI und H.264 reencode) gleichzeitig abgespielt. Das ganze auch auf einem Röhrenmonitor, sodaß Unterschiede im Bild nicht durch unterschiede im Blickwinkel eines TN-Panels entstehen.

    Der Unterschied den ich sehe ist also nur bei den Screenshots.
    Ich habe die Screenshots auf einem 2. Rechner wiederholt, um auszuschließen, das es die Grafikkarte ist, oder ein Fehler in der decodierungskette.

    Wie gesagt wundert mich dieser minimale helligkeits- oder Farbunterschied, weil er bei anderen AVI nach sonstwas recodierungen nicht auftritt.

    Ich hoffe ich werde es irgendwann rausfinden.

    MfG
    Supermario

  • Ich würde gern auch mal solche Screenshots sehen, um zu vergleichen, wie stark die sich unterscheiden, und wo.

    Außerdem könnte dich der AviSynth-Filter "Histogram" interessieren. Der stellt dar, welchen Wertebereich die Komponenten haben. Da wirst du schnell sehen, ob z.B. das eine Video sich auf Bereiche von 16 bis 235 beschränkt, oder den kompletten Umfang von 0 bis 255 ausnutzt.

    Die Beschränkung stammt übrigens noch aus der Fernsehtechnik, da werden "Superschwarz" und "Superweiß" nie für den Bildinhalt, nur für Steuersignale verwendet. Bei der digitalen Speicherung verlieren die zwar ihre Bedeutung, für die Kompatibilität mit den FBAS-Signalerzeugern im DVD-Player wird aber weiter darauf geachtet. Weil der PC-Monitor dagegen den vollen Umfang darstellt, wirken Videos, die sich auf den Fernseh-Signalumfang beschränken, am PC etwas flach (kontrastarm).

  • So, da bin ich wieder. Habe jetzt durch zufall rausgefunden wo der Fehler liegt.

    Wenn ich ein AVI direkt in VirtualDub öffne wird als VFW-codec XVID verwendet.
    Wenn ich über "AVISOURCE" oder "DIRECTSHOWSOURCE" eine Videodatei öffne wurde bei meinen beiden PC's DIVX als VFW-Decoder verwendet.
    Nutze ich als VFW aber XVID oder FFDSHOW, sehen die Screenshots von "AVISOURCE" und "DIRECTSHOWSOURCE" genauso aus, wie wenn ich das AVI direkt öffne.

    Also deine anfängliche Vermutung LigH war richtig. Ich musste nur erstmal rauskriegen wie ich den zu verwendenden VFW-Codec ändere.

    Der DIVX-VFW muss sich irgwann mal dazischengeschoben haben, denn ich sagte ja, das es früher bei mir keine Helligkeitsunterschiede bei Screenshot-vergleichen gab.

    Man sollte also den DIVX nie als VFW verwenden, er ist fehlerhaft, zumindest bei der Anzeige in VirtualDubMod.

    Mein H.264 reencode wurde aber korrekt behandelt beim umwandeln, sonst würden die Helligkeitsunterschiede ja nicht durch ändern desVFW-codec verschwinden.

    Ich finde es aber schon seltsam wie DIVX sich da verhält.

    MfG
    Supermario!

Jetzt mitmachen!

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