OHCI und VV Demo

> o.k. den YUV-Bereich ausserhalb der Norm 16..235

Das ist allerdings ein Thema für sich.
So erzeugt z.B. (fast?) jede Konsumerkamera bei überbelichteten Bildteilen ein RGB-Weiß von über 235.

Wenn man nun in einem Programm, das nicht mit den RGB-Extrembereichen umgehen kann, z.B. zwei Clips, von denen mindestens einer einen solchen "Über-Weiß" Bereich enthält, überblendet, dann kommt es ganau an den Frames, wo die Überblendung anfängt und endet, zu einem Helligkeitssprung, der je nach Bildinhalt SEHR deutlich und SEHR störend sein kann.
Bei Codecs, die nicht mit einem RGB-Bereich diesseits und jenseits 16/235 umgehen können, müsste man also bei FX- und Transitiongebrauch immer die ganzen Clips rendern, um Sprünge zu verhindern. Und selbst dann hat man keinen Einfluss darauf, was der Codec macht, um die RGB-Grenzen einzuhalten. Der eine Codec schneidet einfach das Signal an der Grenze ab. Ein anderer Codec komprimiert das komplette Signal und ändert dadurch auch noch das Kontrastverhalten über den gesamten Luminanzbereich.

So hat ein Codec, der mit RGB unter 16 und über 235 umgehen kann, den Vorteil, dass man sich erstmal gar nicht um Probleme bei Transitions kümmern muss. Solange es darum geht, Videos zu bearbeiten, die ausschließlich auf PCs gezeigt werden, bleibt die Problematik gänzlich aussen vor und man kann sich sicher sein, dass "Unter-Schwarz" und "Über-Weiß" Bereiche unangetastet bleiben.
Wenn man aber Filme für TV-Ausstrahlung bearbeitet, dann kann man z.B. bei VV einfach einen Broadcast-Filter auf das ganze Projekt anwenden und dabei aber den Level der Beeinflussung kontrollieren und justieren.

Hallo Hannes,

Zitat

> ...Canopus-Video in die Timeline mit einem Übergang so wird der gesamte Film neu berechnet im VVTyp1.

o.k. aber nicht der "Film", sondern lediglich die Audiodaten,
damit sie bei der Vorschau über die Soundkarte ausgegeben werden können.

Eben das ist das Problem, es MUSS alles berechnet werden auch der Videoteil sonst hast du die von Marcos beschriebenen Transisitonssprünge (RGB zu YUV-Probleme).

Umrechnungsfehler

Canopusunterschied

Der für mich wichtigste Faktor des Canopusunterschiedes ist nicht die Geschwindigkeit, sondern der YUV- Raum welcher beim Keying viel bessere Ergebnisse erzielt als der RGB- Raum. Das Problem der RGB basierenden Codecs ist, dass bei der Berechnung der DV-Codec von DV4:2:0 zu DV4:2:2 nach DV4:4:4 konvertiert, danach den Effekt berechnet und wieder in das DV4:2:0 rekodiert.

Anders der Canopus Codec der YUVFarbraum arbeitet und für Keying und Compositing die besseren Eigenschaften bereithält.

YUY-Farbraum

GünterN

Tom, Dein letztes Posting hat mich nun doch etwas verwirrt.

VegasVideo erzeugt beim Capturing auf jeden Fall (bzw. im "Normalfall") ein AVI Typ 1. Denn dort ist eben KEIN zusätzlicher zweiter Audiostream enthalten. Erkennen kann man das, indem man die Datenrate pro Sekunde an einem File, das mit VV gecaptured wurde, errechnet. Es ist nämlich die kleinere der beiden Dateigrößenvarianten. Dies entspricht auch den Herstellerangaben.

Es ist dann auch kein AVI 1.0, sondern ein AVI 2.0, was man leicht daran erkennen kann, dass es unter VegasVideo (und NTFS-Partitionen) eben keine Dateigrößenbeschränkung gibt, die es bei AVI 2.0 gäbe.

