Beiträge von Mike99

    Jede Variable hat ihren Geltungsbereich.

    Die Deklaration einer Funktion ist abstrakt. Da sie mehrfach aufgerufen werden könnte, ist es im Allgemeinen sinnvoll, Daten (Clips, Zahlen, Texte) als Parameter zu übergeben und Ergebnisse als Funktionswert zu hinterlassen.

    Globale Variablen, die auch in den Funktionen ihre Gültigkeit haben, sind in AviSynth auch möglich. Jedoch muss man dann sehr genau aufpassen, dass diese Konstruktion dann auch in jedem Zusammenhang funktioniert. Es kann nötig sein, wenn durch eine Funktion mehrere Werte geändert zurückgegeben werden müssen, da AviSynth keine Felder kennt.

    Letzteres hat mich am Anfang mindestens mal eine Stunde aufgehalten, bis ich festgestellt habe, dass es avsi-files gibt die automatisch laden und eine davon jene besagten Glabalvariablen enthielt, wird sicher nicht das letzte Rätsel gewesen sein ....

    Innerhalb der Funktion ist die Variable "last" zunächst lokal undefiniert. Wenn du eine Funktion aufrufst, ohne deren Ergebnis einer Clip-Variablen zuzuweisen, dann wird die lokale Variable "last" innerhalb der Funktion das Ergebnis übernehmen.

    Das sorgt für Klarheit, danke.

    Ersteres hatte ich fasst erwartet, letzteres nicht unbedingt.
    Wenn die lokale Variable last den Wert in diesem Fall zugewiesen bekommt, dann müsste sie sich aber anschließend, da nur lokal und Funktion beendet, sozusagen in Luft auflösen.

    Eigentlich schade, dass es hierfür keine Entwicklungsumgebung mit Debugger gibt, da könnte man das alles schön zur Laufzeit analysieren. Allerdings muss ich auch zugeben, dass mir Script- und Makrosprachen schon immer ein wenig suspekt waren.

    So weit noch richtig...


    Nein.

    "FSC = shrp.mergechroma(smA)" entspricht "FSC = mergechroma(shrp, smA)"; mehr nicht.

    "last" kommt nur ins Spiel, wenn du bei zwei erwarteten Clips nur einen Clip (den zweiten) explizit angibst, aber in deinem Beispiel hast du beide angegeben.

    Da hasst Du natürlich recht, es war wohl noch ein wenig früh heute morgen:hm:.

    Was mich aber im Moment noch am meisten interessieren würde ist die Frage, ob innerhalb der aufgerufenen Funktion die Variable last dann mit der ersten clip-Variable aus dem Funktionsaufruf belegt wird oder ev. sonstwie?

    Hallo Ligh,

    die Klammern habe ich mal noch nachgetragen, danke für den Hinweis.

    Die Funktion ist aber sowieso noch nicht ganz fertig, mit der Kämpfe ich auch inhaltlich noch:huh:.

    Bezüglich mergechroma ging es mir nur darum, dass mergechroma(clip1) identisch sein sollte zu mergchroma(last, clip1) zu last = mergechroma(last, clip1) zu last = last.mergechroma(clip1). Analog müsste dann FSC = shrp.mergechroma(smA) identisch sein zu FSC = shrp.mergechroma(last, smA).

    Und in dem Moment als ich darüber nachdachte fiel mir auf, dass mir dieser generelle Umgang mit last bzw. deren Inhalt in der aufgerufenen Funktion noch nicht verständlich ist, daher die Fragen.

    Beste Grüße Michael

    Nachdem ich das Variablenkonzept einigermassen verstanden hatte (siehe meine Frage zu implizit / explizit) ist mir nun doch wieder etwas unklar.

    Beim Aufruf einer internen Funktion übergebe ich als ersten Parameter eine Variable vom Typ clip. Wenn ich diese Variable nicht angebe wird automatisch die Variable last an die Funktion übergeben.

    Nun frage ich mich wie innerhalb der aufgerufenen Funktion mit der Variable last umgegangen wird.

    Wird diese mit der ersten übergebenen clip-Variable gleichgesetzt?

    Was passiert, wenn ich keine clip-Variable übergebe und auch keine in den Übergabeparametern angegeben ist?
    Ist sie dann initial oder wird sie vielleicht mit der last-Variable der übergeordneten Ebene gefüllt?

    Die betroffene Funktion sieht im aktuellen Entwicklungsstand so aus und soll eigentlich nur dazu dienen das nachschärfen von Testvideos bezüglich Qualität, Codierungslaufzeit und Dateigröße zu untersuchen:

    Ob die Funktion so läuft ist noch offen, vor allem wegen dem letzten Befehl mit mergechroma, der ja automatisch last ziehen sollte, falls ich das richtig verstanden habe. Und daraus entstand dann meine Frage.

    Beste Grüße Michael

    4 fps - ach, Gottchen: Wer schön sein will, muss leiden. Die Nacht ist wunderbar zum Rendern da. ;)

    Was mir an deinem Skript noch fehlt, um es selber mal ausprobieren zu können, wäre noch eine Dokumentation, welche zusätzlichen Plugins ich dafür brauche. Ich wüsste jetzt nicht auswendig, wo MDegrain2 enthalten ist, zumindest nicht ohne im Internet herumzusuchen.

    Wenn ich soweit bin werde ich mir vermutlich aus vorhandenen Teilen und ein paar Zukäufen einen Rechenknecht zusammenbauen und in den Keller stellen, da kann er dann in Ruhe arbeiten. i7 wäre zwar toll, ist mir aber in Summe (bes. Mainboard) zu teuer.

    Das Script ist geklaut und entspricht weitgehend einem Beispiel von Fizick zu seinen MV-Tools. MvDegrain2 ist Bestandteil der MvTools und macht bewegungskompensiertes entrauschen mit einem Radius von 2 Frames jeweils vorwärts und rückwärts (MvDegrain1 und MvDegrain3 gibt es auch noch). Das war letztes Jahr der Beginn eines tieferen Einstiegsversuches in die Materie, als ein Film durch die Umwandlung mehr Platz verbraucht hatte als vorher und der Laie (Ich) sich natürlich ziemlich gewundert hat. Rein für dieses Script braucht man nur die MvTools selbst (avisynth-org-ru). Falls man vorfiltert (fft3d hatte ich dafür genommen) kommt natürlich noch etwas hinzu.

    Obiges Mini-Script läuft natürlich schneller als das MCT was ich gerade probiere. Da sind etwa 7 Frames möglich. Das MCT findet sich übrigens auf doom9-org, genau wo kann ich nicht sagen, da das Forum mal wieder unten zu sein scheint. Auf jeden Fall hat sich da jemand ganz schön Mühe gegeben und ich wäre froh, wenn ich schonmal die Hälfte verstehen würde.

    Gruß Michael

    :daumen:


    Dazu soll stax0711 mal lieber selber was sagen... [Blockierte Grafik: http://cosgan.de/images/smilie/verschiedene/f020.gif] ...in der Zwischenzeit erkläre doch mal etwas ausführlicher, welche Entwicklungen du noch für notwendig bzw. sinnvoll hältst.

    Es ist weniger die Entwcklung von Staxrip selbst an die ich dabei dachte, die war für mich nahezu perfekt und, zumindest für meine Zwecke, von allen GUIs die ich ausprobieren konnte am effektivsten (nachdem ich denn endlich kapiert hatte, wie ich externe Scripte einbinden konnte). Ich kann mir aber vorstellen, dass das sich weiterentwickelnde Umfeld dazu führt, dass es eine Sackgasse wird. Ich kenne die Interna des Programmes natürlich nicht und kann daher nur vermuten, dass es bei sich ändernden Schnittstellen, Parametern usw. irgendwann nicht mehr einsetzbar ist. Da ich MeGui aber nicht so sehr mag, werde ich das Risiko sehr wahrscheinlich eingehen.

    Unabhängig davon habe ich mal eines der umfangreicheren Scripte (MCTemporaldenoise) mit etwas höheren Einstellungen loslaufen lassen um ein Gefühl fürs Tempo zu bekommen wenn man mehr als nur entrauschen tut. Das reduziert die Rate auf etwa 4,2 fps auf meinem Notebook. Selbst mit einem übertakteten i7-4kern wären das dann vermutlich kaum mehr als 15-18 fps grob überschlagen, ganz schön heftig.

    Nun, in dem Fall ist es so, weil du die Funktion so deklariert hast, dass ihr erster Parameter ein Clip ist.

    Siehe auch den Vergleich der beiden Varianten des aktiven Skriptes: Einfach "AviSource(...)" und "TemporalDegrain()" hintereinander funktioniert ja, indem implizit der Clip "last" in jedem Schritt gefiltert wird.

    Nur damit ich das wirklich richtig verstehte:

    Da ich die Funktion mit dem ersten Parameter vom Typ clip deklariert habe ist

    Temporaldegrain() = Temporaldegrain(last) ?

    (oder auch last.Temporaldegrain() )

    Wäre der erste Parameter der Funktion nicht vom Typ clip, dann würde es nicht mehr gehen analog der dann nicht mehr möglichen Prefix-Notation?
    Falls das so ist, dann sickert es langsam durch:).

    Mein Variablenverständnisproblem hat sich übrigens weitgehend gelöst. Es ging um eine für mich nicht nachvollziehbare Globalvariable, die aber über ein avsi-Script im plugin-Verzeichnis automatisch geladen wurde (muss man halt nur wissen).

    Ansonsten mache ich gerad mal ein paar Laufzeittests, habe jetzt MT dazu genommen, probiere noch fft3dgpu (falls es stabil läuft), usw.

    Leider scheint Staxrip aktuell einem Entwicklungsstop zu unterliegen. Das hatte mir nämlich am besten gefallen, nachdem ich rausgekriegt hatte, wie ich da beliebige Scripts einbinde. Jetzt nehme ich erstmal MeGui.

    Gruß Michael

    Hallo LigH,

    vielen Dank für die Erklärung und auch fürs Willkommen. Ich hatte mich ja Anfang letzten Jahres schonmal angemeldet, zu der Zeit waren aber nach ein paar Tests ausreichender Speicherplatz und Rechenleistung (auch preislich) für mein Archivierungsvorhaben noch ungenügend, mittlerweile scheint es eher zu passen.


    Ich hab das Script mal in einen PHP-Block gepackt. Vor allem damit man sieht, wo der Code beginnt und wo er aufhört; aber da stand bei dir noch eine Zeile davor: Bei dem Aufruf der Funktion "TemporalDegrain()" noch vor ihrer Deklarierung war ich nicht sicher, ob das noch dazugehört...

    Der Funktionsaufruf war angegeben wegen der Frage, ob ein Funktionsaufruf ohne Parameter möglicherweise immer die Variable last übergibt. Ist ja glücklicherweise nicht der Fall.


    Wenn du das, was du jetzt im PHP-Block siehst, in eine Datei "TemporalDegrain.avsi" verpackst, und diese dann mit 'Import("TemporalDegrain.avsi")' in deinem eigentlichen Skript verwendest, wird die Trennung von Deklaration und Aufruf sicher deutlicher.

    PHP
    Import("TemporalDegrain.avsi")AviSource("film.avi")TemporalDegrain()

    Das werde ich auf jeden Fall tun, sonst wird es doch schnell unübersichtlich und die Wiederverwendbarkeit leidet. Inhaltlich kann ich ja bei vielen Scripten (noch) nicht folgen, manche sind aber ganz schön lang.


    Das ist natürlich nicht nötig. Die Funktionsdeklaration kann trotzdem auch gern weiter im aktiven Skript stehen. Ich würde die Funktion - wie aus anderen Sprachen gewohnt - gern mit im Anfang des Skriptes schreiben, habe allerdings gehört, dass sie am Ende des Skriptes eventuell für den AviSynth-Skriptparser günstiger sei...

    Vermutlich fängt er dann von hinten an. Ich würde die Includes aber trotzdem auch an den Anfang schreiben, das bin ich einfach so gewohnt und ich finde es übersichtlicher.

    Zu den Variablen muss ich mir noch ein paar Gedanken machen. Da kämpfe ich im Moment noch mit der offiziellen Doku. Grundsätzlich tendiere ich eher dazu last nicht zu verwenden und alles was ich verwende komplett zu deklarieren inkl. Typ der Variablen, auch in den Funktionsaufrufen.

    Hallo,

    da ich wohl nicht umhinkomme, bei einigen Aufnahmen Hand anzulegen, versuche ich gerade, mich (wieder) mit Avisynth vertraut zu machen. Im Moment beschäftigt mich der Umgang mit Variablen in den Scripten, insbesondere die Variable last.

    Als Trockenübung (Inhalt ist nicht wichtig) habe ich mal folgendes zusammengestellt:

    Im Header der Funktion habe ich eine Variable vom Typ clip deklariert.
    Wird beim Aufruf der Funktion ohne Angabe von Parametern automatisch der Inhalt von last übergeben oder funktioniert das so gar nicht?
    Bleibt die Variable last, die ja oberhalb der Funktionsebene existiert, auch innerhalb der Funktion erhalten bzw. ist sie generell als global deklariert? Oder hat jede Funktion eine eigene, gekapselte last-Variable?

    Die Funktion Msuper hat als ersten Parameter einen clip. Da müsste es doch eigentlich genügen, nur die entsprechende Variable hinzuschreiben. Oder muss da "clip = input" stehen? Die anderen Variablen werden ja nicht in Reihenfolge versorgt, da ist die explizite Nennung klar.

    Ginge auch "super = input.MSuper(pel=2, sharp=1)"?
    Würde mir von der Syntax her besser gefallen.

    Der Aufruf von MDegrain2 in dieser Form speichert vermutlich das Ergebnis in last?

    Ich kann eigentlich programmieren, tue mich mit den Konzepten von Avisynth allerdings trotzdem etwas schwer :huh:

    Gruß Michael