Kleines AviSynth-Problem

[beiti]

Ich habe mich nach längerer Pause mal wieder mit AviSynth (genauer: Framerate-Interpolation mittels MVTools) auseinandergesetzt.

Früher habe ich das schon mal erfolgreich praktiziert.
Damals hatte ich jedoch immer Interlaced-Ausgangsmaterial. Daher habe ich den Yadif-Filter benutzt, um aus meinen 50 Halbbildern erst mal 50 Vollbilder zu machen, bevor ich diese Vollbilder dann zur weiteren Verarbeitung an MVTools übergeben habe.
Heute geht es allerdings um Material, das schon in Vollbildern (18 fps) vorliegt. Daher habe ich den Yadif-Filter einfach durch Vorsetzen von # aus dem Script rausgenommen - mit dem Ergebnis, dass das Script danach überhaupt nicht mehr funktionierte. Es gab immer rätselhafte Fehlermeldungen, laut denen angeblich ein Parameter des MSuper-Befehls nicht erkannt werde (was Unfug ist - schließlich wird er ja, solange die Yadif-Zeilen im Script drin sind, auch erkannt).

Nach längerem Probieren bin ich dann drauf gekommen, dass ich noch nicht mal eine komplette Yadif-Konversion machen muss. Es genügt schon, die Zeile "AssumeTTF" drin zu lassen. Die war ja eigentlich nur für den Yadif-Filter gedacht, damit der weiß, wie er die Halbbildreihenfolge des Materials behandeln muss. Aber aus irgendeinem ominösen Grund sorgt sie auch dafür, dass mein Video plötzlich durch MVTools lesbar wird.

Hat jemand eine Erklärung für dieses Verhalten? Kann ich die Zeile "AssumeTTF" durch irgendwas ersetzen, was nicht (fälschlich) mein Material als Interlaced interpretiert?
Hat "AssumeTTF" überhaupt Einfluss aufs Ergebnis in MVTools?

Code: Alles auswählen

# Import des Ausgangsdatei
ausgangsclip = DirectShowSource("F:\boccia2-18.avi", fps = 18, audio = False)

# Laden des Yadif-PlugIns
# Load_Stdcall_plugin("C:\Program Files (x86)\AviSynth\plugins\yadif.dll")

# Smart-Bobbing mit Yadif
AssumeTFF(ausgangsclip)
# Yadif(Mode=1)

# Laden des MVTools-2-PlugIn.
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll")

# Erstellung temporärer Clips: Super-Clip und Vektoren-Clips
superclip = MSuper(pel=2)
vektorclip_rueckw = MAnalyse(superclip, overlap=0, isb = true, search=4)
vektorclip_vorw = MAnalyse(superclip, overlap=0, isb = false, search=4)

# Berechnung der Zwischenbilder für 59,94 fps
MFlowFps(ausgangsclip, superclip, vektorclip_rueckw, vektorclip_vorw, num=60000, den=1001)

[mash_gh4]

ich kann es hier nicht ganz einfach reproduzieren, weil unter linux ja bekanntlich besser VaporSynth benutzt wird, aber die "AssumeTFF" anweisung sollte man wohl definit genaus wie die den YADIF-deinterlace-schritt rauswerfen, wenn es sich um progressives ausgangesmaterial handelt. ein einfaches "AviSource("....avi")" od.ä. sollt statt dessen genügen.

evtl. solltest du jene "rätselhafte Fehlermeldungen", von denen du sprichst, auch posten, um konkreter sagen zu können, was sie bedeuten.

[beiti]

Ich hatte es zuvor auch schon mit AVISource probiert. Das macht keinen Unterschied. (DirectShowSource war eigentlich nur einer meiner hilflosen Versuche, dem Problem auf die Spur zu kommen.)

Die Fehlermeldung kann ich posten. Die ist nach meiner Einschätzung allerdings irreführend und hat mit dem eigentlichen Problem nichts zu tun (das kenne ich noch aus früheren Fehlversuchen mit AviSynth).

Wenn ich die Zeile "AssumeTFF" weglasse, kommt nämlich Folgendes:
Avisynth open failure:
Script error: Invalid arguments to funktion "MSuper"
(F:\fps_interpolieren_boccia2.avs, line 25)

