Videos nach Schneiden in VirtualDub2 RGB32 statt YUY2

    Liebe Mitforisten, ich grüße euch herzlich und hoffe ihr habt ein paar Tipps für mich.

    Ich versuche mich kurz zu fassen:

    Ausgangslage:

    Ich habe mit VirtualDub2 VHS-Capture-Aufnahmen mit Lagarith-Codec (YUY2-Modus) erstellt.

    Diese kompletten Videos werden in Avisynth geöffnet und YUY2 wird unten rechts angezeigt.

    Unklarheiten:

    Wenn ich aber diese Videos vorher in VirtualDub2 schneide (Direct stream copy), passiert folgendes:

    1. Beim Speichern als "AVI" in VirtualDub:

    Avisynth eine Fehlermeldung beim Laden der Preview: AVIsource: couldn´t locate a decompressor for fourcc LAGS

    2. Beim Speichern als "AVI handled by FFMPEG" in VirtualDub:

    Avisynth lädt korrekt, zeigt mir aber RGB32 als Farbraum unten rechts an.

    Meine Fragen:

    Warum verändert das Schneiden den Farbraum ? Sollte man diese Farbraum Konvertierungen nicht vermeiden ?

    Wann und mit welchem Programm ist das Schneiden generell am sinnvollsten ?

    Vielen Dank für eure Hilfe.

    Mit freundlichen Grüßen
    Andy

    Willkommen.

    Wie gerade anderswo geschrieben:

    Zitat von LigH

    Damit effizient komprimiert werden kann (egal ob verlustfrei wie bei Ut oder mit Verlusten wie bei AVC), wird nur sehr selten ein Schlüsselbild (engl. Keyframe; bei AVC nennt sich das I-Frame oder gar IDR-Frame) gespeichert, und alle anderen Frames speichern nur Unterschiede zu einem Schlüsselbild, auf das sie sich als Referenz beziehen (bei HEVC u.U. auch mehrere). Schneidet man irgendwo, erhält man u.U. Differenzbilder, die sich auf das abgeschnittene Referenzbild beziehen. Die speichern dann den Unterschied zu ... zu ... tja. Weg ist der Vergleich. Das Ergebnis sind dann Wiedergabefehler bis zum nächsten Schlüsselbild.

    Wenn du "sparsam decodieren" willst, um beliebig schneiden zu können, bietet VirtualDub2 für den Videostream den Modus "Fast Recompress". Der entspricht etwa dem, was beim Laden einer Videoquelle in AviSynth passiert. Hier hast du dann ein unkomprimiertes Video (z.B. in YUY2), was nach dem Schneiden neu komprimiert wird.

    Historisch gab es im originalen VirtualDub eine Abstufung, was zwischen "Fast Recompress", "Normal Recompress" und "Full processing mode" möglich ist. Im Original hat der "Full processing mode" in RGB konvertiert, weil VirtualDub-Filter nur im RGB-Farbraum gearbeitet haben. Heute mit VirtualDub2 gibt es auch Filter im YUV-Farbraum, da sind die Unterschiede zwischen den drei Modi nicht mehr so strikt.

    Guten Morgen LigH,

    und vielen Dank für die Antwort. Ich verstehe jetzt, dass auch beim Schneiden ein "Recompress" nötig ist.

    Eine Frage habe ich noch:

    Ich möchte aus den Cut-Schnipseln ein "Highlight"-Video basteln und mit einem Song unterlegen.

    Das ist mit VirtualDub2 via "Append video segment" mühselig, da die Segmente nur hinten angehängt werden und nicht mehr anders sortiert werden können. Hängt man also falsch an, kann man wieder komplett von vorne anfangen. Es gibt nicht mal einen "Rückgängig" Befehl dafür.

    Auch wenn man diese Dateien zusammen als Sequenz öffnet, finde ich keine Möglichkeit sie anders anzuordnen.

    Ich müsste die Teilstücke (z.B. als farbige Blöcke, wie bei Musiksoftware) sehen und frei verschieben können, bevor ich sie zu einem neuen Avi zusammenfasse.

    Da scheint mir VirtualDub2 der falsche Ansatz zu sein, oder ist das nur Einstellungssache ?

    Für einen Tipp wäre ich dankbar.

    In der Tat ist für so ein Vorhaben ein "Nicht-Linearer Video-Editor" mit einer Timeline besser geeignet. Wenn du kräftige Hardware hast, könnte auch schon das kostenlose DaVinci Resolve geeignet sein; ich weiß, dass einige Dashcammer für YouTube damit ihre Clips arrangieren (und nebenbei noch die Kennzeichen mit Motion-Tracking DSGVO-konform verpixeln). Aber auch für einfachere Anforderungen gibt es passende kostenlose Software (z.B. OpenShot, Shotcut, Kdenlive).

    Guten Morgen,

    vielen Dank für die Empfehlungen. Funktioniert sehr gut mit Kdenlive.

    Leider muss ich euch nochmal bemühen. Ich habe versucht mir das selber zu erschließen, kriege aber nun langsam Kopfschmerzen.

    Problem:

    Avisynth zeigt bei meinen Capture-Avi (Lagarith) immer Parity: "Bottom Field First" und "Frame Based".

    Dies dürfte aber falsch sein, denn die Befehle "AssumeBFF" & "SeparateFields" erzeugen ruckelige Bewegungen.

    Fragen:

    Nimmt Avisynth immer an, daß es BFF ist oder hätte ich das beim Capturen in VirtualDub2 schon anders einstellen müssen ("Swap fields") ?

    Reicht es aus, nun in Avisynth einfach "AssumeTFF ()" voranzustellen ?

    Was ist mit AssumeFieldBased oder AssumeFrameBased. Welches ist korrekt ?

    Ziel:

    Die Videos sollen interlaced bleiben, ich möchte nur, dass diese Flags (?) korrekt zu anderen Programmen weitergegeben werden, um Probleme zu vermeiden. Also quasi die korrekte "FieldOrder" sicherstellen, vom Anfang bis zum Ende der Bearbeitung.

    Vielen Dank für Eure Unterstützung.

    Zitat von av22

    Nimmt Avisynth immer an, daß es BFF ist ... ?

    Reicht es aus, nun in Avisynth einfach "AssumeTFF ()" voranzustellen ?

    Ja. Bei AviSource wird BFF voreingestellt, weil DV-AVIs praktisch immer BFF sind. Nach AviSource "AssumeTFF()" zu verwenden genügt, wenn AVI-Dateien geladen werden, deren Field-Dominanz tatsächlich TFF ist.

    AssumeField/FrameBased braucht man eigentlich nicht zu ändern, Quellfilter liefern das Video normalerweise Frame-Based, und lediglich Filter wie SeparateFields() und Weave() ändern das sinnvoll in ihrer Anwendung. Diese Assume-Funktionen können in seltenen Fällen für interessante Effekte nützlich sein, in der herkömmlichen Filterung muss man sie aber praktisch nicht verwenden.

    Am Ende der Filterung kann es nötig sein, die Field-Dominanz im Encoder noch mal explizit einzustellen. Die Schnittstelle, mit der AVIs oder die AviSynth-Videoausgabe an Encoder weitergeleitet werden, hat u.U. gar keine Information darüber. Falls du den x264-Encoder in VirtualDub2 verwendest, müsstest du z.B. den Kommandozeilen-Parameter --tff in das Feld "Extra command line (for advanced users)" hineinschreiben, weil dieser Dialog keine Eingabeelemente für Interlaced-Encodierung anbietet.

    Danke. Ich verstehe jetzt, wie man die korrekte FieldDominanz beibehält.

    Was ich leider immer noch nicht verstehe:

    Ich nehme an, mit "DV-AVI" meinst du ein digitales Camcorder-Speicherformat ?!

    Das mir vorliegende Material wurde mit einem Camcorder gefilmt (vor ca. 30 Jahren) und auf VHS-Kassetten überspielt (nicht von mir). Zwischen einigen Videosequenzen sieht man oben im Bild ein OSD "Hi8" aufblitzen. Also wohl analog ?!

    Von mir wurde es mittels USB-Grabber und Virtualdub2 gecaptured.

    Warum ist die korrekte FieldDominanz aber trotzdem TFF ? Liegt das an dem damals verwendeten Camcorder, am Überspielen auf VHS oder am USB-Capture Device ?

    Danke.

    DV (Digital Video) ist digital aufgezeichnet (encodiert ähnlich dem MJPEG-Verfahren) und verwendet laut Standard IEC 61834-2 / SMPTE 314M die Dominanz BFF; Hi8 ist analog (ähnlich S-VHS) und verwendet meist TFF, entsprechend dem PAL-Fernseh-Standard. Ursache ist das ursprünglich aufzeichnende Videosystem.

    Hallo LigH,

    leider brauche ich nochmal deine Hilfe. Vielleicht hast du schonmal von so etwas gehört, sonst muß ich im Kdenlive-Forum nachfragen.

    Problem:

    Ich kann die Cut-AVI Dateien aus Virtualdub2 in Kdenlive mit dem X264-Encoder nicht zu einer MP4 Datei rendern, die interlaced ist.

    Bei "Force Interlace" ruckelt das Ergebnis sowohl bei Einstellung "Top Field First" als auch bei "Bottom Field First".

    Edit: Es funktioniert wenn man bei Clip-Eigenschaften "Full luma range" aktiviert. Leider wirkt das Video danach wie mit einem hellen Schleier überzogen. Besonders gut zu sehen an den sonst schwarzen Rändern. Die sind jetzt grau.

    Wo könnte da der Zusammenhang sein ?

    Auffällig:

    Kdenlive zeigt seltsamerweise bei den Clipeigenschaften der hinzugefügten Clips (Codec Lagarith), bei Scanning: Progressive an.

    So wird die erzeugte MP4 Datei dann auch nach Rendering (bei Scanning auf "Auto") . Mediainfo zeigt "Progressive" an.

    Was ich schon versucht habe:

    Vorher die Clip-Eigenschaften auf Interlaced TFF ändern. Endergebnis: Gleich.

    Habe vermutet, daß es an den Kommandozeilenparametern für den X264 Encoder liegt und habe in einem Custom-Profil verschiedenes eingesetzt, z.B. --tff, oder interlaced=1,-flags +ilme+ildct, aber es funktioniert nicht, vielleicht weil ich die falsch gesetzt habe.

    Es kann doch aber kein progressives Material sein, ich sehe die horizontalen Zeilen sogar im Kdenlive Clipfenster ziemlich deutlich.

    Vielen Dank für jeden Hinweis.

    MfG

    Andy

    Einmal editiert, zuletzt von av22 (29. April 2021 um 20:53)

    Tut mir leid, ich habe noch nie Kdenlive benutzt...

    Der AVI-Container selbst hat keine Flags für Interlacing. Und auch nicht jeder Videocodec hat intern unterschiedliche Arbeitsmodi. Es kommt dann also nur darauf an, ob man u.U. in der Software irgendwelche Projekt-Eigenschaften hat, oder ob man den finalen Codec entsprechend konfigurieren kann. Was Kdenlive kann und ob das fehlerfrei funktioniert, weiß ich persönlich gar nicht.

    "Full luma range" ist hier sicherlich falsch. Warum es damit nicht ruckelt, kann ich mir im Moment aber nicht recht vorstellen.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden