These zu VV- und MC-Codec

Nach alldem, was verschiedene Leute hier im Forum unter "OHCI und VV-Demo" an Infos zum Thema AVI, Codecs etc. beigetragen haben, wage ich jetzt mal eine eigene These:

Vegas Video 3 captured und rendert unter normalen Bedingungen zu einem Typ 2 AVI 2.0.
Beim Capturing wird kein Codec angewendet, beim Rendering - falls nicht definitiv ein anderer Codec angegeben wurde - der hauseigene Codec von SonicFoundry, der erst ab der Version 3 in Vegas Video implementiert wurde.

Sowohl beim Capturing als auch beim Rendering zu einer AVI-Datei wird immer ein Header erzeugt, der Programmen u.a. mitteilen soll, welchem Hersteller das Capturing oder das Rendering zu verdanken ist.
Der Header steht vor dem Video, also kann der Header ausgelesen werden und somit kann das Programm erste Informationen über das Video erhalten, ohne dass das Programm erst das Video decodieren müsste.

Gleichzeitig heißt das aber auch, dass man dem Header eine Information zum Video geben kann, die nicht ganz korrekt ist. Denn wenn z.B. ein Video mit einem DV-nativ System eingelesen wird, dann ist das Video noch immer mit dem Codec komprimiert, den die DV-Kamera (oder der DV-Recorder) verwendet hat. Trotzdem wird nach einem Capturing oft der Codec angezeigt, den der Hersteller der Capture-Software mitliefert.
Grund dafür ist, dass beim Capturing ein Header von der Capturing-Software erzeugt wird und diesem Header dann auch gleich eine Info zum Hersteller der Capture-Software mitgegeben wird.
Das komprimierte Video an sich bleibt dabei aber unberührt.

Manche Codecs schreiben nun bei ihrer Installation Namen und Infos in die Windows-Systemeinstellungen (unter "Videocodecs"), andere wiederum nicht.

Manche Programme ausserhalb der Capture- oder Schnittsoftware brauchen nun aber zwingend Informationen aus den Windows-Systemeinstellungen, um den Header eines Videos lesen zu können. Hat ein Codec in die Windows-Systemeinstellungen keine Infos reingeschrieben, dann bleibt das gesamte Video für jene Programme unlesbar.

Es scheint einige Codecs zu geben, die den gleichen Header schreiben, bzw. auch einige Capture-Tools, die ebensolches tun.
So scheinen VegasVideo und MainConcept für das Capturing und Rendering den gleichen AVI-Header zu schreiben, aber dennoch wenden sie unterschiedliche Codecs an (und anscheinend gilt gleiches für Premiere).

Der Codec von VegasVideo wird definitiv nicht in die Windows-Systemeinstellungen eingetragen. Wohl aber der Codec von MainConcept.

Wenn sich nun in den Windows-Systemeinstellungen gar keine Information zu bestimmten Headern befindet, dann können Programme, die Header-Informationen eines Videos allein in den Systemeinstellungen suchen, ein solches Video gar nicht interpretieren.

Benutzen zwei Programme, bzw. zwei Codecs den gleichen Header, aber nur der eine Codec ist mit dem Header auch in den Systemeinstellungen eingetragen, dann werden die Programme, die die Infos ausschließlich in den Systemeinstellungen suchen, immer nur den einen Codec anzeigen, der eben in den Systemeinstellungen zu dem Header eingetragen ist, selbst dann, wenn der Header eigentlich zu einem anderen Video gehört, dessen Codec aber eben NICHT in den Systemeinstellungen eingetragen ist.

Also vermute ich, dass der MainConcept-Codec den gleichen Header schreibt wie der Vegas Video-Codec, aber der MC-Codec wird im Gegensatz zum VV-Codec in den Windows-Systemeinstellungen eingetragen.