Was hier mit "line 25" gemeint ist (also wie das Programm die Zeilen im Script zählt), ist nicht ganz klar. Nach meiner Zählung ist Zeile 25 eine von denen, die mit # beginnen und daher nicht relevant sind. (Mein Originalscript enthält jede Menge Kommentare mit # davor.)
Ich denke, die Fehlermeldung bezieht sich auf die einzige Zeile, in der der Begriff "MSuper" überhaupt vorkommt:
superclip = MSuper(pel=2)

Was hier falsch sein soll, erkenne ich nicht. Wenn man das Argument (pel=2) weglässt, ändert das übrigens nichts.
Abgesehen davon wird die Zeile ja wieder anstandslos verarbeitet, sobald oben die Zeile "AssumeTFF" aktiv ist. Von daher kann sie doch nicht völlig falsch sein.

[mash_gh4]

Ich hatte es zuvor auch schon mit AVISource probiert. Das macht keinen Unterschied. (DirectShowSource war eigentlich nur einer meiner hilflosen Versuche, dem Problem auf die Spur zu kommen.)

wie gesagt, bei den avsynth bzw. windows spezifischen details kann und will ich ohnehin nicht unbedingt mitreden können... ;)

Die Fehlermeldung kann ich posten. Die ist nach meiner Einschätzung allerdings irreführend und hat mit dem eigentlichen Problem nichts zu tun (das kenne ich noch aus früheren Fehlversuchen mit AviSynth).

Wenn ich die Zeile "AssumeTFF" weglasse, kommt nämlich Folgendes:
Avisynth open failure:
Script error: Invalid arguments to funktion "MSuper"
(F:\fps_interpolieren_boccia2.avs, line 25)

Was hier mit "line 25" gemeint ist (also wie das Programm die Zeilen im Script zählt), ist nicht ganz klar. Nach meiner Zählung ist Zeile 25 eine von denen, die mit # beginnen und daher nicht relevant sind. (Mein Originalscript enthält jede Menge Kommentare mit # davor.)

normalerweise sollte ein derartig formatierte felermeldung sich schon auf die betroffene zeile im explizit angegebenen source file beziehen.

ich würde aber im gegeben fall und der etwas eigenwilligen und nicht immer sonderlich sauberen arbeitsweise von avisynth evtl. auch überprüfen, ob hier nicht probleme innerhalb eines aufgerufenen weiteren scripts bzw. einer verschachtelung vorliegen -- was ich allerdings deinem script auf den ersten blick nicht entnehmen kann -- , die zu einer derart irrtümlichen ausgabe führen.

ähnliche -- oft python basierende -- systeme, liefern hier gewöhnlich eher eine fehlermeldung, die gleich den ganzen stapel der verschachtelungen bzw. relevanten stellen in den source files erkennen lassen.

Ich denke, die Fehlermeldung bezieht sich auf die einzige Zeile, in der der Begriff "MSuper" überhaupt vorkommt:
superclip = MSuper(pel=2)

das würde ich auch so sehen.
evtl. könnte es sich aber in deiner tatsächlich gerade genutzten MVTools version irgendwas bzgl. der parameterübergabe geändert haben?
gefühlsmäßig würde ich aber auch eher irgendwas im datenfluss davor für verantwortlich halten....

"pel=2" ist hier jedenfalls tatsächlich auch der default-wert, den man ohnehin weglassen könnte.

ja -- es hat schon seine gründe, warum es nicht mehr so viele liebhaber von avisynth und dessen geheimnissen gibt ;)

[beiti]

normalerweise sollte ein derartig formatierte felermeldung sich schon auf die betroffene zeile im explizit angegebenen source file beziehen.

Ich habe mein Script mal auf das Nötige zusammengestaucht, also Leerzeilen und Kommentare weggelassen:

Code: Alles auswählen

ausgangsclip = AVISource("F:\boccia2-18.avi")
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll")
superclip = MSuper(pel=2)
vektorclip_rueckw = MAnalyse(superclip, overlap=0, isb = true, search=4)
vektorclip_vorw = MAnalyse(superclip, overlap=0, isb = false, search=4)
MFlowFps(ausgangsclip, superclip, vektorclip_rueckw, vektorclip_vorw, num=60000, den=1001)

An der Fehlermeldung ändert das nichts - außer, dass jetzt die korrekte Zeile mit dem MSuper-Befehl (line 3) genannt wird. Wahrscheinlich war in der kommentierten Version mit der Zeilenzahl was durcheinandergekommen.

