Video länger machen ohne fps zu verändern

Oh, da fällt mir beim Überfliegen etwas auf:

Die SC-detection berechnet für jeden zu bearbeitendem Frame vier mal (!) das AverageLuma eines Frames. Ist wohl nicht so schlimm, weil die Frames zur Analyse auf 1/16 der Fläche reduziert werden ... aber trotzdem, einmal wäre genug. Es handelt sich ja immer um die Frames N-1, N, N+1, N+2.

Freihändig, ohne zu probieren:

# msk0=ch.duplicateframe(0) .reduceby2().reduceby2() .motionmask(thsd=255,y=3,u=1,v=1)
# global msk1=msk0.trim(1,0)
# global msk2=msk0.trim(2,0)
# global msk3=msk0.trim(3,0)


global msk3 = ch.reduceby2().reduceby2() .motionmask(thsd=255,y=3,u=1,v=1).trim(2,0)
global  a0 = 0.0
global  a1 = 0.0
global  a2 = 0.0
global  a3 = 0.0


	f0 = scriptclip(ch,"""sc""") #.subtitle(string(a0)+"       "+string(a1)+"         "+string(a2))""")
	f1 = f0.frameevaluate("""sc= (sc2 || sc1) ? ch : mv""")
	f2 = f1.frameevaluate("""sc2=( (a2 > (a1*5+25)) && (a2 > (a3*5+25)) ) ? true : false""")
	f3 = f2.frameevaluate("""sc1=( (a1 > (a0*5+25)) && (a1 > (a2*5+25)) ) ? true : false""")
        f4 = f3.frameevaluate("a3=averageluma(msk3)")
       # f5= f4.frameevaluate("a2=averageluma(msk2)")
       # f6= f5.frameevaluate("a1=averageluma(msk1)")
       # f6. frameevaluate("a0=averageluma(msk0)")
	f5 = f4.frameevaluate("a2=a3")
	f6 = f5.frameevaluate("a1=a2")
	f6.frameevaluate("a0=a1")

Achtung, scharfi: das ist nur der entsprechende Ausschnitt des Scripts!

Nachteil wäre, dass ganz am Anfang während der ersten 2 bis drei Frames keine Scenechanges erkannt werden. Kann man in der Praxis wohl meistens verschmerzen.

Sehr richtig, da muss ein "global" hin ... ist korrigiert, Danke. Wie gesagt, freihändig

Eventuell müsste man die Berechnungen in "f1=..." & "f2=..." ein wenig anpassen: X * 5 + 25 ist vielleicht einfach zu groß. Weiss ich aber nicht sicher ... hab mit dieser Funktion selber noch nicht gearbeitet & kann deswegen nicht abschätzen, wie der Output von MotionMask() in diesem Fall hier genau aussieht :redface:

Vielleicht fällt dem Erfinder noch was schlaues ein.

mvfpsscd() funktioniert eh nicht ganz richtig.
(bei dem erwachsenenvideo, was mir da zugeflogen ist, hats recht gut geklappt, aber der abspann hat geholpert, da lowmotion, siehe unten)

grundgedanke: das avgluma eines motionmask-bildes bei einem scenenwechsel ist x-mal höher, als die summe des AVGluma der vorhergehenden und nachfolgenden bilder

problem:
ich würde diese erkennung gerne VOR der framerate umwandlung machen und das ergebnisflag dann auf die neue framerate bringen, geht aber irgendwie nicht.

deswegen läuft die scenechange-erkennung hinter einem changefps().
problem dabei: bei low motion, oder ungünstig-motion©®™ werden auch zwischendurch mal scenenwechsel erkannt, wo keine sind, weil changefps dupes oder drops ins video schmeisst.
deswegen ist x*5+25 auch so hoch angesetzt. leider.

wenn dann jedenfalls ein szenenwechsel erkannt wurde, werden die frames vor & nach dem szenenwechsel mit den frames vom changefps() ersetzt.

"das Script mit 520 Zeilen benötigt 9 GB RAM."
wie haste den RAMbedarf ermittelt ?

Gegenvorschlag: MVTools2 – MFlowFPS()

Siehe Beispiele zu "double fps", und danach nur wieder AssumeFPS() mit der Original-Framerate.

Ja, beim Bobben von Videos (engl. "bob" ~ "nicken"; bei First-Person-Shootern auch das Auf- und Abbewegen der Kamera als Simulation des Laufens über die Beine) hat man leichtes "Flackern", weil ja immer jeweils die andere der beiden Zeilen eines Paares interpoliert wird. Didée hatte mal was von einem Ausgleich mit Hilfe einer Subpixel-Verschiebung geschrieben...

