Warum man YV12 tunlichst meiden sollte...

Danke für die Beantwortung einer Frage, die sich bei mir eigentlich erst im Ansatz manifestiert hatte
In der Vergrößerung sieht das aber gar nicht mal so doll für YV12 aus....
Da stellt sich doch die Frage warum QuEnc so großen Wert darauf legt ???

Gruß,
Obscura

Zitat von Obscura

In der Vergrößerung sieht das aber gar nicht mal so doll für YV12 aus....
Da stellt sich doch die Frage warum QuEnc so großen Wert darauf legt ???

Weil DVDs YV12 nutzen. Und bei DVD Konvertierungen erspart man sich so zwei Farbraumkonvertierungen.

Worauf muss ich denn hier besonders achten?! ... Nun ja, die Ränder zwischen Orange und Blau sind schon böse; und der gelbe Schnabel des rechten Fisches erst - so farblos! :nein:

@ LigH

"Könnte" es mal "irgendwann" vorkommen, dass es z.B. in XVID eine YUY2 Enkodier Option geben wird?

- würde das keinen Sinn machen?

- oder hat der Inc. da was in Xvid übersehen, denn dann gibts nen Termin beim Augenarzt

Ich erinnere mich schwach daran, dass darüberhier schon mal spekuliert wurde. Das würde aber bedeuten, auf ein 4:2:2-Profil (siehe Profile@Level) gehen zu müssen. Und das wollten die Entwickler (zu denen ich nicht gehöre) mit Sicherheit nicht in einer Version 1.x. Sinn machen würde es bestimmt, auch wenn dann höhere Bitraten und schlechtere SAP-Kompatibilität zu erwarten wären.
__

@ scharfi:

Ich hoffe, du bist einverstanden, dass ich den Beitragstitel mal etwas 'verschönert' habe...

Außerdem würde mich interessieren, unter welchen Vorassetzungen für dich ein YUY2-Codec "vernünftig" ist. Vielleicht hab ich da ja noch einen Vorschlag, sobald ich deine Wünsche kenne.

Es wäre eine klasse Sache fürs Capturen z.B., denn wenn z.B. in Xvid mit sehr niedrigem festen Quantizer gecaptured wird, sieht das Ergebnis recht gut aus und es gäbe kleinere Files, ..... wenn da eben nicht das YV12 4:2:0 Farb Problem wäre.

Ich habe mir ja auch die PVR350 (hardware mpeg2) Screens im Capture Thread angesehen und muss leider sagen, dass da eben (zzgl. YV12 Problem) auch noch jede Menge Blöcke rauskamen, obwohl die Einstellungen ca. avg 6000, max 8000 waren.

Vorteil von XVID 4:2:2 wäre eben, besseres Chromahandling, kleinere Files, recht flotter on-the-fly capture-Encoder für Full 704x576 und eine bessere Qualität als Mainconcept (ganz zu schweigen von PVR250/350, WinDVR, PowerVCR).

Das Schlimme ist, das man die Ergebnisse dort oben auch auf die Konvertierung "DVD MPEG-2 Video -> irgendwas" anwenden kann. Obwohl die zusätzliche Farbraumkonvertierung (YV12 -> YUY2/RGB24/RGB32 -> ?) das Endergebnis eigentlich verschlechtern müßte, ist genau das Gegenteil der Fall.
Ich glaube, die MPEG-2 YV12 Decodierung muß dringend mal generalüberholt werden, denn in ihrer jetzigen Form ist sie unbrauchbar. Wenn man das bei natürlichen Bildern schon so deutlich sieht, was dann erst bei CG Filmen à Shrek, welche überwiegend aus scharfen Kanten und Farbkontrasten bestehen.

A_YV12

LoadPlugin("DGDecode.dll")MPEG2source("DGIndex.d2v",iPP=true)Crop(12,66,-420,-66)

A_ConvertToYUY2()

LoadPlugin("DGDecode.dll")MPEG2source("DGIndex.d2v",iPP=true)ConvertToYUY2(interlaced=true)Crop(12,66,-420,-66)

Muß man denke ich nichts zu sagen.

B_YV12

LoadPlugin("DGDecode.dll")MPEG2Source("DGIndex.d2v")Crop(8,8,704,560)LanczosResize(704,384)

B_ConvertToYUY2()

LoadPlugin("DGDecode.dll")
MPEG2Source("DGIndex.d2v")
ConvertToYUY2()
Crop(8,8,704,560)
LanczosResize(704,384)

Man beachte Rods Nase und Belas Rücken.

@scharfi: damit keine Mißverständnisse aufkommen, wäre es eventuell ganz gut, wenn Du oben in den ersten Thread noch kurz einfügen könntest, wann ein YUV2 Codec einem als User helfen würde und wann nicht.
Wenn die Quelle schon Yv12 ist, ist eine Farbraumwandlung doch immer noch unsinnig, oder ?

Cu Selur

Zitat von scharfis_brain

deswegen die treppchen bei B
und deswegen auch das kaputte interlacing bei A, weil eben dieser Filter progressive YV12 vermutet. und das ist falsch.

Aber B ist doch progressive?

Zitat von Selur

Wenn die Quelle schon Yv12 ist, ist eine Farbraumwandlung doch immer noch unsinnig, oder ?