Sobald also der MC-Codec im System vorhanden ist, kann der Header, der auch beim VV-Codec vorhanden ist, von jedem Programm gelesen werden, das vorher mit dem Lesen des VV-Video-Headers Probleme hatte.
Zwar wird nun durch den Header die Information immer zu dem MC-Codec geleitet, da allein dieser in den Systemeinstellungen vorhanden ist, aber der Header ist dabei nur zuständig, erste allgemeine Informationen auszugeben.
So liest man dann als Codec eines Clips, der mit VV-Capturing eingelesen wurde, bei vielen Programmen, es wäre ein MainConcept Codec.

Stellt sich noch die Frage, warum denn ein DV-AVI korrekt decodiert werden kann, obwohl der Header zu einem falschen Codec führt:
Ich denke, es liegt daran, dass bei DV das Decoding standardisiert ist (ganz im Gegensatz zum Encoding). Für das Decoding wird also keine weitere Information gebraucht, soweit im Header nur die Strukturdaten (z.B. für die Cliplänge, AVI 1.0/AVI 2.0 etc.) korrekt angegeben sind.

Alles nur eine These, aber klingt für mich einigermaßen logisch

et voilà ...

... ich hab jetzt nochmal einen kleinen Clip einmal mit VV-Codec und einmal mit MC-Codec gerendert und dann beide Clips jeweils mit einem Editor geöffnet.

Die beiden ersten beschriebenen Zeilen sind ABSOLUT IDENTISCH.

Die nächsten beiden beschriebenen Zeilen sind nur noch ähnlich (leider ist das ja nur ein Zeichencode, den ich nicht interpretieren kann).

Es folgen wieder sehr viele (hunderte), gleiche Leerzeilen und hin und wieder eine identische Zeile, bis irgendwann tausende von Zeilen kommen, die allesamt verschieden sind.

Ich schätze, dass somit die ersten paar hundert Zeilen zum Header gehören, alles weitere dann das eigentliche Video ist.

Ich muss mal einen Editor suchen, der mir das Vergleichen etwas einfacher macht ...

Hab den eben erwähnten Versuch nun nochmal etwas genauer durchgeführt mit dem Hex-Editor von VirtualDub. Da wird es sehr deutlich.

Mit Ausnahme von 2 Zeilen sind dort die Datei-Header des Clips - mehrere hundert Zeilen - von VegasVideo und des Clips von Mainconcept absolut identisch.

Dann folgen tausende von (Videokompressions-)Daten, die allesamt unterschiedliche Zeilenwerte haben (nach mehreren hundert unterschiedlichen Zeilen folgen hin und wieder 4 identischen Zeilen mit lauter Null-Werten).

Zum Schluss kommen dann nochmal etwa 55 Zeilen, die bei beiden Versionen wieder exakt gleich sind.

Wenn man nun genau wüßte, welche Zeilen im Header einem Programm den Weg zum Namen des Codecs weisen, dann könnte man das leicht umleiten und könnte damit endgültige Klarheit durch einen Gegentest schaffen.
Das werde ich aber wohl nicht mehr tun können. Ich finde, dieses Ergebnis stützt auch so schon die Vermutung, dass allein der Header der MC- und VV-Videos gleich ist und somit zu Fehlangaben führt.

Jetzt hab ich nochmal den MC-Codec vom System gelöscht und stattdessen den Panasonic-DV-Codec installiert. Nun werden alle AVIs, die mit VegasVideo gecaptured oder gerendert wurden, als Panasonic-DV angezeigt und können ebenfalls von allen Anwendungen geöffnet werden.
Sogar das mit dem MainConcept-Codec gerenderte AVI wird nun als Panasonic-DV angezeigt.

Ich denke, das macht es nun endgültig klar. Es hat nichts damit zu tun, dass der MC- und der VV-Codec gleich wären (wie sehr sie sich unterscheiden zeigt ein RGB-kritischer Rendertest).