Im Falle von Interlaced-Material, das zu exakt halb so schnell spielendem Progressiv-Video konvertiert werden soll, wäre vermutlich eine der besten Lösungen:

source.QTGMC(...).AssumeFPS(source.FrameRateNumerator, source.FrameRateDenominator)

Völlig fehlerfrei sind Algorithmen mit Bewegungsschätzung eigentlich nie, selbst wenn man sie erst mal zumindest technisch korrekt verwendet; vielleicht lassen sich die Parameter für MSuper und MAnalyse noch etwas tweaken, um das zu vermeiden. Aber das weiß wohl jemand mit mehr praktischer Erfahrung besser als ich.

Das hier produziert recht gute Ergebnisse:

# double FPS (Smart)
LoadPlugin("c:\Program Files (x86)\SVP\Plugins\svpflow1.dll")
LoadPlugin("c:\Program Files (x86)\SVP\Plugins\svpflow2.dll")
super=SVSuper("{gpu:1}")
vectors=SVAnalyse(super, "{}")
SVSmoothFps(super, vectors, "{}", url="www.svp-team.com", mt=8)






# decimate back to 30
LoadPlugin("C:\Programme\AviSynth\plugins.manual\FDecimate.dll")
#FDecimate(metrics=true)
FDecimate(rate=30,threshold=3.85, protect=false)

den threshold beim FDecimate() musst du an dein Video anpassen. Dafür benutzt du die Zeile darüber und sternst die letzte Zeile erstmal aus. Näheres dazu findest du auf der Homepage von Donald (http://neuron2.net/fdecimate/fdecimate.html).

Die SVSuper-Plugins zum laufen kriegen war, soweit ich mich erinnern kann, pain-in-the-ass, aber wie gesagt, gibt schön smooth extrapolierte Frames und garnichtmal soviele Bildfehler.

Ach nee, da gibt's mal was interessantes neues, und das erfährt man nur so nebenbei... :hm:

Dabei meine ich insbesondere die auf GPU-Unterstützung gepatchte MVTools2-Variante, die allein damit schon Geschwindigkeitsvorteile bringen kann, unabhängig von der zusätzlichen Funktion MSmoothFps.

Das einzige, was mir noch etwas Kopfzerbrechen bereitet, ist der Parameter "url" in SVSmoothFPS aus der SVPflow.dll. Sieht irgendwie nach "Schutz geistigen Eigentums" aus, aber die Auswirkungen sind nicht dokumentiert...

Wobei die mvtools2 Variante wohl vermutlich Probleme mit den neueren Avisynth 2.6 Versionen machen wird, gab dafür ja extra ne neuere mvtools2 Version,...
+ "Their outputs is exactly the same but GPU output can be a little less sharp. " da hat jemand eine andere Vorstellung von 'outputs is exactly the same' als ich, wenn die Ausgabe dann doch unterschiedlich scharf ist.

Zitat von LigH

Das einzige, was mir noch etwas Kopfzerbrechen bereitet, ist der Parameter "url" in SVSmoothFPS aus der SVPflow.dll. Sieht irgendwie nach "Schutz geistigen Eigentums" aus, aber die Auswirkungen sind nicht dokumentiert...

Meinst du die technischen oder rechtlichen Auswirkungen?

Technisch ists einfach ... fehlt der Parameter oder trägt man da was anderes ein, funktioniert die dll's nicht mehr.
Rechtlich hab ich nix gefunden, außer das die jungs sich wohl damit von ???vorgängerversion??? abeheben wollen. Warum auch nicht ... ist auch gut gelungen finde ich.

Zitat von Selur

Wobei die mvtools2 Variante wohl vermutlich Probleme mit den neueren Avisynth 2.6 Versionen machen wird

Gute Frage ... ich hab die SVP-Version draufgehauen, noch irgendeine DLL ins system32 kopieren müssen und dann lief es. Dafür liefen dann 'ne ganze Menge anderer Sachen instabil, also hab ich die 2.5er wieder drübergebügelt und jetzt läuft bei mir beides.

Soweit ich das gesehen habe, rauchen die Plugins ab, sobald von der Grafikkarte mehr Speicher gezogen wird, als diese onboard hat ... ich hab in meinem Lappi 1 GB drauf und sobald ich da nahe rankomme (größer 900irgendwas MB) gibts ne Schutzverletzung.