Suche zwei Funktionen

Also wenn schon solche Skripte, denn doch gleich alles in einem Durchgang. Da Punkt 1 und 2 sich nicht mit selectrange realisieren lassen, empfehle ich aber eine Funktion die einen bestimmten Bereich durcharbeitet (z.B. 1000 Frames) und anschließend ausgibt, was erkannt wurde.
Hab' übers Wochenende wieder kein Avisynth, aber vielleicht ja nächste Woche.;)

Ich philosophiere mal ... wenn man das Video in Fields trennt (einmal TFF, einmal BFF), und sich die Entwicklung der Differenzen zwischen ihnen (mit "geeigneten" Metriken) anschaut, dann würde man sicherlich recht typische Muster bemerken; über die automatische Auswertung dieser Werteentwicklungen mache ich mir da noch keinen Kopf, auch wenn ich mir schon ziemlich sicher bin, dass AviSynth alleine für die Auswertung nicht reichen dürfte. Es muss wohl ein Plugin in einer üblichen mächtigen Hochsprache werden. Neuronale Netze wären bestimmt nützlich.

Zitat von LigH

über die automatische Auswertung dieser Werteentwicklungen mache ich mir da noch keinen Kopf, auch wenn ich mir schon ziemlich sicher bin, dass AviSynth alleine für die Auswertung nicht reichen dürfte. Es muss wohl ein Plugin in einer üblichen mächtigen Hochsprache werden. Neuronale Netze wären bestimmt nützlich.

Also ich halte Avisynth für diese einfache Aufgabe mehr als ausreichend, kompliziert wird es erst mit welchselnder Fieldorder, aber davon wollen wir hier mal nicht ausgehen. Zur Fieldordererkennung wäre es grundsätzlich noch nicht einmal notwendig Bff und Tff miteinander zu vergleichen, ein Clip würde schon ausreichen, aber der Vergleich wäre natürlich sicherer.

Na wenn es gut funktioniert. Aber etwas einfach gehalten ist es schon. Es werden lediglich die Summen der Lumadifferenzen miteinander verglichen und keine Randbedingungen berücksichtigt.

So, ich hatte gestern etwas Zeit und hier ist das Resultat:

Funktion auf Seite 3

Die Funktion sollte eigentlich für die drei Aufgaben ausreichen. Sie bekommt drei Parameter, nämlich den zu untersuchenden Clip, "start" zur Festlegung des ersten zu untersuchenden Frames (Standard: 0) und "mthresh" um sicher zu gehen, dass die Erkennung nur in bewegenden Szenen erfolgt (Standard: 3.0).
Die Funktion legt sechs globale Variablen fest (ich hoffe du kannst sie nutzen, ansonsten wäre auch eine Logdatei möglich).
progressive - zählt progressive Frames
interlaced - zählt die interlaced Frames
telecined - alles was tfm sonst noch so matched
Die Summe aller drei Werte ergibt die Gesamtzahl der untersuchten Frames (Framedifferenzen kleiner mthresh werden nicht untersucht).
tffcount/bffcount - zählen alle Frames die als tff/bff erkannt werden
Dabei werden jedoch nur Frames bei denen es eindeutig scheint verwendet.
real_interlaced - ist eine Untermenge von "interlaced" und zählt nur die Bewegungen, die so flüssig sind, dass man von tatsächlich interlacten Material ausgehen kann

Zur Auswertung:
Normales Interlacing - wenn real_interlaced größer 70% von Summe aller untersuchten Frames
NTSC pulldown - wenn NTSC und interlaced kleiner 5% und telecined größer eindrittel und kleiner zweidrittel von progressive
Progressive - wenn interlaced kleiner 1% und progressive größer 95%
-> ansonsten irgendein anderer Murks

Gedacht ist es so, dass bei genügender Anzahl untersuchter Frames der Durchlauf abgebrochen wird und die Ergebnisse zur Erkennung genutzt werden können.
Aufgrund der Einfachheit der Funktion gibt es allerdings ein paar Beschränkungen.
1. Sie arbeitet nicht mit Graustufenbildern und nur in yuv
2. Bob ist schnell, aber andere Filter könnten genauere Ergebnisse liefern (ich halte es trotzdem für ausreichend)
3. Die Einstellungen von tfm sind für diesen Gebrauch sicher nicht ganz optimal (die richtige Auswertung der Werte sollte trotzdem ausreichen)

Na, denn hoffe ich mal, dass sie für dich nützlich ist.;)