Bei meinem Test oben waren die Quellen YV12

EDIT
Nur um Mißverständnissen vorzubeugen:
Mit DivX 5.2, sowie mit XviD [Koepi's binaries (1.0.1-05062004 Final Release] und ffdshow [20040808] als YV12 Decoder tritt obiger Mist auf.

Achso, jetzt verstehe ich das Grundproblem. Es gibt wohl keinen gängigen Codec, der in YUY2 speichern kann :(. Wenn also Quelle und Ziel YV12 sind, macht eine Farbraumkonvertierung zu YUY2 zwischendrin natürlich keinen Sinn - es sei denn, die Filter verlangen es oder sind mit YV12 buggy.

Ich habe übrigens einen Bug im XviD Decoder gefunden.
Baut Euch mal ein AviSynth 2.55 Skript, in dem eine YV12 Quelle geladen und nur geschnitten (crop) wird. Schneidet dort rechts und links asynchron, natürlich so, das x Mod4=0 bleibt.
Beispiel:

LoadPlugin("DGDecode.dll")
MPEG2Source("DieAerzte.d2v")
Crop(20,0,-16,-0)

-> siehe Anhang
ffdshow produziert so etwas nicht.

Zitat von Viperzahn

Es gibt wohl keinen gängigen Codec, der in YUY2 speichern kann.

Es gibt eine ganze Menge Codecs, die mit 4:2:2-Chroma-Subsampling (wie auch YUY2) speichern können - z.B. HuffYUV. Nur MPEG- und H.261/H.263-basierte Codecs verwenden normalerweise 4:2:0-Chroma-Subsampling (wie in YV12) -- außer man hat Codecs, die erweiterte Profile@Level unterstützen, in denen auch 4:2:2-Subsampling erlaubt wäre.

Ursache ist vor allem wohl, dass man bei 4:2:0-Chroma-Subsampling neben besserer Komprimierbarkeit auch eine gleichmäßige Reduzierung der Auflösung in beiden Richtungen (horizontal und vertikal) hat, was der planaren Speicherung (Helligkeit Y und Farbigkeits-Differenzwerte Cb=U und Cr=V unabhängig voneinander) in DCT-Blöcken entgegenkommt.
__

Zitat von Viperzahn

Wenn also Quelle und Ziel YV12 sind, macht eine Farbraumkonvertierung zu YUY2 zwischendrin natürlich keinen Sinn - es sei denn, die Filter verlangen es oder sind mit YV12 buggy.

So ist es: Erstens verlangt das einmal vertikal Verdopplung (bzw. Interpolation) der Farbigkeitswerte bei 4:2:0 => 4:2:2 und später wieder vertikal Halbierung bei 4:2:2 => 4:2:0; und zweitens verlangt das wie beim "Karten mischen" das Verschieben von planarer in gepackte Speicherung.

Planar:

YYYYYYYYYYYYYYYYUU  VVUU  VV

Gepackt:

YU YV  YU YV


YU YV  YU YV


YU YV  YU YV


YU YV  YU YV

__

P.S.: Die Typen auf dem Bild sehen krank aus, die müssen mal zum Arzt gehen! ;D

Zitat

Es gibt eine ganze Menge Codecs, die mit 4:2:2-Chroma-Subsampling (wie auch YUY2) speichern können - z.B. HuffYUV. Nur MPEG- und H.261/H.263-basierte Codecs verwenden normalerweise 4:2:0-Chroma-Subsampling (wie in YV12) -- außer man hat Codecs, die erweiterte Profile@Level unterstützen, in denen auch 4:2:2-Subsampling erlaubt wäre.

Muß ich denn alles immer ins 1000-Fache zerlegen ;)?
Ich meine gängige Zielcodecs. Das ich eine DVD nicht nach HuffYUV speichere, oder meine TV Captures nicht als HuffYUV oder MJPEG Video auf der Platte liegen lasse, sollte klar sein. Kennst Du einen _aktuellen_ Zielcodec der etwa die gleiche Qualität pro Bitrate liefert wie XviD/DivX5/RV10... und dabei in YUY2 speichert?

Zitat

Ursache ist vor allem wohl, dass man bei 4:2:0-Chroma-Subsampling neben besserer Komprimierbarkeit auch eine gleichmäßige Reduzierung der Auflösung in beiden Richtungen (horizontal und vertikal) hat, was der planaren Speicherung (Helligkeit Y und Farbigkeits-Differenzwerte Cb=U und Cr=V unabhängig voneinander) in DCT-Blöcken entgegenkommt.

Und am Monitor unübersehbare Treppchen + Blöcke an den Kanten, die der Decoder wieder ausbügeln kann, gibts gratis dazu

Aktueller Codec ... Kann ich nicht mit Sicherheit sagen. Aber mit fällt gerade Rududu wieder ein, da schau ich mal nach.

Bis dahin hänge ich mal eine AVI-Datei an, die bei der Beurteilung des Chroma-Subsampling hilft (encodiert mit CorePNG 0.82 - der decodiert eher nach RGB24).
__

Nein, der scheint auch 4:2:0 zu verwenden (eigentlich logisch für einen Wavelet-Codec).