Das war schon klar, allerdings hatte ich die Funktion fflow nicht verstanden. Ich bin davon ausgegangen, dass ich mit selecteven und selectodd die Halbbilder getrennt bearbeite.
OK, mit selecteven und selectodd nehme ich jeweils nur jeden zweiten Frame, und fflow setzt dann immer einen interpolierten Frame dazwischen.
Dann werden die getrennten Clips wieder zusammengefügt (interleave) und jeweils nur die interpolierten Frames herausgepickt (selectevery).
Das ist prinzipiell das, was ich wollte.
Hallo,
ich greife das Thema noch einmal auf.
Ich möchte gerne einen Clip definieren, der jeden Frame (der ersten und letzten erst einmal ausgeklammert) durch eine Interpolation des vorherigen und des nachfolgenden ersetzt.
Dabei bin ich auf folgendes gestoßen:
function fflow (clip c)
{
sup = c.msuper (pel=1)
bv = sup.manalyse (isb=true)
fv = sup.manalyse (isb=false)
c.mflowfps (sup, bv, fv, num=0)
return(c.mflowfps (sup, bv, fv, num=0))
}
Aufruf dieser Funktion wie folgt:
function I1ClipV (clip c)
{
o = c
flowed = interleave( o.selecteven().fflow(), o.selectodd() .fflow() ).selectevery(4, -1, 2)
return (flowed)
}
Ist das so korrekt bzw. was lässt sich verbessern?
Mich irritiert, warum hier oberes und unteres Feld nicht erst getrennt werden müssen, also so:
function I1ClipV (clip c)
{
o = c.SeparateFields()
flowed = interleave( o.selecteven().fflow(), o.selectodd() .fflow() ).selectevery(4, -1, 2)
return(flowed.weave())
}
Das Ergebnis ist hier aber ein anderes, unerwünschtes.
Aus einer Sequenz von Frames blau blau rot blau blau macht
(1) blau dunkelrot blau dunkelrot blau
(2) blau violett dunkelrot violett blau
Demnach arbeitet nur (1) richtig, weil es den roten Fehlerframe durch einen blauen ersetzt.
OK, die Runtimes fehlten. Ich habe den Installer genommen.
Jetzt läuft AVS+ r2772 MT, x86_64.
Aber mvtools2 nicht.
Einzige 64-Bit Version ist "mvtools2 2.7.39\x64\", und obiges Skript ergibt sehr grünes Bild.
Und die neue 2.7.40 macht das Bild noch schöner !
Es liegt übrigens nicht an der 64-Bit-Version.
2.7.39\x86 und 2.7.40\x86 erzeugen ebenfalls vorrangig grün.
Die letzte Fizick-Version mvtools-v2.5.11.20\mvtools2 funktioniert noch.
Neuinstallation unter Win 10:
AvsPmod 32 kommt nicht mit allen AVS Versionen klar:
AVS258 AviSynth Fenster erscheint kurz und schließt sofort wieder
AVS260 AviSynth 2.60, build:Mar 31 2015 [16:38:54] OK
AVS261_Alpha Fenster erscheint kurz und schließt sofort wieder
AVS260_ICL AviSynth 2.60 (ICL10) OK
AVS260_MT AviSynth 2.60, build:Feb 20 2015 [03:16:45] OK
AVSPLUS_X86 Fehlermeldung [Error 126] Loading avisynth.dll failed.
AvsPmod 64:
AVSPLUS_X64 Fehlermeldung [Error 126] Das angegebene Modul wurde nicht gefunden.
Fazit: AvsPmod läuft nur als 32 Bit mit den AVS260-Varianten.
Vielen Dank, FatFaster.
Wenn ich den Universal Avisynth Installer benutze, muss ich dann noch etwas von https://github.com/pinterf/AviSynthPlus runterladen? Was?
Ich brauche die 32-Bit-Version, wenn ich die vorhandenen Plugins nutze, richtig?
Und noch eine Frage zu Vapoursynth:
Gibt es eine Möglichkeit des "Einbaus" in meinen Ablauf?
Ich lese in Avisynth/AvsPmod eine avi.Datei mit Codec Lagarith ein und bearbeite Sie mit mehreren Filtern, zuerst kommt denoise.
Die Ausgabe könnte entweder wieder in Lagarith erfolgen oder Eingabe für ffmpeg (x264) sein.
Ich müsste dann also eine mit Vapoursynth bearbeitete Datei in Avisynth einlesen.
Das geht wahrscheinlich nicht ohne zwischenspeichern. Ist das im geleichen Format (Lagarith, ohne Farbraumkonvertierung) möglich?
Gruß
Highwayman.
D.h. von AvsPmod gibt es noch keine offizielle Version für Avisynth+ ??
Overlay = 4 müsste die Genauigkeit auf ein halbes Pixel verbessern.
Ich bin mir nicht sicher, ob Overlay = 4 irgendetwas verändert.
oriA = ori.xMdegrain2i2 (0, 0)
oriB = ori.xMdegrain2i2 (4, 0)
return stackhorizontal (oriA, oriB, Overlay (oriA, oriB, mode = "subtract"))
Das dritte Bild zeigt tiefe Schwärze.
Ich weiß nicht, ob das etwas aussagt.
Oder kann man auch verschiedene Avisynth-Versionen parallel betreiben bzw. wechseln?
Wo wird eingestellt, welche Version VDub bzw. avsPmod nimmt?
In der Registry?
Wenn ich jetzt unter Win 10 eine neue Umgebung aufbaue, auf welche Standards / Versionen sollte ich dann bauen?
Für die Filterung und den Austausch von Frames brauche ich
Avisynth
AvsPmos
VirtualDub
und diverse Filter, meist 32-Bit.
Avisynth+ 64 Bit ?
Highwayman.
Ich habe mir erst einmal den overlap-Parameter vorgenommen.
In MDegrain2i2 ist der Default-Wert ja 0. Keine Ahnung, warum ich den damals auf 4 eingestellt habe.
Und hier ist ja schon ein enormer Performance-Unterschied.
Meine Werte für einen 4-Minuten-Clip (SD, 720 x 576, Lagarith --> YUY2):
overlap = 4: ~3.5 fps, ca. 27 Minuten
overlap = 0: ~11.5 fps, ca. 9 Minuten
Das ergibt bei einem 1h-Band: 6 3/4 h gegen 2 1/4 h.
Das wäre schon einmal sehr viel besser.
Kann jemand beantworten, was der overlap-Parameter genau bewirkt? Auf den ersten Blick sehe ich keinen Unterschied.
FatFaster: 40 fps klingt natürlich super. Python schreckt mich nicht, nutze ich zusammen mit AvsPmod.
Was genau ist Vapoursynth? Wie kann es einbunden werden?
Neuere mvtools2.dll (von https://github.com/pinterf/mvtools/releases) die eventuelle die CPU besser nutzt ist das Einzige was mit einfällt.
Dafür scheint mein Avisynth zu alt zu sein: ... is not an Avisynth 2.5 plugin
Ich nutze Avisynth zusammen mit AvsPmod 2.5.1 unter Windows 7 und weiß nicht, welche Baustellen entstehen, wenn ich Avisynth durch eine neue Version ersetze. Evtl. baue ich das parallel unter Win 10 auf.
Hallo,
ich habe mich vor langer Zeit für eine Denoise-Funktion entschieden, die optimale Ergebnisse bei kurzen Testclips bringt.
Bei Clips in Stundenlänge läuft das bei mir aber mehrere Stunden bzw. Tage.
Ich glaube, dass ich da eine optimale Varinate gewählt habe, die aber keinen praktischen Mehrwert gegenüber anderen Varianten bringt.
Ich brauche da eigentlich eine Empfehlung, wie
Hier die Funktion denoise (clip c):
LoadPlugin ("E:\Projekt_Capture_Win_7\Plugins\mvtools2.dll")
function denoise (clip c)
{
erg = Mdegrain2i2 (c, 4, 0)
return (erg)
}
function MDegrain2i2 (clip source, int "overlap", int "dct")
{
overlap = default (overlap, 0) # overlap value (0 to 4 for blksize=8)
dct = default (dct, 0) # use dct=1 for clip with light flicker
fields = source.SeparateFields () # separate by fields
super = fields.MSuper ()
backward_vec2 = super.MAnalyse (isb = true, delta = 2, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse (isb = false, delta = 2, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse (isb = true, delta = 4, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse (isb = false, delta = 4, overlap=overlap, dct=dct)
erg = fields.MDegrain2 (super, backward_vec2, forward_vec2, backward_vec4, forward_vec4, thSAD=400)
erg = erg.Weave()
return (erg)
}
Gruß
Highwayman
Ja, zb das hier https://forum.doom9.org/showthread.php?p=1772209
Danke für den Hinweis.
Ich habe FrameSurgeon kurz ausprobiert (musste einige Plugins downloaden, läuft jetzt).
Ich tendiere dazu, SawBones durch meine Anwendung unter AvsPmod zu ersetzen.
Problem ist, dass SubRip nicht mit allen Codecs klarkommt.
avi uncompressed und Lagarith funktionieren.
Gebe mal ein Videobeispiel. Habe hier ähnliche Probleme mit Video 2000 Material, was ja noch bescheidener an Qualität ist als Dein Hi8-Material.
Hallo Propaganda,
ich habe die Beispiele oben in #1 eingefügt.
Hallo,
beim Digitalisieren meiner (alten) Hi8-Kassetten tritt ein Problem sporadisch auf: eine horizontale Störung.
Eigentlich gibt es drei verschiedenen Ausprägungen:
Meistens ist nur ein Frame betroffen, oft nur ein Halbbild.
Manchmal sind es Stellen, die besonders wichtig sind.
Was ist von einer Lösung zu halten, nur ein Halbbild zu verwenden (für den betroffenen Frame)?
oriB = oriA.SeparateFields().Bob().SelectEven()
oriC = oriA.SeparateFields().Bob().SelectOdd()
Ich würde dann den Frame aus oriA durch den entsprechenden aus oriB oder oriC ersetzen.
Gibt das Probleme, leidet die Qualität darunter?
Gibt es bessere Ansätze?
Z.B. ein Frame durch einen aus vorherigem und nachfolgendem Frame zu berechnen?
Oder nur einen Zeilenbereich zu ersetzen?
Die Werkzeuge stehen mir eigentlich durch avsPmod, Python und Avisynth zur Verfügung.
Für die Korrektur von weißen Fischen setze ich das auch schon ein, wäre nur zu erweitern.
Highwayman.
Ich habe probiert, den Code mittels SubRip auszulesen (musste erst einmal den Timecode nehmen).
Im Prinzip funktioniert das, derzeit aber noch mit gelegentlichen Fehlern.
SubRip muss wohl noch besser angelernt werden, Problem sind die wechselnden Hintergründe, teilweise in gleichen Farben wie der Text.
Eigentlich müsste SubRip nur auf Ziffern, Punkt und Doppelpunkt getrimmt werden, aber ich komme mit dem Tool noch nicht ganz klar.
Alle genannten Codecs, sind in VDub(Vers. 43073) verfügbar, auch im Capture-Modus.
Hallo Pro Jo,
Vers. 43073 ist VirtualDub2, richtig?
Ich habe aber noch ein Tool / Plugin im Hinterkopf, vielleicht schon vor Jahren einmal ausprobiert, das mittels OCR-Erkennung einen Ausschnitt analysiert und den Wert zusammen mit der Framenummer in eine Datei schreibt, als Grundlage für eine Subtitle-Datei (klingt nach Avisynth).
Deshalb bevorzuge ich eigentlich avi-Dateien, die ich einfach in Avisynth einlesen kann, unabhängig davon, ob das tatsächlich so umsetzbar wäre.
Ich glaube, es war SubRip. (Anspruchsvolles) Ziel ist es, den Datacode in eine srt-Datei zu scheiben, diese zu komprimieren (gleiche Werte zusammenfassen) und die Untertitel-Datei der Qualitätsaufnahmen zuzuordnen.
Mal sehen, was SubRip 1.57 kann.
