In YV12 aufzunehmen, funktioniert nur recht selten:
YUY2 wird "interleaved" übertragen, und zwar - worauf der "Name" des Formates hinweist - in den folgenden Bytes pro Komponente und Pixel:
Y1 - U1,2 - Y2 - V1,2
YV12 ist jedoch "planar". Das heißt: Erst wird die gesamte Y-Ebene (mit 1 Pixel pro Byte) übertragen, und dann die U- und V-Ebenen mit halber Auflösung (Mittelwert von je 2x2 Pixeln pro Byte).
Kaum eine Kamera liefert planare Daten.
Ufff. Da fragt sich doch der Laie woher ihr das alles wisst. 
Jahrelanges Training? Oder beruflich?
Hut ab, Gerhard
Oder Google.
Beruflich zum Teil auch (ich z.B. war mal DVD-Author). Bei den meisten aber wohl v.a. Neugier.
Ja, und Erfahrung ist eh das wichtigste:
Erfahrung ist eine nützliche Sache.
Leider macht man sie meist erst, kurz nachdem man sie brauchte...
Original von LigH
In YV12 aufzunehmen, funktioniert nur recht selten[...]
Geht bei mir völlig problemlos (KNC1 RDS + Treiber von iulabs)! Nun muss ich nur noch sehen, ob es einen Qualitätsunterschied gibt oder nicht...
Gerhard.
wie oben schon angedeutet, wirst du Unterschiede am ehesten bei starken vertikalen Farbkontrasten finden können.
Bin gespannt auf deine Ergebnisse.
Besonders krass wird man das bei schrägen Rot/Blau-Grenzen sehen - da wird ein gewisses "bluten" (ausfransen) der Ränder sichtbar, weil da fast die gesamte Information nur durch die niedriger aufgelösten U/V-Komponenten gespeichert werden.
(Die folgenden Bilder sind jeweils per Pixel-Resize zweifach vergrößert)
RGB24: Red-Blue.avi
YUY2:
AviSource("Red-Blue.avi")
ConvertToYUY2()
YV12:
AviSource("Red-Blue.avi")
ConvertToYV12(false)
Erst mal danke sehr für die Beispiele, die sind sehr eindrucksvoll. 
So eindrucksvoll, dass ich schwer am überlegen bin, die von mir nur für mich aufgenommenen Filme doch wieder in DivX 5 zu speichern. (Ich hoffe, dass die SAP DivX Player wenigstens mit DivX 5 kein Problem haben.)
Allerdings muss ich auch sagen, dass ich bei den ersten Tests (subjektiv) zwischen YUY2 und YV12 Aufnahmen (Viva Plus) keine sonderlichen Unterschiede feststellen konnte. Übrigens auch nicht beim Coden! Es scheint zumindest für DivX 5.05 egal zu sein, ob man YUY2 oder YV12 Material einspeist -- der Sache gehe ich noch nach, aber ich habe fast den Verdacht, als würde DivX das Eingangsmaterial stillschweigend in RGB konvertieren... Hatte aber auch nur 30 Minuten Zeit für die Tests. (So ist das mit der lieben Famile... )
Und jetzt noch eine Schlussfrage: Kann man überhaupt mit CCE auch im YUY2 encoden? Oder reduziert der unweigerlich auf YV12? Und wenn man es kann, wie stehen die Chancen, dass der SAP das verarbeiten kann?
Danke, Gerhard.
ups, jetzt wollte ich gerade mal mit ein paar Speed-Tests (Farbraumkonvertierung) spielen, da stelle ich fest, dass AviSynth 2.52 beim Laden eines DivX5 (DX50) Filmes daraus implizit einen YV12 macht!
Ich mache nichts anderes als den Film (Magnum) mit AviFileSource einzulesen und das avs mit VirtualDubMod zu laden. Ein Blick auf die File->Information -- und der erzählt mir, es wäre YV12!!
Das wundert mich, weil YV12 doch erst seit Version 2.5 überhaupt möglich ist. Läuft da was schief?
Gerhard.
Ähh, peinlich. Gut, wer lesen kann...
aus dem AviSynth Handbuch
Seit AviSynth v2.5 ist der Standardwert des pixel_type Parameters auf YV12 geändert worden.
Hüstel... 
PS: Aber der war mal YUY2!!! Jaaaaaa, ganz bestimmt!
{ Verdammt - hätte ich nur noch mal vorher nachgesehen... }
__
Ja, na und? MPEG 1, 2 oder 4 speichern das Video im Format 4:2:0 - und das ist praktisch das gleiche wie YV12. Das bedeutet: Genauer als YV12 sind die Daten gar nicht gespeichert, wenn man DivX 5 benutzt - denn das ist ja grundsätzlich MPEG-4. Das selbe bei DVD-Video: MPEG-2 ist auch 4:2:0 - also wie YV12.
Deshalb ist die MPEG2Dec3.dll für AviSynth 2.5x auch optimal, weil keinerlei Konvertierung von MPEG-2 (DVD) über AviSynth (YV12) zu MPEG-4 (DivX) notwendig ist.
Wird dagegen AviSynth 2.0x verwendet, muss der MPEG-2-Decoder für die Farbkomponenten die Zeilen zwischendurch verdoppeln, damit AviSynth im YUY2-Modus arbeiten kann (und zusätzlich auch von planar in interleaved umschaufeln), und der nächste MPEG-Encoder halbiert sie hinterher wieder (und speichert planar).
Und wird es zwischendurch gar RGB, dann vervierfacht sich die Anzahl der U/V-Pixel sogar, bevor dann auch noch von YUV nach RGB konvertiert wird - und später wieder zurück.
Also egal ob das "Ausgangsvideo" (oder besser: Das Zwischenformat in AviSynth) für den MPEG-Encoder mal RGB oder YUY2 war: In den MPEG-Daten wird es immer zu YV12 bzw. 4:2:0.
__
Der CCE kann leider in den verbreiteten Versionen nicht YV12 direkt lesen, weil er - trara - "planare" Videoformate nicht verarbeiten konnte. Möglich, dass die neuesten Versionen das jetzt können (bin da nicht so auf dem neuesten Stand bei MPEG-2-Encodern).
Wow. viel Info. Muss ich erst mal Hintergrundinfos lesen um wirklich alles zu verstehen ... und zu behalten.
Original von LigH
[...]Der CCE kann leider in den verbreiteten Versionen nicht YV12 direkt lesen[...]
Das hab ich schnell mal getestet, es geht, bringt aber scheinbar nichts.
gerhard.
Ich musste schnell noch mal was korrigieren - da stimmte nämlich doch was nicht. Deshalb hier noch mal ein Link zu einer Seite, wo die Chroma-Subsampling-Konfigurationen (4:4:4 | 4:2:2 | 4:1:1 | 4:2:0) sehr schön mit Bildern erklärt wurden:
http://www.mir.com/DMG/chroma.html
Die Beschreibung für die AVI-Codecs bzw. Pixelformate ist aber nach wie vor hier am vollständigsten zusammengefasst:
http://www.fourcc.org/fccyuv.htm
Man beachte besonders die Trennung "Packed / Planar YUV formats".
Gute Links.
Das Puzzle wird vollständiger.
Nun stellen sich für mich zwei Fragen, die :google: mir nicht beantworten konnte:
(a) Was für einen Vorteil sollen planare Formate haben? Als Informaticker würde ich sie nicht so klasse finden, da man mit Puffern arbeiten muss. Ein packed Format kann man leichter als Stream verarbeiten.
(b) Ich konnte nirgendwo finden, wie Cr und Cb die Farbinformation berechnen. Es wird mit "Hue" (Buntton) verglichen, aber mehr als ein Vergleich kann es nicht sein, da die Farbmodelle mit Buntton erst Ende der 70er entwickelt wurden und ja auch immer eine Sättigung benötigen. (Als könnte man sowieso Cr und Cb nur mit Buntton+Sättigung vergleichen.) Dann könnte Cr dem Winkel bei Buntton entsprechen und Cb der Sättigung oder umgekehrt. Aber wie gesagt, FarbTV gab es vor 1978... Also müssen Cr und Cb anders die Farbe "berechnen"... Hast Du dazu auch einen Link?
Gerhard.
ad a) manchmal können code-Teile unabhängig vom Kanal geschrieben werden, also "zuerst Y, dann U, dann V abarbeiten" und nicht dauernd wechseln und möglicherweise entpacken. Das gilt nur bei echten Filtern, nicht wenn nur die Daten geschaufelt werden.
ad b)
r=1.164383*(y-16)+1.596027*(u-128) + .5;
g=1.164383*(y-16)-0.812968*(u-128) - 0.392*(v-128)+.5;
b=1.164383*(y-16)+2.017232*(v-128) + .5;
Y = ( 0.299R + 0.587G + 0.114B)(219/255) + 16.
Cb = (-0.299R - 0.587G + 0.886B)(112/255) + 128.
Cr = ( 0.701R - 0.587G - 0.114B)(112/255) + 128.
Da gibt es dann noch diverse Unterschiede, wie die Formeln GENAU aussehen, aber im Prinzip ist
Y = a.R + b.G + c.B
Cb = B - Y
Cr = R - Y
Mehr zu a)
Ein 'gepacktes' Format wird Zeile für Zeile und (mehr oder weniger) Pixel für Pixel gespeichert - wenn also jedes Pixel seine eigenen Kanalkomponenten für sich hat (4:4:4) oder die Farbkanäle nur zeilenweise einen Mittelwert repräsentieren (4:2:2), mag das noch möglich sein.
Aber wenn Mittelwerte auch noch über zwei Zeilen hinweg gespeichert werden (4:2:0), dann frage ich dich, wie man die Werte eines 2x2-Pixel-Quadrates denn 'gepackt' überhaupt speichern soll:
1. Y-Wert: links oben = O.K.
2. Y-Wert: rechts oben = O.K.
3. Y-Wert: links unten - Sprung in eine andere Zeile! Böse, böse...
Du findest auf der FourCC-YUV-Seite nirgends einen Codec, der gepackt eine "Sample Period" in Y-Richtung von größer als 1 verwendet. Planes mit quadratischem Subsampling ("Sample Period" X = Y) findest du nur im Bereich der planaren Formate.
Farbmodell: Danke, ich habe auch noch in einem Buch ein wenig über das CIE Lab Farbmodell gelesen und verstehe es soweit, dass ich damit zufrieden bin. (In einem anderen Zusammenhang zwar, aber ich glaube (kann mir das jemand bestätigen?) dass das "Y-Ca-Cr" Modell nichts anderes als ein diskretes CIE Lab Modell ist, was mit den Formeln auch ganz gut hin kommt...)
Planar/Packed: Hm, stimmt, bei vielen Filtern ist ein planares Format auf einen ganzen Frame bezogen schneller und wenn man nur eine Komponente (z.B. Luminanz) betrachten muss, auch Pixelweise. Man muss halt nur oftmals den gesamten Frame puffern (wenn man mehr als eine Komponente betrachten muss) -- und bei drei Planes sollte man das besser schnell machen...
Der Nachteil, den LigH nannte, leuchtet mir indes nicht ein, denn bei 4:2:0 richte ich eben einfach einen n-Zeilen Puffer ein. (Z.B. mit n=2) Ist noch immer weniger als drei komplette Planes zu speichern (Ok, eine Plane ist natürlich nur ein Byte tief. [Keiner wird eine Plane mit weniger als 1 Byte/pixel aufbauen...]) Vielleicht verstehe ich das doch noch nicht.
Aber ich denke weiter darüber nach. 
möglicherweise bezieht er sich auf das cache-Verhalten vom Prozessor.
Ob eine Zeile im cache ist oder nicht, bestimmt massiv das Tempo.
Wenn man Zeilensprünge macht, sind die Daten garantiert nicht im cache.
Naja, moderne CPUs haben einen solchen Monster-Cache... Und bei planaren Modellen wäre das doch noch schlimmer (ausser man benötigt nur eine plane, klar.)
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
