These zu VV- und MC-Codec

    Hi,


    >>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.<<


    Da bin ich mir inzwischen nicht mehr so sicher.
    Ergänzend zu meiner erwähnten Testreihe habe ich nun mal in VegasVideo das 10-malige Rendern mit dem MainConcept Codec 2.04 durchgeführt.


    Ihr erinnert euch: dieser Test unter MediaStudio ergab auch mit diesem Codec eine Qualitätseinbuße.
    In VV war dieser Qualitätsverlust nun nicht mehr vorhanden.
    Grübel, grübel.


    Also erzwingt die Funktion "Render as.." wohl doch nicht das erneute De- und Rekomprimieren.


    Und nun der Beweis:
    Der gleiche Test mit "Render to New Track" zeigte dann endlich auch mit dem MC-Codec den Qualitätsverlust.


    Deshalb musste nun eine weiter Testreihe mit dem VV-Codec und dem Befehl "Render to New Track" durchgeführt werden.


    Hier zeigte sich allerdings beim 10. Neurendern auch wirklich kein Qualitätsverlust.


    Eine Überraschung gab es noch als Beigabe:
    während in MediaStudio das 10-malige Rendern mit dem MC-Codec 2.04 eine generelle Abdunklung des Bildes ergab, führte das 10-malige Rendern in VV mit dem expressis verbis ausgewählten MC-Codec 2.04 zu einer Aufhellung des gesamten Grauverlaufs.


    Da soll noch einer durchblicken.


    Mit testenden Grüßen
    Tom

    Hoppla, interessante Ergebnisse!


    Ich hatte damals meine Rendertests zum Qualitätsvergleich der Codecs ausschließlich unter Anwendung eines Filters gemacht.
    Jetzt - bei unseren Tests nach dem Motto "welches Rendering in VV hat welche Funktion" - hatte ich mich einfach darauf verlassen, dass bei "Render as ..." immer eine komplette Recompression stattfindet.
    Was ich als Bestätigung betrachtet hatte, war die Zeit, die "Render as ..." benötigt, um einen unveränderten Clip, der im VV-Codec vorliegt wieder im gleichen Format zu exportieren (v.a. im Vergleich zum Prerendering, wo das immer nur wenige Sekunden dauert).
    Das wäre ja nun widerlegt.


    Einerseits erfreulich, dass dem nicht so ist, andrerseits: Was macht VV denn in all der Zeit, in der es bei "Render as ..." NICHT rendert ...? ;)
    Vielleicht ist es ja die Umwandlung des AVI, also die Aneinanderreihung von Clips aus verschiedenen Ursprungsorten.

    Einmal editiert, zuletzt von Avalon ()

    Hi Marco,


    schön, dass man Dein Konterfei nun auch betrachten kann.
    So wird das Forum noch persönlicher.


    Ich hatte mich mal in einem Posting auch über die Rendergeschwindigkeiten geäußert.
    Mir war aufgefallen, das das "Prerendering" länger als das "Render as .." dauert.


    Ist aber jetzt auch kongruent zu meinem Test.


    Excurs:
    Wenn ich in MSP mehrere Clips auf die Timeline lege und keinerlei Transitionen oder Filter anwende, also "nackt", dauert das Erstellen eines neuen AVI's auch seine Zeit.
    Auch beim sog. "Smart Check & Render", mit dem man alle Clips auf das gleiche Format umwandeln kann, ist der Fortschrittsbalken in Aktion.


    Wahrscheinlich werden Informationen aus dem Ursprungsclip auf irgendeine Art eingelesen, um den neuen Clip erstellen zu können.


    Aber das kann ich nicht belegen.


    Gruß
    Tom

    Hallo Leute,


    RGB4:2:0 ist die Antwort von SonicFoundry aber ein besonderer.!!!-->


    Dualprozessorfähig und Fehlfarbeninterpolierend.


    HA jetzt wird mir auch die Qualität der Keyers klar.



    @Tom


    Bei einem reinen Cliprendern ist kein Rendern notwendig.


    bei einer 18 min Sequence dauert das Neuberechnen(Kopieren) genausolange wie das Kopieren mittels Explorer in ein anderes Verzeichnis der gleichen Partition(~2sec länger)


    GünterN :bigok:

    Hi Tom,


    >Mir war aufgefallen, das das "Prerendering" länger als das "Render as .." dauert.


    Ja, das kann ich für bestimmte Konstellationen mit meinen Tests durchaus bestätigen. Aber nicht für alle.
    Wenn es z.B. wirklich darum geht, einen Clip, der mit VV gecaptured wurde, unverändert zu "rendern", dann dauert dieser Vorgang - selbst wenn der Clip viele Minuten lang ist - nur wenige Sekunden, wenn man es über Prerendering macht, aber mehrere Minuten, wenn man es über "Render as ..." macht.


    Konkretes Beispiel:


    Ein Clip von 10 Minuten Länge braucht bei mir über Prerendering 3 bis 4 Sekunden zur Berechnung.
    Gleicher Clip über "Render as ..." braucht 6 Minuten.
    Auch wenn ich diesen einzelnen Clips in viele kleinere Clips aufteile, ändert es nichts an der Berechnungszeit für das Prerendering.


    Mit jedem Clip, auf den ich dann einen Filter anwende, steigt die Zeit für das Prerendering. Wenn ich nur wenige Clips mit Filtern versehe, dann bleibt die Zeit für das Prerendering erheblich kürzer, als die Zeit für "Render as ...".
    Wenn nun aber z.B. ALLE Clips mit einem Filter versehen sind, dann dauert das Prerendering tatsächlich länger als der Vorgang "Render as ...".



    Hallo Günter,


    > RGB4:2:0 ist die Antwort von SonicFoundry aber ein besonderer.


    Ist das nicht ein Widerspruch. RGB müsste doch immer 4:4:4 sein, oder?
    4:2:0 als YUV. VV arbeitet bei Filtern und Effekten aber im RGB-Raum. Auch der Keyer arbeitet - laut Aussage des SonicFoundry-Supports - immer im RGB-Raum. Allein dadurch, dass der Codec aber subjektiv verlustfrei arbeitet, ist das hier kein Nachteil zum YUV-Rendering im 4:2:0-Raum.
    Durch die Interpolation wird beim Keying der Vorteil noch weiter ausgebaut.
    Meinst Du den SonicFoundry-DV-Codec, der - unabhängig von Filterarbeit - 4:2:0 DV-Signale erzeugt?


    > bei einer 18 min Sequence dauert das Neuberechnen(Kopieren)
    > genausolange wie das Kopieren


    Hey, das ist es! VV muss den Timeline-Inhalt ja auch kopieren. Klar, für mehrere GB dauert das dann auch ein paar Minuten. Danke für den Hinweis, da hätte man lange rätseln können ...

    Einmal editiert, zuletzt von Avalon ()

    Hallo Marco,

    Zitat

    Ist das nicht ein Widerspruch. RGB müsste doch immer 4:4:4 sein, oder?
    4:2:0 als YUV. VV arbeitet bei Filtern und Effekten aber im RGB-Raum. Auch der Keyer arbeitet - laut Aussage des SonicFoundry-Supports - immer im RGB-Raum. Allein dadurch, dass der Codec aber subjektiv verlustfrei arbeitet, ist das hier kein Nachteil zum YUV-Rendering im 4:2:0-Raum.
    Durch die Interpolation wird beim Keying der Vorteil noch weiter ausgebaut.
    Meinst Du den SonicFoundry-DV-Codec, der - unabhängig von Filterarbeit - 4:2:0 DV-Signale erzeugt?


    Dem werden wir uns noch genauer widmen müssen.


    Zur Renderzeit sei noch eines angemerkt--->>


    Die Quelldateien MÜSSEN auf einer anderen physikalischen Partition liegen.


    Beobachte die Kopierzeit beim Transfer von Partition nach Partition auf gleicher HD und von HD zu HD.


    Da werden die 18~33Mb/sec meiner Maxtorplatte mit 4MbCache zur Lachnummer. die 4 Gigs sollten in ~2,7Min kopiert sein aber so ist es nicht..... Fortsetzung folgt.


    GünterN :richter:

    > Beobachte die Kopierzeit beim Transfer von Partition nach Partition auf
    > gleicher HD und von HD zu HD.


    Hab's gerade mal getestet. Tatsächlich - Wenn ich zum Rendern als Ziel die gleiche HD benutze wie die des Originals, dann verlängert sich die Renderzeit um etwa 20 Prozent.
    Zum Glück hab ich 8 Partitionen zur Auswahl ... ;)

    Einmal editiert, zuletzt von Avalon ()

    Hi,


    >>Wenn ich zum Rendern als Ziel die gleiche HD benutze wie die des Originals, dann verlängert sich die Renderzeit um etwa 20 Prozent.<<


    Das ist doch auch logisch, schließlich müssen die Schreib-/Leseköpfe mehr arbeiten, wenn von der gleichen HD gelesen und wieder darauf geschrieben werden muss.


    Wird von einer HD gelesen und auf eine andere HD geschrieben, muss der Vorgang zwangsläufig schneller gehen.


    Aber derartige Finessen hatte ich bei meinen Testreihen nicht auch noch einbezogen.


    Gruß
    Tom

    @all:


    Theoretisch sollte man noch bessere Werte erreichen wenn die Platten auch an unterschiedlichen Controllern hängen.


    Die Begründung:
    Jeder Positioniervorgang wird durch einen Seek-Befehl (Suchbefehl) eingeleitet, mit dem der Kopf Zylinder und Sektor auf der Platte sucht. Den Abschluß der Suche meldet die Platte an den Kontroller und dieser wiederum per Interrupt an die CPU damit diese den DMA einleiten kann. Da pro Kontroller nur ein Interrupt (14 bzw. 15) zur Verfügung steht, kann auch nur ein Seek-Befehl zur Zeit pro Kontroller abgerbeitet werden.


    Hängen die Platten an unterschiedlichen Kontrollern, können zwei Seeks zur Zeit abgearbeitet werden (einer auf IRQ 14, einer auf IRQ 15), was den Vorteil hat daß beide Platten gleichzeitig suchen und positionieren können. Die langsamere Datenrate des zweiten Kontrollers (meist nur UDMA33 oder 66) fällt nicht ins Gewicht weil sie in jedem Fall das Mehrfache der notwendigen Video-Dantenrate (3,7 MB/s) beträgt.


    So weit die Theorie. Tatsächlich sind, durch die Bauart der Gehäuse bedingt, meist beide Platten an einem Kontroller angeschlossen und CDROM bzw. Brenner und DVD am anderen Kontroller. Deshalb auch oft die Warnung der Brennprogramme (z.B. Nero) bei Kopien nicht mit voller Geschwindigkeit zu brennen. Im günstigsten Fall kann bei richtigem Anschluß und richtiger Verteilung der Daten (z.B. Clips und temporäre Files auf Device 3 und gerendertes Projekt nach Device 0 schreiben) die Zeit für die Fertigstellung des gerenderten Film halbiert werden.


    Tröstet euch: Auch meine Devices sind "falsch" angeschlossen um den Kabelverhau im Gehäuse zu vermeiden.


    Ein Tip für die, die es trotzdem versuchen wollen: Dreht die Kontrollerkabel um, also mit dem kurzen Stück vom Kontroller zur ersten Platte und dann mit dem langen Stück von der Platte zur CD-ROM. Und wichtig: Immer alle Laufwerke auf "CS" jumpern, niemals auf "Master/Slave" denn damit gibt´s kein UDMA 100/133.


    Viele transferoptimierte Grüße
    vom Peter

    Ich wünsche mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann und die Weisheit, das eine vom andern zu unterscheiden.

    Hi,


    CS besagt, der Puter guckt was da anner Strippe hängt und sacht sich selber: det is een' Dampfmaschin, nee, war ein anderer Film, also sacht sich, die eene Platte mach ich zum Master, die andere zum Sklaven, oh wie sexistisch.


    Kurz gesagt: brauchst Dich dann nicht weiter um Master oder Slave bekümmern.


    Gruß
    Tom