Welcher Codec in einem AVI ausgewiesen wird hängt auf jeden Fall davon ab, welcher DV-Codec in den Systemeinstellungen eingebunden ist und vielleicht auch von den Header-Informationen der AVIs.
Diese Codec-Angabe eines AVI ist in vielen Fällen einfach falsch. Zumindest besagt sie nichts darüber, mit welchem Codec das AVI komprimiert wurde, sondern lediglich, zu welchem Video-for-Windows Codec das AVI innerhalb der Dekompression kompatibel ist.

Puuuhhh ...

Tom, ganz Deiner Meinung!
Ich finde es nur gut, dass wir relativ schnell auf dieses Problem gestoßen sind und es auch schnell lösen konnten. Denn wenn ich unter Zeitdruck auf einmal vor dem Rätsel gestanden hätte, dass ich mit keinem Programm ein VegasVideo-Clip hätte öffnen können, dann hätte es mich wahrscheinlich über Wochen sämtliche Nerven gekostet, hinter das Geheimnis zu kommen.
Ist schon cool wie schnell man in so einem Forum Rätsel lösen kann

Eben bekam ich zu diesem Thema eine Antwort des MainConcept-Supports im US-Forum von VegasVideo. Ich zitiere die hier mal ohne Übersetzung:

"Some codecs use the same header, which is why if a certain codec is
installed it may appear to be another codec. However, that doesn't actually
mean the indicated codec is actually being used."

Also, wie ich es damals unter manche Mathe-Arbeiten schreiben musste:

Quod erat demonstrantum.

Hi Ihr,