Der DV Codec sorgt nun allerdings ja nur für die Komprimierung. Der Codec hat erstmal gar nichts mit dem AVI-Container zu tun. Der gleiche Codec könnte - rein theoretisch - ebenso in einem Quicktime-Container liegen.
Der Codec bestimmt also die Quantisierung, den Render-Farbraum, die Komprimierung, etc.
Der Codec wird dann nochmal eingebettet in einen Container. In diesem Fall ist der Container das AVI. Der Container verändert den Codec nicht mehr, er sorgt lediglich dafür, wie der codierte Video- und Audiostream organisiert wird. So erzeugt dann eben ein AVI Typ 2 noch zusätzlich einen zweiten Audiostream, aber ohne irgendetwas an dem Codec zu verändern.

Sorry, nochmal zu den AVIs, weil ich da jetzt total aus dem Takt bin.

Das einzige, was mir noch sicher scheint, ist die Tatsache, dass VegasVideo von Hause aus AVI 2.0 (also OpenDML-konform) captured und rendert, denn das erkennt man leicht an der nicht vorhandenen Dateigrößenbeschränkung.

Ganz anders sieht es bei der Frage aus, ob es denn nun Typ 1 oder Typ 2 AVIs sind. Finde ich eine Quelle, die den VV Standard als Typ 1 bestätigt, so widerspricht dem die nächste Quelle.

Ich hab zum Rendern unter VV nun auch mal einen Test gemacht und alle möglichen Kombinationen, die die Art des AVI angehen, ausprobiert.
Dabei kann ich dann z.B. überhaupt keinen Unterschied feststellen, ob ich nun im Menü Options/Preferences/Video "strictly conform to AVI-2-specifications" aktiviert habe oder nicht.
Lediglich bei den Rendereinstellungen selbst kann ich dann einen Unterschied auslesen, je nachdem, ob ich dort ein AVI 2.0 gewählt habe oder nicht.
Dieser Unterschied macht sich aber auch nur minimal in der Dateigröße bemerkbar, sprich: Das AVI 2.0 ist letztlich 23,6 kB/sec größer, aber das hat wiederum nichts mit dem Größenunterschied eines AVI-Type 2 zu tun, dessen Datenrate 192 kB/sec größer wäre.
Als Vergleichstest hab ich dann mal ein Capturing mit Premiere gemacht. Auch dort gibt es eine Differenz zu den VV-AVIs, aber gemessen an den "großen" OpenDML-Files von VegasVideo ist auch hier der Unterschied nur 26 kB/sec.
Gleiche Sequenzlänge mit CineStream als Quicktime ergibt einen Unterschied zu dem VV-OpenDML-File von 12 kB/sec.

Da bei Quicktime generell nur ein einziger Audiostream angelegt wird, liegt damit doch die Vermutung nahe, dass es sich bei den VV-AVIs auch tatsächlich um den Type 1 handelt, der ebenfalls nur einen einzigen Audiostream enthält. Aber sicher bin ich mir da nun ganz und gar nicht mehr ...

Ich kann lediglich bestätigen, dass man dann zwar in VegasVideo wählen kann, ob als AVI 1.0 oder AVI 2.0 gerendert werden soll, aber eine Auswahl zwischen Type 1 und Type 2 kann ich nicht finden.

> Und Du glaubst, VV3 würde im YUV-Farbraum arbeiten ???

Tatsache ist, dass VV am Luminanz- und Farbraum gar keine Änderung vornimmt, egal in welchem Wertebereich, solange man eine solche Änderung nicht "befiehlt".
Die Arbeitsweise des VV-Codecs in diesen Luminanz- und Farbräumen ist identisch mit der des Canopus-Codecs.

Hi Tom,

ich wollte Dir nicht widersprechen, sondern lediglich zum Ausdruck bringen, dass ich etwas verwirrt bin, gerade eben, weil Deine Tests für sich sprechen.
Den Herstellerangaben traue ich grundsätzlich eher noch am wenigsten.

Das mit AVI 1.0/AVI 2.0 ist ja jetzt klar.

