Wie müsste ein Typisches Scrypt (SetMTmode) usw. aussehen damit es läuft?
Gar nicht, bzw., vergiss es einfach.
Dieser "High-Resolution" Filter ist i.d.Praxis ziemlich nahe bei "Schlangenöl". 
Für Upscaling im Zweifelsfall einfach die NNEDI3.dll nehmen (Filter NNEDI3_rpow2() ), das funktioniert problemlos, und liefert mindestens genau so gute, in der Regel bessere Ergebnisse.
Mir ist es eigentlich wurscht, welcher Player oder welcher Renderer dieses oder jenes macht. Ich wüsste jetzt noch nicht mal auswendig, welche Renderer wie arbeiten (betreffs der YUV->RGB Konvertierung), und wo man aufpassen muss und wo nicht. Bei mir sind die Player so konfiguriert dass ffdshow zum dekodieren verwendet wird, die Ausgabe wird auf RGB erzwungen, und die Matrix-Ausgabe steht auf "Auto". Damit hab ich keine Probleme mit, äh, "Zufallsergebnissen", sondern es wird einfach immer "richtig" gemacht.
(VLC verwende ich sowieso nie ... hat der überhaupt schon mal irgendwas richtig gemacht?) 
Vielleicht kann hier einer von euch mal eure Hardware Player daraufhin testen. Würde mich ml interessieren ob da meiner die Ausnahme oder die Regel ist.
Das muss jemand anders machen, mein Hardware-Player IST der PC.
Im Zweifelsfall wäre es natürlich hilfreich, wenn die korrekten Matrix-Einstellungen und Color-Primaries bereits beim Encodieren auch in das Video hineingeschrieben würden. So ist es nämlich richtig, aber bei vielen Eigen-Encodings wird das typischerweise nicht gemacht. Sind die Transfer-Charakteristiken eingetragen, dann "weiß" der Player, wie es richtig ist. Sind sie nicht eingetragen, dann gibt es streng genommen kein richtig oder falsch ... es ist zwar naheliegend, dass HD-Quellen mit Rec.709 kodiert sind, und deswegen ist es günstig, dieses im Zweifelsfall einfach anzunehmen. Aber ein absolutes "Muss" ist das natürlich nicht. Wenn keine Transfercharakteristiken im Video drinstehen, dann ist der Zustand höchst offiziell "undefiniert".
Ich sehe in der Vorschau was ich Enkodiere und was ich auf allen Playern und geräten auch sehe.
Zurück auf Anfang: Wenn die Quelle HD/Rec.709 ist, dann ist das, was Du in der Vorschau siehst, bereits falsch.
Wenn Du also beim Playback das gleiche siehst wie in der Vorschau, dann konvertieren deine Player ebenfalls falsch.
Also mit dem VLC sind die beiden NICHT gleich. Bilder mit VLC erstellt.
Auch auf meinem Patriot Box Office player (Realtek) und Röhre sind die farben nicht gleich. Ebenfalls nicht mit VLC. Nicht mit MPC-HC und EVR-cp. Und nicht mit Staxrip.
Du lieferst selber die Bestätigung. Wenn ein Player sich "richtig" verhält, dann müssen die beiden Videos nämlich genau die gleiche Farbe zeigen. Zeigen sie hingegen unterschiedliche Farben, dann macht der Player es eben nicht richtig. (D.h. Rec.709 wird fälschlich mit Rec.601 Matrix zu RGB konvertiert.)
Große Philosophie: Ist das Quellmaterial Murks, [dann] ist das Quellmaterial Murks.
imagesource("batb_ivtc.tif")
converttoyv12()
[B]separatefields().vinverse().weave().vinverse()[/B][Blocked Image: http://thumbnails104.imagebam.com/27961/2a7d5e279609486.jpg]
Dass man vinverse erst auf die separierten Felder anzuwenden hat ist zwar nicht der Normalfall, aber bei manchem Quellmaterial ist es nun mal so, dass "2 Pixel hohe" Streifen nach dem IVTC drin sind. Warum auch immer, aber die Frage ist müßig ... wenn es in einem Fall so ist, dann ist es eben so.
Zeig' doch bitte noch ein Beispiel, wie diese 'Linien' im Endergebnis genau aussehen. Nach IVTC kann durchaus ein rest-Aliasing übrigbleiben, in dem Fall ist es oft gut, wenn man etwa den Vinverse()-Filter dem IVTC hinterherschießt.
Inhalt des avs-Scripts bitte auch posten, nur um sicher zu sein, dass nichts anderes versehentlich übersehen wird.
und festgestellt das bei "sehr starkem Rauschen" Blocking Artefakte entstehen. Also besser da nicht verwenden
Overlap auf halbe Blockgröße setzen, dann gibt's auch keine Blockartefakte. Und bei "sehr starkem" Rauschen die Blockgröße auf 16, Default 8 ist zu klein. (Bei HD wäre evtl. sogar Blockgröße 32 angebracht, aber das ist leider etwas buggy.) - Einerlei, bei wirklich "sehr starkem" Rauschen muss man im allgemeinen einen Pre-Filter für die Bewegungssuche anzuwenden. Sonst sucht die Engine mehr nach der Bewegung des Rauschens anstatt der Bewegung von Objekten, und die Block-SADs gehen auch durch die Decke, was die Beurteilung zwischen "guter" und "schlechter" Kompensation sehr ungünstig verschleiert.
Ja, nur das Avisynth MT alles andere als stabil läuft (bei mir - Win7 63bit).
Hmja ... dass das unter 63bit nicht stabil läuft, das ist durchaus denkbar. :zunge:
Ich meine: wenn ich nicht einen Zwischenzustand zwischen Frame A und Frame B erzeugen will, sondern einfach nur Frame A auf Frame B bewegungskompensieren will, dann nehme ich nicht MFlow, sondern MCompensate.
Überhaupt würde ich vrmtl. hergehen, einen kompensierten temporal-Median nehmen, spatial punktmuster aussieben. DeSpot hat mir zuviele Parameter, das ist zu kompliziert für mich.:) - Bis ich da ausprobiert und verstanden habe was wie arbeitet und welche Auswirkungen hat, wäre ich mit der zu-Fuß-Lösung wahrscheinlich schneller fertig.
Wieso eigentlich Motion-Tresholds, wenn doch sowieso schon Motion"compensation" durchgeführt wurde ...
Wieso eigentlich MFlow, wenn man doch eine Kompensation haben will, und keine Interpolation ...
Nö, das passt schon, wenn der Input bereits 50p ist. Man könnte erwägen, ob man vor dem Interlacing noch einen vertikalen Lowpass-Filter setzt (wg. Zeilenflimmern etc.), aber bobben oder um-eine-halbe-Zeile-erschieben muss man bei 50p Input ganz sicher nicht.
Ich ergänze mal frisch von der Leber weg:
Diese MP4's sind auch bei bewegten Objekten von guter Qualität. und werden auf einem PC-Monitor angeschaut
eine Video-DVD erstellt....
Die erzeugten Videos zeigen aber leichte Bewegungsunschärfen. wenn sie auf einem LCD-Fernseher angeschaut werden
Falls ich mich täuschen sollte: einfach drauflos schimpfen. 
Gute Frage ... weiß gar nimmer, ob ich die Variante mit verkettetem Aufruf und stdout.wav auch probiert hatte. Weil, wenn man nach 2 Stunden nur 10 BSODs auf der Rechnung hat, aber immer noch kein Ergebnis, dann drehste nur noch am Rad, und wünscht Dir HeadAC3He zurück ...
Komplett manuell über WAV hab ich auch nicht hingekriegt, soviel weiß ich noch. Falsche Bittiefe / falsche Endian-ness (keine Ahnung, das Ergebnis war BZZZZRRSCHSCHSCHRRRSCHSCHSCH), zu kurzes Ergebnis ohne -ignorelength, zu langes Ergebnis mit -ignorelength ... das waren zwei weitere Stunden ohne ein Ergebnis, und dann war ich an dem Punkt "LECK MICH AM AAAAAAA..."
==> "dann drehste nur noch am Rad, und wünscht Dir HeadAC3He zurück ..."
Inzwischen hab ich die Faxen dicke, reiß' den Kram mit --no2ndpass 'runter (schei** auf die paar Clippings), und zerbrech mir den Kopf stattdessen über andere Sachen.
Bleibt nur, von eac3to auf einen externen Encoder zu pipen, sei es NeroAacEnc, Fraunhofer oder qaac...
Das macht er ja schon. eac3to piped die Daten zu NeroAACenc.
Kann es sein, das NeroAACEnc probleme hat Dateien > 2GB zu schreiben? (Hab noch nie versucht so eine großes File zu erstellen)
Da ist der Murks schon längst passiert, die erstellte aac würde mit q 0.3 sowieso niemals so groß werden. Die Logs "Processed XXX seconds" tauchen erst auf, nachdem der Encoder sich festgefressen hat.
____
Ich kenn' das Problem, steh' aber auch völlig ratlos auf dem Schlauch.
Was mir aufgefallen ist:
- sehr, sehr häufig bei AC3-Audio
- einigermaßen häufig bei DTS, wenn 2-pass Normalisierung verwendet wird
- sehr selten (bei DTS), wenn keine 2-pass Normalisierung verwendet wird [--no2ndpass]
Außerdem:
- Mit der älteren v3.24 von eac3to hatte ich es, wenn, dann immer nur mit Fehlermeldungen/Abbrüchen zu tun.
- Bei v0.26/0.27 gibt es mit Glück eine Fehlermeldung ... desöfteren schmiert die Kiste aber auch komplett mit BSOD ab. :mad:
Letztlich kann Dir die Entscheidung niemand abnehmen, zu irgend etwas musst Du Dich durchringen.
Einfaches Frameskipping würde ich nach Möglichkeit auf jeden Fall vermeiden - bei Kameraschwenks mittlerer Geschwindigkeit sieht man die Skips fast immer. Nicht schön.
Sobald man MVTolls-Tralala dazunimmt, müsste/sollte man sich auch gleich um das Problem der Scenechanges kümmern und kontrollieren, dass die auch wirklich gut erwischt werden.
Wie gesagt - solange nichts anderes ausdrücklich dagegen spricht, Methode b). Macht am wenigsten Arbeit, und es kann am wenigsten schief laufen.
Solange Audio-mäßig nichts gegen ein reencoding spricht, würde ich Methode b. eindeutig für am schmerzfreiesten befinden.
Sollte ein strobing-judder Problem störend bemerkbar werden (weil 1/50s belichtete Frames als 24p dagestellt werden), dann könnte man den fehlenden Motionblur per MVTools-Interpolation dazurechnen. (Würde ich aber ebenfalls auf Basis eines 25>24 Slowdowns machen [wenn ok mit Audio], weil weniger Probleme mit Artefakten.)
Eine laufzeitidentische Umrechnung würde ich nur machen, wenn Audio der hauptkritische Bestandteil ist (Musikvideo, Konzert, o.ä.)
Der ursprüngliche Ansatz ist okay ... bis auf zwei Dinge:
- Threshold=0 für Ydifference ist i.d.Praxis vermutlich zu klein, bei Mpeg2-Codierung sind die Dup-Frames vermutlich nicht völlig identisch. Überprüfen und den Threshold ggf. etwas größer wählen.
- Es ist keine so tolle Idee, den Komplex aus SuperClip-Erstellung + Bewegungssuche innerhalb des Conditionalfilter anzulegen. Die komplette Conditional-Environment wird doch irgendwie bei jedem Frame neu initalisiert.
Besser ist's, den Clip mit neu-errechneten Frames komplett extern außerhalb der Conditional-Enironment zu erstellen, und dann im ConditionalFilter eben nur noch darauf zuzugreifen.
In etwa
mpeg2source("vts_01_1.d2v")
o = last
flowed = interleave( o.selecteven().fflow(),
\ o.selectodd() .fflow() ).selectevery(4,-1,2)
ConditionalFilter(o, o, flowed, "YDifferenceFromPrevious()", "greaterthan", "0.12345", true)
return(last)
#--------------------------
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(last) }Die MVTools-Parameter in der "fflow()" -Deklarierung dürfen natürlich nach belieben erweitert & verfeinert werden.
Interessant. Das ist ein Fall, in dem sich gar nichts tun lässt. Besonders deutlich zu sehen bei zB. Sekunde 8~9 : jedes Bild ist ein Blend mit dem Nachfolger ... AB BC CD DE EF usw.
Klappe zu, Affe tot, Fall geschlossen.
Nur was ist das wenn solche Blends praktisch in (fast) jedem Bild vorkommen ?
Na, ... Wenn Blends in fast jedem Bild vorkommen, dann ist das etwas völlig anderes als
Quote from may24Blends tauchen nach folgendem Muster auf:
p p p b b p p p b b p p p b b ...
Bei Normkonvertierungen gibt noch den Fall, dass eine "gleitende" Framrate-Conversion à la "ConvertFPS()" gemacht wurde - für diesen Fall ist "RestoreFPS" (von mg262 / Clouded) vorgesehen, das kann oftmals die Sache zurückrechnen, mit ein wenig manuellem Try-and-error.
Die Frage ist, in jedem Fall aufs Neue, wie bzw. warum Blendings da sind. Lösungen gibt es viele, aber man muss halt zusehen, dass man auch die Lösung erwischt, die zum aktuellen Problem passt.
- (Und da kann's einem gehen wie beim Pilzesammeln: Die Unterscheidung zwischen einem rötlichen Bläuling und einem bläulichen Rötling ist nicht immer einfach.)
Dieses Pattern tritt auf, wenn ein 30i Video mit 3:2 Pulldown fälschlich "deinterlaced" wurde (Verschmelzung von Top- und Bottom-Fields)
FixBlendIVTC()
TDecimate()
oder
Srestore(omode="pp3")
TDecimate()
TDeint mit Parameter "tryweave"?
würde mal vermuten, dass Merge auch mit drei Clip-Parametern überfordert sein könnte; gibt es da keine Fehlermeldung,
Du hast recht, stimmt, das müsste sowieso eine Fehlermeldung geben. War mir nicht aufgefallen - glaube mein Hirn ist gerade am verdunsten, es ist ZU WARM.