dies scheint sich in der grundsätzlichen Kernaussage mit einer Erscheinung zu decken, die ich bei meinen ersten Versuchen mit dem vor ca. einem halben (oder war' schon dreiviertel) Jahr von mir entdeckten Panasonic Codec gemacht habe. Die Identifikation eines mittels VfW-Codecs codierten Clips als Panasonic oder MainConcept, richtete sich immer nach dem gerade im Windows System (per System.ini) initialisierten Codec!

Im Klartext: Wurde ein Clip mit dem Panasonic codiert, erschien er in den 'Properties' von Premiere, wie auch in den 'Infos' von MSP als MainConcept-Clip - wenn dieser gerade aktiviert war! War der Panasonic aktiv, wurde der Clip auch 'richtig' als Panasonic identfiziert. Und vice versa:
Ein original MainConcept codierter Clip wurde problemlos in AP6 und MSP als 'Panasonic' erkannt, wenn dieser eingebunden war.

Zumindest vom Header her ist VfW wohl gleich VfW. Zur Idenfikation, mit welchem der beiden Codecs der Clip denn nun wirklich codiert wurde, ist mir noch kein sicheres Erkennungsmerkmal bekannt geworden.

Muß man sich wohl aufschreiben und 'n Zettel an den Clip kleben

ikarus

Solange ein Codec genau das macht was er soll und wenn er es zudem noch sehr gut macht, ist ja alles bestens.
Nur wenn dann heftige Probleme auftauchen wie bei Uwe, dann würde ich mir schon wünschen, gleich irgendwie erkennen zu können, ob vielleicht ein ganz bestimmter Codec der Übeltäter ist.
Das mit dem Zettel am Clip sollte man den Entwicklern mal vorhalten ...

Danke für den Erfahrungsabgleich!

Ich hatte ja einen ähnlichen Vergleichstest hier vor kurzem schon mal beschrieben und das selbst erstellte Testbild hier auch zum Download angeboten (Thema OHCI und VV-Demo, Positing vom 27.07. 3:16 Uhr).

Der Hammer dabei ist, das z.B. der MC- und auch der Microsoft-Codec schon nach dem ERSTEN!!! Rendering dabei (bei meinem Testbild) das komplette Luminanzsignal staucht, während beim VV-Codec auch nach der 10. Rendergeneration alles unverändert bleibt.

Peter, vielen Dank für die Infos und die weiterführenden Links. Interessantes Thema!

Hallo Hannes,

Die oben im Thread genannten Begriffe sind Dir wahrscheinlich deswegen etwas fremd, weil sie aus dem VegasVideo-Wortschatz stammen. Dort tauchen sie in diversen Menüs und Fenstern auf.

>> "render as.."

Das ist bei VegasVideo eine Menü-Option zum Export der Timeline (oder eines markierten Teils der Timeline) vorrangig zu einem anderen Format oder Codec. Das kann z.B. RealMedia, Quicktime, WMV oder andere sein.
Ebenso kann man damit all die Files, die in der Timeline liegen, zu einem neuen eigenständigen File zusammenfassen. Das wäre ja z.B. dann der normale Vorgang, wenn man ein Projekt beendet hat, es dann aber noch mit anderen Programmen weiterbearbeiten möchte. Dann würde man diesen Export mit "Render as ..." machen, ohne unbedingt einen Fremdcodec anzuwenden.

Wenn man nun über "Render as ..." einen Export macht, zwingt man das System dazu, das Material der Timeline erst zu dekomprimieren und dann erneut zu komprimeren. Wählt man also bei "Render as ..." nicht einen VV-fremden Codec zum Recomprimieren aus (z.B. für Internet-Videos), dann wird dabei wieder der VV-eigene Codec angewendet.
Wenn man also mit der Option "Render as ..." die Timeline als neue, eigenständige Datei exportiert, dann wieder importiert und dann den selben Vorgang mehrmals wiederholt, dann kann man leicht diese auch erwähnten Rendergenerationen herstellen, bei denen viele Codecs schon ab der fünften Generation - manche aber schon nach der ersten Generation - deutliche Qualitätseinbrüche zeigen.

Äquivalent zu der Menü-Option "Render as ..." gibt es dann in VegasVideo auch die Option "Render to new track".
Da passiert im Grunde genommen genau das gleiche wie bei "Render as ...", nur dass die Timeline nicht nur gerendert exportiert wird, sondern die neu erstellte Datei wird dann auch AUTOMATISCH wieder importiert und synchron in eine neue Spur in der Timeline abgelegt.
Das dient dann vorrangig dazu, schonmal einen Teil der Timeline, auf dem eventuell viele komplexe Effekte liegen, als eine einzige fertige Datei im Projekt weiterzuverwenden.

> und dem Template "PAL DV"

Dieses "Template PAL-DV" ist eine fertige Konfiguration für eine Projekteinstellung oder eine Rendereinstellung, in der alle wichtigen Parameter für das Projekt oder das Rendering als fertig abgespeichertes Paket aufgerufen werden.
Wenn man ein ganz bestimmtes Rendering oft wiederholen muss/möchte, bei dem man viele Parameter nach eigenen Ansprüchen verändern musste, z.B. für die Erstellung eines Web-Videos, dann kann man sich diese Einstellung als eigenes Template abspeichern und später muss man dann nur noch dieses Template aufrufen, um somit automatisch die gewünschten Parameter zu erhalten.
Als Standard sind diverse Einstellungen schon als Template direkt abrufbar, so z.B PAL-DV, NTSC-DV, PAL-16:9 etc.

> und woher kommt der Can-Cod?

Wie Tom schon erwähnte - Der Canopus-Codec ist gar nicht auf seinem System. Das war nur ein Missverständnis.
Meines Wissens ist der Canopus-Codec nicht als reiner Software-Codec erhältlich.
Es ging nur um die Erwähnung, dass ja auch der Canopus-Codec in Bezug auf Renderqualität einen hervorragenden Ruf hat.
Allerdings muss man dabei auch erwähnen, dass es bei der Prüfung des Canopus-Codecs (zumindest bei dem, was ich bisher darüber gelesen hab), immer nur um die Erhaltung des gesamten Luminanzraumes bei Videosignalen mit "Unter-Schwarz" und "Über-Weiß" ging.
Ob denn beim Canopus-Codec auch ansonsten ein kritisches Videosignal über derart viele Rendergenerationen gar keinen feststellbaren Verlust aufweist, das bleibt für mich noch zu beweisen, aber ich selbst kann es nicht prüfen, da ich auch kein Canopus-System und damit auch keine Canopus-Codec habe.

> Hast Du eine Raptor etc. auf die VV3 zugreifen kann?

Die Raptor-Karte kann nicht auf VV zugreifen und VV nicht auf die Raptor - meines Wissens. Oder? VegasVideo braucht eine OHCI-Karte.
Man kann aber eine Raptor und gleichzeitig eine OHCI-Karte für VV verwenden.

> Wieso sollen VV3 und Can sich verstehen??

Warum sollten sie es denn nicht?
Gut, man kann nicht unbedingt davon ausgehen, dass zwei verschiedene Schnittsysteme auf gleicher Hardware unbedingt problemlos nebeneinander existieren können, aber oft geht das.
VV und CineStream geht z.B. auch ohne Probleme.
Uwe hat ja gerade VegasVideo und RaptorEdit auf einem System laufen. Bei ihm funktioniert es jetzt - fast - perfekt. Nur RaptorEdit macht auf einmal im Vorschaufenster Zicken. Aber dazu müsste er selbst selbst berichten.

>>> Wenn man nun über "Render as ..." einen Export macht,
>>> zwingt man das System dazu,
>>> das Material der Timeline erst zu dekomprimieren und
>>> dann erneut zu komprimieren.

> aber doch wohl nicht das Material, welches nicht verändert wurde !!
> (Smart-Rendering)

Doch, bei dieser Funktion "Render as ..." wird alles de- und rekomprimiert. Es ist ja - wie erwähnt - eigentlich zur Umwandlung in ein anderes Format gedacht.
Als Smart-Rendering gibt es in VV eine andere Funktion, die sich "Prerendering" nennt. Über diese Funktion werden dann nur Teile gerendert, die entweder nicht dem VV-Codec entsprechen, oder die mit Filtern verändert wurden.

>>> ..den selben Vorgang mehrmals wiederholt, dann kann man leicht diese
>>> auch erwähnten Rendergenerationen herstellen

> o.k., aber wer macht das schon ??

Hehe, normalerweise natürlich niemand. Es ging uns ja nur darum, einen Test durchzuführen. Zu Rendergenerationen in einer x-ten Generation kommt es in der Praxis schon hin und wieder. Dann beinhaltet aber jede Rendergeneration auch die Anwendung eines oder mehrerer Filters oder FX.
Man kann aber eine Qualitätsüberprüfung schlecht durchführen, wenn man das Bildmaterial mit einem Filter verändert, deswegen muss man zu solch einem Test entweder einen Filter anwenden, der aber das Bild gar nicht verändert (eben mit den entsprechenden Null-Werten für die Einstellung), nur um dem System das Rendern aufzuzwingen, oder aber man benutzt den Export.

>>> Meines Wissens ist der Canopus-Codec nicht als
>>> reiner Software-Codec erhältlich.

> Doch, mit dem Boosterpack.

Gut zu wissen!

>>> Wann wird unser Material denn schon mal gesendet ?? (;-)))))

Ich denke, das Material von einigen hier doch sehr oft ...

> Dadurch daß Konsumerkameras auch kein Normsignal liefern,
> sondern bei Überstrahlungen rücksichtslos Reinweis benutzen,
> liefert der Can-Cod hier bessere Ergebnisse.

Bessere Ergebnisse im Vergleich zu was? Als der Panasonic-, MS-, oder MC-Codec. Das ist richtig.

> weil Canopus grundsätzlich sein eigenes Süppchen kocht!

Das ist wohl war. Es hat nicht gerade den Anschein, als wäre Canopus sehr bemüht oder erfreut darum, andere Schnittsoftware auf ihrem System laufen zu lassen. Aber mit VegasVideo scheint das zu funktionieren. Es gibt ja sogar ein Canopus-Bundle, das mit VegasVideo ausgeliefert wird (was nicht wirklich heißen muss, dass es funktioniert ... )
Uwes Konstellation mit der Raptor und VV funktioniert jetzt übrigens wohl auch ohne Probleme.