Was mir aber weiterhin ein Rätsel bleibt ist, warum bei Dir, wenn Du mit VV aufnimmst, dennoch bei der Datei der MainConcept DV Codec 2.0.4 angegeben wird.
Könnte doch sein, dass bei Dir durch irgendeine Voreinstellung dadurch ein anderer AVI-Type erzeugt wird. Nur - welche Voreinstellung sollte das sein?
Auch die Dateigrößenunterschiede, bzw. die Unterschiede in der Datenrate finde ich weiterhin verwirrend. Zwichen MSP und VV gecaptured sind es auch hier nur 23,5 kB/sec Unterschied. Das reicht nicht für einen zweiten Audiostream des Type 2.

Letztlich ist dieser Unterschied ja gar nicht mal so wichtig, aber mich hat das jetzt dermaßen Neugierig gemacht, dass ich keine Ruhe finde, bevor ich es nicht für mich geklärt hab.

Nun verweigert z.B. auch VirtualDub den Import von einer Datei, die mit VV gecaptured wurde, eben weil sie nicht Video-for-Windows kompatibel ist. Eine Eigenschaft des AVI Type 1.
Premiere 6.0 soll ja angeblich auch im Type 1 capturen. Und auch bei einem solchen File verweigert VirtualDub den Import mit der gleichen Fehlermeldung.

> Beim Capturen kann man überhaupt nichts einstellen.

Ich schrieb 'beim Rendern', nicht beim Capturing. Da hast Du absolut recht, da kann ich auch nichts finden.

Tom, bei all der Recherche wird nur eines immer klarer: Dass überall die Begriffe, Bedeutungen und Auswirkung rund um die AVI-Typen und Versionen wild durcheinandergeworfen werden.
Das Einzige, was Hand und Fuß zu haben scheint, ist Dein Praxistest.
Solange, bis mir niemand plausibel das Gegenteil erklären kann, gehe ich davon aus, dass ein AVI Type 2 gecaptured wird.

Für diese falsche Erkennung des Codecs gäbe es vielleicht noch eine andere Erklärung, mal sehen, ob ich dazu was halbwegs Fundiertes finden kann ...

Bis hierhin aber ein Danke für Deine Tests!

Hallo Leute,
es lichtet sich um das Mysterium VV- Codec.

Der von VV3 verwendete Codec ist eine Lizenz des MCDV-Codec vers.4.02.

Bei der Installation von VV3 wird eine für VV3 spezielle Lizenz verwendet welche nur für VV3 zu Verfügung steht.

Der MCDVTyp2 OpenDML- Konform YUV4:2:2

Beim Kauf der echten MCDV-Codec Lizenz werden die Funktionen MCDVTyp2 nonOpenDML YUV4:2:2 zu Verfügung gestellt und auch anderen Programmen zu Verfügung gestellt.

Diese Erfahrung machte ich mit Videofiles die als Typ2 Klassifiziert sind , sich aber weder in Combustion noch mit AE5.5 öffnen ließen. Erst mal folgte Schweigen, danach ein Test mit MP4Pro und MSP6.5. Die mit diesen Programmen erstellten Sequenzen des Typ MSDVTyp2 konnten mit AE und Combustion geöffnet werden. Auch die aus Premiere erzeugten Files des Typ2 wurden von AE verarbeitet.

Nach der Installation des MCDV4.02 und der nonopenDML Aktivierung wurden die Files von VV3 auch von AE und Combustion verkraftet.

FAZIT: VV3 rendert als MCDVTyp2 OpenDML- Konform YUV4:2:2

Mit der MC- Lizenz auch als MCDVTyp2 nonOpenDML YUV4:2:2

GünterN

Hallo Hannes,

die sehr einfache und wahre Antwort auf Deine Frage wäre:

Nein, VegasVideo rendert definitiv NICHT im YUV, sondern im RGB-Farbraum.

Da aber diese Information immer wieder für die wildesten Schlussfolgerungen sorgt, sollte man damit vorsichtig umgehen.