ich habe mich schon (erfolglos) an einer zuverlässigen 24p, 30, 60i erkennungsroutine probiert. wenn das pattern stabil ist, geht das einigermaßen. Ausserdem muss man festlegen, wie statische szenen, oder solche mit wenig bewegeung erkannt werden: interlaced oder progressive?
ich bevorzuge interlaced, denn bei statischen szenen tut ein deinterlacer nicht weh, mouth-combing aber sehr wohl.
weiterhin habe ich es nicht in den griff bekommen, modiwechsel (zwischen 24p, 30p und 60i) sauber zu schalten, ohne dass es zum vor-rück springen an der schaltstelle kommt.
Das script ist jetzt schon abartige 500 Zeilen lang.

scharfis_brain
Das kann ich mir gut vorstellen.:D Aber mit hybriden Quellen möchte ich mich gar nicht erst rumplagen, die werden zufrieden gelassen. Bei statischen Szenen bevorzuge ich progressive Behandlung. Mit yv12lutxy kann man auch sehr geringe Bewegungen wie mouthmoving noch von tatsächlich statischen Szenen unterscheiden.

incredible
Hab die Funktion leicht verändert. Sie gibt jetzt eine Logdatei aus, deren Pfad mit dem Parameter "file" verändert werden kann. Start(0) und end(5000) stehen für die Range von Frames die untersucht werden soll und every(17) gibt einen Dezimierungsfaktor vor. Es werden also (end-start)/every Frames zur Erkennung herangezogen und davon wiederum nur die Framedifferenzen verwendet die über mthresh(3.0) liegen. Aufgrund üblicher Patternlängen sollte man es dringed vermeiden every als Teiler (Ausnahme 1) oder Vielfaches von fünf und sechs zu setzen, deshalb auch diese schöne Zahl 17.

Funktion auf Seite 3

Ja, ich weiß woran das liegt. Die writeif-bedingung wird meistens nicht erfüllt. Bei mir wurde die log trotzdem immer mit den Werten erstellt sobald der Durchlauf beendet war, deshalb habe ich es nicht geändert. Sonst wurde der Inhalt immer zweimal in die Datei geschrieben, keine Ahnung weshalb.

deci = default(every,17)...c99=WriteFileIf(source, output, "current_frame==stop", ...

->

global deci = default(every,17)
...
c99=WriteFileIf(source, output, "current_frame>=stop-deci", ...

Diese Änderung sollte eine erfüllbare Bedingung bringen. Ich kann es im Moment aber nicht testen. Ansonsten kann man zu Testzwecken ja eine immerwahre Bedingung wählen. Weshalb bei mir am Ende des Durchlauf aber die Log automatisch mit den Werten befüllt wird und bei dir nicht, da habe ich absolut keine Ahnung.

Edit: Ich habe writefile leider auch nicht dazu bewegen können die Logdatei immer mit den aktuellen Werten zu überschreiben. Egal welche Einstellungen, ohne writefileif wurde jede Veränderung in einer neuen Zeile festgehalten.

incredible
Bei mir hat jetzt auch wieder alles normal gearbeitet. Es wurde aufgrund der Bedingung nichts in die Log geschrieben. Die schon angesprochene Änderung behebt dieses Fehlverhalten. Ich habe die Funktion editiert.
Die Pulldownerkennung ist grundsätzlich möglich. Um eine sichere Erkennung zu gewährleisten müsste man allerdings jedes Frame bzw. mehrere patternlange (also 5 Frames) Abschnitte untersuchen. Wenn wir eine NTSC-Quelle haben, und interlaced unter 2% und der telecined und fieldshifted Anteil etwa 3:2 verteilt ist (2:2 und sogar 2:3 sind auch möglich, wenn auch unwahrscheinlich, da sich tfm bei 1 von 5 Frames für c- oder p-match entscheiden kann), denn ist die Wahrscheinlichkeit für NTSC-Pulldown wirklich sehr hoch.
Wenn du das allerdings für nicht ausreichend hälst, ist eine separate Pulldownerkennung natürlich machbar.;)

Edit:
Wegen dem Graustufenproblem, da werde ich mal testen, ob sich doch noch was anderes finden lässt. Tfm kommt mit vielen Funktionen nicht so gut klar. Das Problem tritt auch nur auf, wenn AverageChromaU tatsächlich 128,0 ist. Das hat sich bei Tests kurzer Graustufenbereiche bis jetzt jedoch nicht gezeigt. Aber bei tatsächlich graustufenencodierten Material (kann man ja zum Beispiel für Abspann usw. einstellen) kommt es zur Fehlerkennungen.

Funktion auf Seite 3

Hier ist meine überarbeitete Funktion. Die Interlacingerkennung arbeitet jetzt auch mit Graustufenbildern. Zudem ist auch ein Parameter dazu gekommen. "INF" steht für die Informationsausgabe, bei Null wird nichts extern ausgegeben, bei 1 wird deine Subtitleversion verwendet (etwas langsamer/nicht getestet) und sonst (standard) die log ausgegeben.
So, ich hoffe das wars vorerst, ich plage mich jetzt mit vfw rum.;)

