Geschwndigkeit von "fast recompress" bei VirtualDubMod

  • Hi,

    ich habe einen Film analog gecaptured und ein AviSynth-Script erstellt. So weit, so gut. Nur würde es ca. 40 Stunden brauchen, dieses Script/Film mittels CCE (3-Pass) zu encoden. Ein wenig lang, finde ich.

    Um diese Zeit zu verkürzen, kann man ja (wenn ich mich nicht irre) dieses Script in VirtualDubMod laden, mittels Fast recompress wieder als HuffYuv abspeichern und dieses File dann in den CCE laden. Nur dümpelt VirtualDubMod bei Fast recompress mit 4 fps dahin, d.h. das würde auch ca. 9-10 Stunden dauern. Ist das normal? Full processing mode hat nämlich genau die gleiche Geschwindigkeit.

    Danke im voraus!

    Quapla'
    Gothmog

    Gegen jeden, der es unternimmt, diese Ordnung zu beseitigen, haben alle Deutschen das Recht zum Widerstand, wenn andere Abhilfe nicht möglich ist. (Art. 20(4) GG)[SIZE=-1]
    [/SIZE]

  • Fast recompress übergibt das Input Material direkt dem Codec und verhindert die Zwangskonvertierung nach RGB die im Full Processing Mode vorgenommen wird wenn das Material nicht schon als RGB vorliegt.

    Wenn Dein Script was Du VDM fütterst also schon RGB ausgibt oder einfach so komplex ist, dass die Umwandlung in den RGB Farbraum verschwindent viel Zeit einnimmt wird sich an der Geschwindigkeit nichts tun.

    Falls der Encoder den man eh alles was nicht RGB ist nach RGB umwandelt bringt Fast Recompress natürlich auch nichts. (es sei den die internen xy -> RGB Routinen des Codecs sind nicht wesentlich anders in der Geschwindigkeit als die von VDM)

    Soweit ich mich entsinne verarbeitet HuffYUV nur RGB, d.h. das Material wird eh nach RGB umgewandelt. Es ist also nur die Frage nimmt VDM oder der Codec die Umwandlung vor.

    Cu Selur

  • Soweit ich mich entsinne verarbeitet HuffYUV nur RGB, d.h. das Material wird eh nach RGB umgewandelt. Es ist also nur die Frage nimmt VDM oder der Codec die Umwandlung vor.

    Nein!

    Wie der Name schon sagt, arbeitet HuffYUV sehr wohl auch mit YUV-Video (das Original mit YUY2, in ffdshow zusätzlich auch mit YV12). Je nach Einstellung wird dabei RGB entweder als RGB komprimiert, oder vorher noch zu YUV konvertiert.
    __

    Die alte Generation von TMPGEnc 2.x hat grundsätzlich immer nach RGB konvertiert, das liegt am VFAPI-System als Kern seiner Videoverarbeitung. Der CCE jedoch nimmt gern YUY2 (nur YV12 mag er nicht, weil die Programmierer glauben, dass der Anwender keine Ahnung vom Unterschied zwischen progressiv und interlaced YV12 hat).

    "Full Processing" gibt immer RGB an den Codec, weil man da eventuell noch die VirtualDub-Filter verwenden könnte, die auch bloß im RGB-Modus arbeiten. "Fast Recompress" gibt das an den Codec, was hineinkommt, und erlaubt keine VirtualDub-Filter.
    __

    Wenn du einmal nach HuffYUV konvertierst, dann wird das AviSynth-Skript nur einmal angewendet (das Ausgeben des HuffYUV-AVI dauert dann je nach Komplexität der Filter). Danach wird der CCE das Zwischenmaterial encodieren, ohne noch drei Mal die AviSynth-Filter zu benötigen. Letztlich wird das schon schneller sein, wenn das Skript sehr komplex ist.

  • Hm, dann muss ich wohl etwas Zeit mitbringen.

    Gecaptured habe ich in YUY2, musste aber im Script eine Konvertierung nach YV12 einbauen (und wieder zurück), wegen MCNR_simple2 und LimitedSharpen.
    Ich hänge es mal an.


    Sooo komplex ist das eigentlich nicht, oder?

    Quapla'
    Gothmog

    Gegen jeden, der es unternimmt, diese Ordnung zu beseitigen, haben alle Deutschen das Recht zum Widerstand, wenn andere Abhilfe nicht möglich ist. (Art. 20(4) GG)[SIZE=-1]
    [/SIZE]

  • Wenn man von YUY2 nach YV12 konvertieren muss -- dann immer mit der Angabe "interlaced={false|true}"! Bei falscher Wahl erhält man sonst Mischfarben, die zu unerklärlichen Ergebnissen führen können.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!