Habe im Anhang mal ein Sample geladen.
Meine Analyse der Einzelbilder ergibt nach meinen bescheidenen Kenntnissen:
Original war mal 29,97 fps und wurde nach 25 fps gewandelt, dadurch fehlt das jeweils sechste Bild, was zu den Rucklern führt.
Liege ich damit richtig?
Kann man das beheben?
Habe eben mal restore24, srestore getestet, sind aber wahrscheinlich nicht die richtigen Filter.
Ich schätze mal, das wird die richtige Erklärung für das Problem sein... zum "Reparieren" (zu 30 fps) wirst du wohl am besten in den MVTools stöbern, ob man regelmäßig aller 5 Bilder 1 Bild interpolieren lassen kann. Ist ja mehr oder weniger mit IVTC vergleichbar, nur ohne Field-Separierung.
Ein ganz ähnliches Problem hatte ich auch schon mal ... 29.97p Input, der fälschlicherweise zu 23.976p IVTC'ed worden war.
Am Ende der Anstrengung war ein korrektes Script, das theoretisch sehr gut funktioniert hätte. Ist aber daran gescheitert, dass TDecimate() Murks gebaut hat. Von 40min Input war nur die 1. Minute OK (perfekt flüssig), im ganzen Rest hat TDecimate Phasen-verschoben dezimiert => Müll.
An dem Punkt hab ich abgebrochen und die Sache nicht weiterverfolgt.
Handarbeit? Manuelles Suchen? Nein, *eigentlich* braucht's das nicht ...
Das grundsätzliche Problem ist, dass die Verteilung der fehlenden Frames nicht absolut regelmäßig ist, wie Du inzwischen auch schon gemerkt hast. (Wegen 1000/1001, wegen Entscheidungen des Dezimierers, usw.)
Deswegen kann man nicht einfach stur nach jedem x-ten Frame einen Ersatzframe einfügen, sondern es braucht eine Erkennungs-Routine.
In meinem Fall hatte ich über eine LumaDifference-Routine eine Erkennung gebastelt, die zu >99.5% die richtigen Stellen erkannt hat. Dann: die 23.97fps auf 2*23.976 gedoppelt, und anhand der Erkennungsroutine in diesem 47.952fps-Stream die entsprechenden Dups durch MVFlow-Interpolationen ersetzt; schließlich das ganze von TDecimate auf 29.97fps dezimieren lassen.
Script und Methode waren *korrekt*, es hätte das gewünschte Ergebnis herauskomen müssen. Leider war, wie gesagt, nur die erste Minute brauchbar, die restlichen 39 Minuten waren Schrott. Da die Erkennungs- und Dup-Ersetzungs-Routinen definitiv richtig gearbeitet haben, kann der Fehler nur bei TDecimate glegen haben. (War nicht das erste Mal, vergleichbare Probleme gibt's auch mit TDecimate in Restore24. Für mich war's deswegen ein "Aha, TDecimate!" - Effekt...)
Ergo: man könnte das Problem durchaus automatisiert lösen. Zumindest ich bring's aber nicht hin, wenn nicht alle Tools verlässlich so arbeiten, wie es zu erwarten wäre.
Nachtrag: die LumaDifference-Methode würde bei Deinen Billard-Videos vermutlich nicht so gut funktionieren. Meine Quelle war ein Sport-Video mit hinreichend viel Bewegung, da ging die Erkennung sehr schön. Beim Billard sieht's anders aus: da ist fast alles statisch, und die Unterschiede durch die bewegten Bälle sind eher klein. Da würde LumaDiff wahrscheinlich nicht ausreichen, und man müsste vrmtl. stattdessen die Länge der Bewegungsvektoren auswerten. Das ist deutlich kniffliger!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