Zitat von incredible

Ich habe noch die fehlenden String Globals zu der Subtitle-Ausgabe hinzugefügt, die hattest du noch vergessen

Nochmals vielen Dank!

Oops! Ja, ich habe einfach nur deine Subtitleversion reinkopiert und darauf irgendwie nicht geachtet.

Zitat von incredible

Ich habe festgestellt, dass SelectEvery(deci,0) doch mit selectrangeevery(deci,1) ausgetauscht werden könnte, habe es getestet, die Folge und die Framessind die gleichen, aber weitaus schneller.

Ich wusste nicht, dass selectrangeevery deutlich schneller ist. Danke für die Info.

Zitat von incredible

Zudem wollte ich gerne, dass ebenso der gesamte Stream mit gescannt werden kann, ohne dass nur jeder 17te Frame analysiert wird.
Jetzt die Frage: Via einem Deci*x kann ich die Anzahl der gesamten zu analysierenden Frames doch kürzen und die Pattern-Logik "17" bleibt erhalten? Habe es getestet und klappt anscheinend gut.
Selbst mit einem optionalen "LowPrec" Argument, dass die Source in ihrer Breite vor der Analyse auf die Hälfte reduziert funktioniert die Analyse auch noch sehr gut, ist aber mit Sicherheit nicht so akkurat.

Das stimmt leider nicht so ganz. Zum einen kannst du die every ja frei wählen und der Wert 17 ist absolut kein muss. Für deci*x besteht also keine Notwendigkeit. Der gewähle Dezimierungsfaktor darf einfach nicht die Teiler 2, 3 oder 5 haben. Sollte das nämlich der Fall sein, wird bei Pattern der Länge 5 (oder auch 5*5) oder 6 (->üblich Bsp: Pulldown, Normkonvertierung) nicht jeder Frame eines Patterns behandelt. Zwar werden bei der Zahl 17 nur wenige Frames genutzt, allerdings ist jedes neue Frame an einer anderen Position im jeweiligen Pattern. Also kann für every auch 7 oder 13 zum Beispiel gewählt werden (Primzahlen sind immer gut).

Zitat von incredible

Ich habe mal aus Spaß eine progr. PAL Source genommen und ein Pulldown angewendet.

assumefps(23.976).assumeframebased()
SeparateFields()
SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)
Weave()

... und sodann die Funktion drüber laufen lassen.
Also entweder habe ich was verpast oder ****wow***.
Demnach scheint das every=17 genau für die erkennung des eigentlichen progressiven Inhalts verantwortlich zu sein? Ist es das, was es mit der krummen "17" auf sich hat? Denn .... nach anwenden der Funktion auf den pulldowned Stream wurde komplett progressive angezeigt. Was ja auch stimmt.
Nur die Frage: Wie siehts denn da mit dem Offset beim Pattern in einem Pulldowned Stream aus? Habe nach dem Pulldown mal via einem Trim(2,0) einen offset simuliert und zumindest wird dann "fieldshifted" ausgegeben - Klasse.

Alles anzeigen

Das sollte eigentlich nicht der Fall sein. Ich habe es mit einer NTSC Hybrid Quelle getestet und die Erkennung lieferte das erwartete Ergebnis. Um sicher zu gehen, dass die Erkennung macht, was sie soll, kann man mit every=1 erstmal testen, ob alles funktioniert. Das Conditional Enviroment kann manchmal Probleme machen, wenn vorher ein selecteven(), selectevery() usw. angewendet wird. Also am besten Source vorher zwischenspeichern. Zur guten Erkennung müssen denn natürlich noch genug Frames bearbeitet werden und die Bewegungen dürfen nicht zu gering ausfallen. Mit trim(2,0) wird denn nur noch fieldshifted ausgegeben? Hast du bereits den Multiplikator verwendet? Einen "amount" Parameter, der zum Beispiel 1000 Frames gleichmäßig verteilt über die Source zur Erkennung heranzieht ohne in den Pattern zu fallen, kann ich gerne integrieren, every halte ich dann aber für unnötig.

Zitat von incredible

PS: Wenn ich dir ansonsten mit VFW etc. helfen kann, einfach klingeln.

Danke für das Angebot. Erstmal sehen wie weit ich es mit meinen Quellen schaffe. Gegebenfalls komme ich darauf zurück.;D

Edit:Hier ist gerade ein neues Tool erschienen, welches bestimmt sehr brauchbar für dich sein könnte, habe es allerding noch nicht getestet.