ob hier nicht probleme innerhalb eines aufgerufenen weiteren scripts bzw. einer verschachtelung vorliegen

Verschachtelt habe ich nichts.

evtl. könnte es sich aber in deiner tatsächlich gerade genutzten MVTools version irgendwas bzgl. der parameterübergabe geändert haben?

Das oben gezeigte, verkürzte Script habe ich gerade exakt so getestet. Mit demselben Ergebnis (Fehlermeldung) wie vorher.

es hat schon seine gründe, warum es nicht mehr so viele liebhaber von avisynth und dessen geheimnissen gibt ;)

Schwer vorstellbar, dass es die überhaupt mal gab. :)

[beiti]

Okay, jetzt bin ich auf was Interessantes gestoßen.
Es funktioniert auch, wenn ich statt "AssumeTFF" folgende Zeile reinmache:
ConvertToYUY2 (ausgangsclip)

[mash_gh4]

Okay, jetzt bin ich auf was Interessantes gestoßen.
Es funktioniert auch, wenn ich statt "AssumeTFF" folgende Zeile reinmache:
ConvertToYUY2 (ausgangsclip)

prima! -- dann erspare ich mir, dir zu schreiben, wie man genau das selbe mit VapourSynth in analoger, aber eben plattformübergreifender, weise realisieren könnte.

genau diese kleinen details, wie unklarheiten bzgl. des tatsächliche benutzte pixelformats, sind es, die AviSynth so unglaublich problematisch erscheinen lassen. es hat zwar natürlich auch seine vorteile, dass das dort alles derart primitiv und minimalistisch gelöst ist, man also nicht, wie bspw. bei OpenFX, extrem viel umgebenden verwaltungscode schreiben muss, um auch nur die einfachsten operationen am bild tatsächlich in code umzusetzten, aber das bringt eben auch genau solche folgen mit sich.

wenn man schon mühen auf solche sache verschwenden muss, ist es daher meist zielführender, wenn man gleich zu zeitgemäßeren professionellen lösungen greift. z.b. könntest du ja mit den konos-nodes im nuke [non-commercial] genau das selbe wie mit diesem script bewerkstelligen -- nur eben technisch deutlich befriedigender.

[beiti]

wie man genau das selbe mit VapourSynth in analoger, aber eben plattformübergreifender, weise realisieren könnte.

Prinzipiell würde mich das schon interessieren, da VapourSynth auch wesentlich schneller sein soll. Hab mich da aber bisher nicht rangetraut, weil die Scripte wieder ganz anders aufgebaut sein müssen (und ich hatte schon mit AviSynth genug zu kämpfen).

wenn man schon mühen auf solche sache verschwenden muss

"Müssen" tu ich das zum Glück nicht. ;) Aber es gibt eben einige Bereiche, wo Frameraten-Interpolation interessante Möglichkeiten eröffnet.

Vor ein paar Jahren hatte ich mich daran versucht, weil ich 50i-Videos für die US-Verwandtschaft konvertieren musste und im Ergebnis möglichst geschmeidige Bewegungen erhalten wollte. Das kriege ich inzwischen auch gut hin.

Aktuell geht es um die Nachbearbeitung von frisch digitalisiertem Super-8-Material, dem ich zu etwas flüssigerer Bewegung verhelfen will. Das ist allerdings nicht so einfach wie im Fall des digital gefilmten Ausgangsmaterials, weil das Super-8-Material naturgemäß unscharf und körnig ist und zudem einen schlechten Bildstand hat. Dort, wo vom Stativ gefilmt wurde, klappt die MVTools-Methode erstaunlich gut und verhilft den alten Aufnahmen zu neuen Qualitäten. Aber sobald die Kamera wackelt oder schnell schwenkt, treten unschöne Nebeneffekte auf; ich kann also nicht einfach das ganze Material unbesehen so verarbeiten.
Von daher könnten mich (bessere) Alternativen zu MVTools durchaus interessieren.

z.b. könntest du ja mit den konos-nodes im nuke [non-commercial] genau das selbe wie mit diesem script bewerkstelligen -- nur eben technisch deutlich befriedigender.

Das ist bestimmt interessant und wäre einen Versuch wert. Muss ich schauen, ob ich mich mal aufraffen kann, mich da reinzufuchsen; Nuke ist halt eine professionelle Software, in der man vermutlich nicht mal schnell mit ein paar Klicks was zustande bringt...