Günter's Aussage ist grundsätzlich vollkommen richtig. Ein Rendering, ganz besonders, wenn es um Veränderungen der Farbinformation geht, ist eher verlustfreier, wenn es bei DV im 4:2:0 YUV-Raum stattfindet, weil man damit unnötige Qualitätsverluste ausschließen kann.
Generell muss bei den Codecs und Filtern, die im RGB-Raum arbeiten, zunächst die DV-4:2:0 Farbauflösung in die RGB 4:4:4-Auflösung umgerechnet werden, was die Gefahr eines Qualitätsverlustes erhöht.

Zurück zu VegasVideo, wo ausschließlich im RGB-Raum gerendert wird.

Der DV-Codec von VV ist dermaßen ausgereift, dass selbst nach sehr vielen Rendergenerationen kein Verlust stattfindet (zumindest kein messbarer), lt. Hersteller gilt das bis in die 50. Generation, selbst nachgewiesen habe ich das bisher bis zur 10. Generation.
Wenn aber nun selbst beim Umrechnen in den RGB-Raum kein messbarer Verlust auftritt, dann hat das auch keine negativen Auswirkungen auf eine Filterqualität, auch nicht auf den Chroma-Keyer!

Zusätzlich zu dem äusserst guten Generationsverhalten des VV-Codecs, der die beste Basis für ein Chroma-Keying bietet, hat man den Codec noch weiter - speziell für das Chroma-Keying - optimiert. Im Großen und Ganzen schweigt man sich über die Methode aus.
Grund für weniger gute Ergebnisse beim Chroma-Keying ist ja in erster Linie nicht die Wandlung nach RGB, sondern die Tatsache, dass bei DV-YUV 2 Anteile der Farbinformation fehlen. Ob nun in RGB oder in YUV gerendert wird, ändert nichts an dieser Tatsache.
Um dieser Tatsache entgegenzutreten arbeitet man in VegasVideo beim Chroma-Keying mit einem bestimmten, nicht näher definierten Interpolationsverfahren, mit dem die fehlende Farbinformation des ursprünglichen 4:2:0-Signals schätzend ergänzt werden soll.
Das Ergebnis soll - angeblich - deutlich besser sein als bei normalen Verfahren. Ich denke, Canopus benutzt genau das gleiche Verfahren.

Ich persönlich kann dazu nur sagen, dass ich selbst mit CineStream, was diese Methode für Keying nicht benutzt, beim Blue-Boxing Ergebnisse erzielt habe, die allererste Sahne waren.

Ich glaube, dass man den Schwerpunkt des Chroma-Keyings mit Diskussionen um den besten Software-Keyer etwas arg verlagert. Ich finde es viel wichtiger, beim Dreh für gute Ausleuchtung zu sorgen.
Wenn bei der Ausleuchtung alles stimmt, dann wage ich mal zu behaupten, dass der Keyer nur noch einen bescheidenen Beitrag zur Qualitätserhaltung leisten kann. Umgekehrt kann auch der beste Keyer kaum eine schlechte Ausleuchtung retten.

Günter, woher hast Du denn die Info, dass der VV-Codec "nur" eine Lizensierung des MC-Codecs ist?
Es ist ja bekannt, dass in VV3 der MPEG-Codec von MC lizensiert wurde, dass das aber für den DV-Codec gilt, ist mir neu.

Hallo Marco,

Zitat

Nein, VegasVideo rendert definitiv NICHT im YUV, sondern im RGB-Farbraum

ich glaube es wird Zeit SonicFoundry direkt zu bemühen.

Uns rauchen jetzt die Köpfe und unser CombustionGuru wirftgerade ein Aspirin ein und legt sich einen Eisbeutel auf den Kopf da das Hammerweitwerfen in der Gedächtnishalle lebensbedrohende Ausmaße erreicht hat.

Eigenartig ist, Combustion2 erkennt die Quelldatei als Typ2 YUV4:2:2 ?!?!?!?

Lassen wir uns überraschen was noch alles an die Oberfläche geschwemmt wird.

Wie es aussieht glauben wir etwas zu Wissen obwohl wir alle überhaupt nichts Wissen.

GünterN

> ich glaube es wird Zeit SonicFoundry direkt zu bemühen.

Die Info, dass VV ausschließlich im RGB-Raum rendert, kommt von SonicFoundry.