Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
shh 
Anmeldungsdatum: 01.03.2002 Beiträge: 959
|
Beitrag 20 - Verfasst am: Fr Okt 18, 2002 20:31 Titel: |
 |
|
> 4-2-0 bedeutet doch 4 Y Pixel gehören zu 2 Color Pixeln.
Das ist schon richtig.
Qualitätsvorteile bringt dein gerades Addborders aber nicht, weil die Farbwerte ja gleichwertig dür gerade und ungerade Zeilen gelten. (es würde also keine Farbverschiebung auftreten)
Hmm, von der Geschwindigkeit her, wäre evtl. ein theoretischer Vorteil zu erkennen:
Wenn man das wie du machst, wird nämlich eine Color-Zeile weniger geschrieben (pro frame). Ich traue mich aber wetten, daß das garnicht messbar ist.
Wenn Avisynth so intelligent ist, und vor dem decoden den framebuffer schon incl. der Ränder anlegt, ist der Vorteil gleich Null, weil jedesmal pro frame entweder "normal" geschwärzt wird, oder die decodierten Daten vom Film geschrieben werden. (es wird also nichts doppelt oder mehr geschrieben)
Schönen Gruß
shh _________________ shh >>> shh's MPEG-tools |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 21 - Verfasst am: Fr Okt 18, 2002 22:48 Titel: |
 |
|
Ich will ja keine Hoffnungen zerstören, aber letztendlich reden wir hier ja schlieslich über DCT-transformierte und quantisierte Blocks bzw. Macroblocks - Pixel gibt's da doch gar keine. Die werden ja erst bei der Decodierung wieder erzeugt.
Wie welche Pixel da ursprünglich mal hinein geraten sind, ist ziemlich schnurz. Und ihre Farbe erst recht.
Wegen der Geradzahligkeit: ALLES, was mit MPEG zu tun hat, wirkt sich in der Hauptsache auf geradzahlig durch 8 oder 16 teilbare Bereiche aus.
Gruß,
Kika |
|
 |
fz1 
Anmeldungsdatum: 03.04.2002 Beiträge: 43
|
Beitrag 22 - Verfasst am: So Okt 20, 2002 17:26 Titel: |
 |
|
Da hatte ich doch was übersehen...
YUY2 ist 4-2-2, nicht 4-2-0 codiert. Und damit arbeitet Avisynth.
Die Pixel werden zu Makropixeln (Packformat) zusammengefasst und folgendermaßen gespeichert:
(Y0 U0 Y1 V0) (Y2 U2 Y3 V2)...
Jetzt kann man auch erkennen, warum das ungerade horizontale Croppen zu Fehlern führt. (dann werden u und v vertauscht -> komplementärer Farbfehler)
Im MPEG-2 Stream der DVD, haben wir es mit einem YUV 4-2-0 Colorformat zu tun, dass man so nicht bearbeiten
kann, weil die Farbwerte u, v auf zwei Zeilen liegen (TV-Farbauflösung ist sowieso nur halb so groß wie Y-Signal).
1. Zeile (Y0 U0 Y1 ) (Y2 U2 Y3 )...
2. Zeile (Y0 V0 Y1 ) (Y2 V2 Y3 )...
Kommt jetzt noch interlaced hinzu, was ja eine Grundeigenheit des TV ist, wirds erst richtig lustig.
Deshalb convertiert DVD2AVI das Colorformat in 4-2-2! Ich kann mich noch erinnern, wie sich Jackei dabei abgemüht hat, das richtig hinzukriegen.
Das heißt, die Farbwerte werden aus jeweils zwei Zeilen des dekodierten MPEG Streams in einer YUV-Zeile approximiert. Somit kann man vertikal wieder zeilenweise editieren, in der Horizontalen bleibt aber die Einschränkung auf geradzahlige Werte. Jedenfalls gilt das für Avisynth. Hier liegen die Frames wirklich dekodiert (meist mit MPEG2DEC.DLL) im Puffer vor.
Aufpassen muss man natürlich, ob es sich um interlaced Frames handelt.
CCE nimmt YUY2 4-2-2 an und ERZEUGT daraus den 4-2-0 codierten MPEG Stream.
Makroblocks etc. sind interne Objekte des Encoders und spielen erst hier wieder eine Rolle. Zitat: | Qualitätsvorteile bringt dein gerades Addborders aber nicht, weil die Farbwerte ja gleichwertig dür gerade und ungerade Zeilen gelten. (es würde also keine Farbverschiebung auftreten) |
Also richtig SHH!
EDIT:
CCE konvertiert zuerst den Eingansstream in das YUV 4-2-0 Format (Main Profile) und erzeugt dann einen DCT-transformierten und komprimierten MPEG-2 Stream.
Zuletzt bearbeitet von fz1 am Okt. 29 2002,18:38 |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 23 - Verfasst am: Mo Okt 21, 2002 23:36 Titel: |
 |
|
Moment, Moment, Du musst aber unterscheiden zwischen der Art, wie die Farben im Stream gespeichert werden und der Art, wie sie zum Reencoden geliefert werden. Dort sind's nämlich Pixel, und jeder einzelne davon ist YUV-Encodiert.
Bei YUV 4:2:2 sind das dann 8 Bit für Y und je 4 für U und V.
Hergeleitet werden die aus dem Stream, wobei man das auch so verstehen kann, dass jeder Pixel einen eigenen Y- aber nur je zwei Pixel zusammen einen U- und einen V-Wert haben.
Nächste Ebene ist dann MPEG selbst, bei dem die Farbinformationen oder besser die Bildinformationen ja so gespeichert sind, dass pro Macroblock, der nur aus Y-Werten besteht, je ein Block für U und V vorhanden ist. |
|
 |
fz1 
Anmeldungsdatum: 03.04.2002 Beiträge: 43
|
Beitrag 24 - Verfasst am: Di Okt 29, 2002 20:37 Titel: |
 |
|
Ich will den Thread hier nicht weiter ausdehnen, weil's sonst wirklich zu speziell wird.
Wir haben über das richtige Editieren im YUY2 4-2-2 Farbraum mit Avisynth geredet, nicht über die MPEG-2 Codierung in CCE. Wenn man in Avisynth durch falsches Croppen, Resizen oder Bordern Fehler macht, dann produziert der CCE halt Mist.
KiKa hat natürlich Recht, dass im MPEG-Stream die Daten transformiert gespeichert sind.
Aber hier noch eine Korrektur.
1. MPEG benutzt grundsätzlich 8-Bit Auflösung für die Komponenten.
2. YUY2 speichert 8 Bit für Y und jeweils 8 Bit für eine Cb oder Cr Komponente in einem Word = 16 Bit je Pixel.
(Y0 U0)(Y1 V0) = 2 x 16 Bit = 2 Pixel = 1 Makropixel
3. MPEG:
Hier ist die kleinste Blockgröße durch die DCT (Digitale Cosinustransformation) auf 8x8 Pixel für jede Komponente festgelegt. Auf einen 8x8 DCT-Block von Farbwerten (Cb oder Cr) kommen 4 8x8 Y-Blöcke. Ein 4-2-0 Makroblock enthält also auf Grund des Subsamplings 4 Y-Blöcke, 1 Cr-Block, 1 Cb-Block. Seine Größe dehnt sich damit auf 16x16 Pixel aus. Auf dieser Ebene spielt sich auch die Motionkompensation ab.
Zum Makroblock gehören also auch die Farbkomponentenblöcke dazu.
Zuletzt bearbeitet von fz1 am Okt. 29 2002,23:50 |
|
 |
|