Beiträge von Didée

In Hinsicht auf "Blassheit" macht es aber nun gar keinen Unterschied, ob ein Video mit MDegrain oder mit QTGMC gefiltert wird. Entweder die Videolevels stimmen, oder sie stimmen nicht. Das ist völlig unabhängig vom (Rausch-) Filter.

Vielleicht meint "blass" aber gar nicht die Farben/Helligkeit, sondern den Detailgrad des Ergebnisses? Je nach Quelle kann es schon passieren, dass das Ergebnis von Mdegrain irgendwie "leer" wirkt. Ist vor allem dann der Fall, wenn das Quellmaterial nur wenig-bis-garkein echtes fein-Detail enthalten hat ... so manches Quellmaterial "lebt" überhaupt nur vom enthaltenen Rauschen und Artefakten. Entfernt man Rauschen und Artefakte, dann sieht man, dass da eben "nichts" mehr ist ....

Wenn ss_x/ss_y nicht ausdrücklich angegeben werden, dann gelten die Default-Werte. Und Default ist mit Supersampling.

Sehe gerade, die Vorgabewerte für 'preset="new" verwenden nur 1.25*1.25 Supersampling, nicht 1.5*1.5. Macht aber trotzdem um einiges langsamer. Oh, und mit diesem Preset hat LSFMod auch noch "Soothe" implementiert und aktiviert. Ooh, das macht auch langsam - besonders in diesem Fall hier, weil damit ein weiterer Zeit-Filter (TemporalSoften) auf das Vorgängerergebnis von einer MVTools-Anwendung (MDegrain, oder auch QTGMC - bei dem natürlich erst recht!) angewendet wird. Eine Verkettung von Zeit-Filtern treibt die Komplexität schnell nach oben, das kann leicht ins Auge gehen. Gerade bei QTGMC, weil der intern sowieso schon eine zweifache zeitliche Staffelung verwendet - wenn dann Soothe noch eine dritte Komplexitätsebene dazubaut, o-ooh ...

Natürlich geht das einfacher und schneller. GrainFactory3 ist relativ komplex, weil es drei verschiedene Layer von Grain-Korngröße und Grain-Stärke generiert, und dann abhängig der lokalen Helligkeit zusammenkopiert. (War in dieser Form auch gar nicht meine Idee, das Script ist eigentlich "auf Wunsch" eines anderen Users so entstanden.)

Andererseits: sooo langsam ist das Ding nun auch wieder nicht. GrainFactory alleine, so wie in der verlinkten Seite benutzt, läuft bei mir (i7-860 -- uuur-alte Technik;)) auf einem 1920x800 Video mit ca. 85fps. Also, so furchtbar ist das nicht, da gibt's schlimmeres.

Wenn ich mir anschaue was der dort noch so alles in seinen Scripten drin hat:

- NNEDI2

- MDegrain2

- LSFMod

dann bin ich mir nicht so sicher, ob wirklich GrainFactory der Schuldige, bzw. der alleinige Schuldige ist. Kann natürlich sein dass ohne GrainFactory die Gesamt-Komplexität des Scriptes noch gerade~so im Rahmen ist, und GF3 dann der Tropfen ist der das Fass überlaufen lässt. Wäre schon möglich.

Übrigens ruft der Knabe LSFMod mit Supersampling auf. Auf einem Material das vorher bereits hochskaliert worden ist. Das ist einerseits rein Filter-technisch nicht unbedingt clever, und vor allem ist das andererseits für sich alleine schon ordentlich langsam. Wenn die Quelle bereits 720p oder gar 1080p ist, dann sollte man sich gut überlegen, ob man das (1.5)² Supersampling wirklich braucht.

Okay, bei gemischten allgemeinen Inhalten ist Verlangsamen natürlich keine so gute Option. Hab' halt nur das Sample gesehen und dachte, in dem Fall könnte man das so machen.

Grundsätzlich kann man mit Avisynth so ziemlich alles machen. Aber man wird in den meisten Fällen schon recht viel manuell eingreifen müssen. Ein Script, wo man oben was-auch-immer 'reinstopft, und unten kommt dann "mach-mir-das-bestmögliche-für-dieses-Videomaterial" heraus, das wird sich ~so~ wohl kaum realisieren lassen.

> NTSC in PAL (Framerate, Auflösung)
Beste Ergebnisse sicherlich über MVTools, wie LigH schon vorgeschlagen hatte. Bei Ziel DVD geht's schneller, wenn man das auf der kleinen PAL-Auflösung durchführt, nicht auf der Full-HD-Auflösung. Allerdings lassen sich dabei gelegentliche Artefakte nicht ganz vermeiden. Zwischenbildberechnung ist schwierig, und es gibt Bildsituationen die quasi unmöglich korrekt zu lösen sind.
Die einfachere Variante - Pulldown bzw. 50 Frames aus den 60 selektieren -- ist einfach, schnell, gibt keine Artefakte, und ist immer ruckelig.

> Angabe eines Bereiches, Start/Ende min/s oder frame
Dafür gibt's den Trim()-Befehl. Ist ganz einfach. - ... außer wenn die Audiospur mitgeschnitten werden soll (und das soll sie natürlich). Dann muss man zusätzlich zum Video auch die Audiospur in Avisynth 'reinbringen. Technisch auch kein großes Problem, aber oft unhandlich. Irgendwie endet man oft damit, die Audiospur mindestens ein-, gerne auch zweimal als unkomprimiertes WAV zwischenspeichern zu müssen ...

> Korrektur von Helligkeit/Kontrast/Gamma/Farbkurven/autokorrektur
Auch alles möglich. Mit Levels() kann man Helligkeit/Kontrast/Gamma direkt mit einem einzigen Befehl anpassen. Wenn's einzelne Farbkurven sein sollen (RGB) geht das auch, entweder man zerlegt es selber in die Kanäle, bearbeitet sie und fügt sie wieder zusammen, oder evtl. gibt's da auch spezielle Plugins für. Weiß gerade nicht, arbeite eher selten in RGB.
Autokorrektur gibt es ... äh, nicht wirklich. Es gibt wohl einen Filter der automatisch die Quelle auf das maximale Spektrum aufspreizt und auch einen automatischen Weißabgleich machen kann ... aber ich glaube, so richtig prall ist das Ding nicht.

> Erhöhung der Lautstärke
Hat man die Audiospur in Avisynth geladen, dann ebenfalls kein Problem. Die Frage ist eher, will man Audio wirklich in Avisynth verarbeiten. (siehe oben)

> Und wenn ich das richtig verstanden habe: Bei 720p 25p und bei 1080i 50i
Nimmt die Kamera in 720p nur 720p30 auf? Dann ja. Wenn auch 720p60, dann genauso --> 50i.

Wie gesagt: gehen tut so ziemlich alles. Aber Avisynth ist nun mal eine Scriptsprache, keine Klicki-Bunt-Anwendung. Von daher ist's vermutlich nicht ganz so komfortabel, wie man das als normaler "Mausschubser" gerne hätte. (Gar nicht böse gemeint, bin selber auch ein Mausschubser.);)

Huii, viel Text hier in dem Thread. Bin mir nicht ganz sicher, welche Baustellen hier offen, dringend, weniger dringend oder geschlossen sind ... ?

Geht es bei den Videosequenzen eigentlich immer um diese Art von Natur-Aufnahmen? Weil, mir kam die blöde Idee, dass man diese Art von Material eventuell ganz einfach von 60/s auf 50/s verlangsamen könnte. Wäre viel einfacher, und man würde sich auch keine Artefakte durch Bewegungsinterpolation einfangen.

Andereseits: Bei dem Sample hatte ich - besonders beim ersten mal Anschauen - ein echtes optisches Problem, wegen dem schlimmen Gezittere. Kommt wohl daher dass ein ziemlich starker Zoom verwendet wurde?
Man könnte hier versuchen, eine nachträgliche Stabilisierung durchzuführen - DePan wäre wohl das Mittel der Wahl. Oder DeShaker, den hab ich aber noch nie probiert.

Hab's mal versucht: Depan-Stabilisierung des Samples.

Bin mir selber nicht sicher, ob ich das 100%ig richtig/optimal gemacht habe, kann sein dass das noch etwas besser ginge. Man sieht im direkten Vergleich ziemlich deutlich dass es sehr viel ruhiger ist ... sind aber auch ein paar Stellen dabei wo kleine "Sprünge" drin sind, weiß nicht ob das Stellen sind wo Depan zwischen "ich-mach-was" und "ich-mach-nix" gewechselt hat. Bin leider auch kein Spezialist für Depan-Stabilisierung, da wird vielleicht einmal im Jahr ein Script zusammengewurstelt...

Hab' den speziellen Fall zwar noch nicht ausprobiert, denke aber mal, dass eine [Frame]-[Dup]-[Frame]-[Dup]-... Struktur generell eher ungünstig für den Kompressor ist. Auch für AVC, und für Mpeg-2 sowieso. Der Kompressor ist hin-und-her gerissen ... die Dups lassen sich sehr effizient als P-Frames über Skip-Funktionen komprimieren. Aber, wenn man das so macht, dann passen irgendwie keine B-Frames mehr in die Struktur hinein. Hat Mpeg-2 überhaupt die Möglichkeit auf Skip-Blocks in B-Frames? AVC mit Pyramid kann/könnte ja P-P'-B-B'-P-P'-... machen (mit ' = Skip, auch bei B-Frames wegen B->B Referenz durch Pyramid). Vermute mal bei Mpeg2 geht das nicht ...

Mit der Verschmelzung von Frames aus [25p-in-50p] wäre ich auch ein wenig vorsichtig. Sicher, generell schon eine gute Idee (wobei allerdings auch zu prüfen wäre ob's praktisch überhaupt was nennenswertes bringt). Aber: kann man sich überhaupt darauf verlassen, dass der Sender wirklich immer eine 100%ig korrekte 2-2-2-2 Struktur liefert? Wenn das Muster ein Mal aus dem Tritt kommt, weil, aus-welchen-Gründen-auch-immer, irgendein Frame nur 1mal, oder 3mal vorkommt, dann würde man ab diesem Punkt eine Verschmelzung von 2 verschiedenen Frames produzieren. Ich wär' da zumindest misstrauisch, und würde mich genötigt sehen, den Stream komplett von vorne bis hinten manuell zu kontrollieren, ob da auch wirklich nirgendwo etwas aus dem Ruder läuft.

Probier mal

Telecide()
SetPlanarLegacyAlignment(true)

Irgendwo im Telecide-Code stecken noch alte, nicht mehr gültige Annahmen über Chroma-Pitch usw. Siehe hier.

Wenn man eh' schon MDegrain verwendet, dann ist gerne auch vor-Schärfen interessant, anstelle von hinterher-Schärfen.

avisource("D:\__DL\MVI_2948_sample.avi",audio=false)
o=last


rg11 = o.removegrain(11)
pre  = rg11.temporalsoften(2,12,12,24,2)
shrp = mt_lutxy(o,rg11,"x x y - abs 6 / 1 1.6 / ^ 6 * 1.6 * x y - x y - abs 0.6 + / * +",U=2,V=2)


sup1 = pre.msuper(sharp=0)
sup2 = shrp.msuper(sharp=1,levels=1)


blocksize = 8 # 16   #  16 ist deutlich schneller, aber nicht viel schlechter


bv3  = sup1.manalyse(isb=true, delta=3,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)
bv2  = sup1.manalyse(isb=true, delta=2,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)
bv1  = sup1.manalyse(isb=true, delta=1,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)
fv1  = sup1.manalyse(isb=false,delta=1,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)
fv2  = sup1.manalyse(isb=false,delta=2,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)
fv3  = sup1.manalyse(isb=false,delta=3,blksize=blocksize,overlap=blocksize/2,dct=5,search=5)


#rg11.mdegrain2(sup2,bv1,fv1,bv2,fv2,thsad=320)         #  <-- würde eigentlich ausreichen,
rg11.mdegrain3(sup2,bv1,fv1,bv2,fv2,bv3,fv3,thsad=320)   #  <-- aber wir geben's uns gnadenlos ...


#stackhorizontal(o.subtitle("source",size=14),last.subtitle("script",size=14))
return(last)

Das defish - Plugin von davidhorman könnte geeignet sein, um den vorhandenen Pincushin-Effekt zu neutralisieren. Natürlich nicht exakt und nur nach Augenmaß - schließlich weiß man ja nicht, mit welchem Algorithmus oder Parametern das Bild ursprünglich mal verzerrt wurde.

Zitat von Goldwingfahrer

Ob man QTGMC auf einem AMD PC einsetzen kann weiss ich nicht,der kann soviel ich weiss nichts anfangen mit RemovegrainSSE2,RepairSSE2 und auch nicht SSE2Tools.dll.

Lötzinn.:) Mag bei Steinzeit-Athlons mal so gewesen sein, aber aktuelle AMDs unterstützen doch mit sicherheit "offiziell" SSE2. Wäre ja schlimm, da müsste ja "alles mögliche" auf AMD-Cpus nicht funktionieren.

Und selbst wenn tatsächlich nicht -- kaum vorstellbar -- dann nähme man halt die "generischen" DLLs, ohne das "SSE2" im Namen.

Als Kritik hab ich das auch gar nicht aufgefasst. Hab halt nur etwas über das warum-weshalb-wieso herumgebrummelt. Und überhaupt, das zieht sich wohl wie ein roter Faden durch die meisten meiner Scripte: Genau gearbeitet wird da wo's nötig ist - und da wo's nicht weiter weh tut, da dürfen die Hemdsärmel auch gerne offen bleiben. Außerdem komm ich meistens eh nur bis an den Punkt "Methode -> funktrioniert? ==> Jaa, funktioniert!!" - Der weitere Rattenschwanz mit Optimierung, Feintuning, und Absicherungen gegen Falscheingaben ist dann immer so lästig, da braucht's keine Kreativität, nur viel Fleißarbeit, und da mag ich dann meistens nimmer weitermachen.

Wie jetzt - der Blackman ist in x264 nicht mehr drin? Schau mal einer an! - ich hab' nicht mal gewusst dass er jemals drin war!

Ganz salopp würde ich mal sagen, dass die Resizer-Geschichte mit den "hunderten von" verschiedenen Kernels gerne ein wenig überbewertet wird. Mag ja sein dass der eine oder andere deutliche Unterschiede zeigt , wenn man ein Bild dreihundertsechzig mal um ein Grad gedreht oder um 0.234 Prozent vergrößert hat. Aber für die alltägliche Geschichte: Größe "X" in einem Schritt in Größe "Y" zu überführen, dafür kochen sie alle mit dem gleichen Wasser. Es wird ein Kernel einer gewissen Größe angewendet, mit jeweils leicht unterschiedlichen Gewichtungen.

http://svn.int64.org/viewvc/int64/r…oc/kernels.html

Am Ende des Tages läuft's immer auf das gleiche hinaus: mehr "Schärfe" bedeutet mehr "Ringing", weniger Ringing bedingt weniger Schärfe.

Hochskalieren: Spline36 (oder NNEDI3, aber das ist ja ne andere Geschichte)
Runterskalieren: Bicubic, mit einstellbarer (Schärfe/Weichheit)

FEIERABEND.

Der Rest ist von eher akademischem Interesse .... ah, fast wie beim Pilzesammeln: Der Rötliche Bläuling ist sowieso recht schwer vom Bläulichen Rötling zu unterscheiden. Ob nun ein Bläulicher Rötling etwas rötlicher oder bläulicher, oder ein Rötlicher Bläuling etwas bläulicher oder rötlicher ausfällt ... oh jeh, wer will's sagen, das ist so schwer ...

(...Oh, LigH's Antwort gar nicht gesehen, hatte die Textbox ziemlich lange offen...)

Ist schon richtig, hast Du korrekt aufgelöst. NRLimit gibt ja vor, plus/minus wieviel Änderung-per-Pixel maximal vom Denoised-Clip (an der Stelle: ==> RemoveGrain(4)) auf den Original-Clip übernommen werden soll. Und wenn NRLimit=0, dann wird eben eine maximale Änderung von Null übernommen, also keine Änderung zum Original.

Sicher, dieser Spezialfall hätte eleganter gelöst werden können, über eine weitere Abfrage ob NRLimit Null ist, so wie es z.B. weiter unten im Script ja auch gemacht wird:

(NRlimit==0) ? clp : \
mt_lutxy(clp,NRdiff, "y 128 "+NRL+" + > x "+NRL+" - y 128 "+NRL+" - < x "+NRL+" + x y 128 - - ? ?",chroma="process")

Vermutlich war's mir einfach egal (oder ich war zu faul) als ich das Script zusammengeschrieben habe. Erstens kommt ja trotzdem das richtige raus, zweitens ist ein zusätzliches LutXY ziemlich nebensächlich was den Rechenaufwand angeht, und drittens dürfte NRLimit=0 sowieso ziemlich selten vorkommen, weil's von vornherein nicht sonderlich sinnvoll ist ... bzw anders, die Idee war dass ein wenig von dem RemoveGrain(4) immer angewendet werden sollte, um vorhandenes Rauschen nicht zu sehr zu schärfen.

Hmm. Ein ausdrücklicher Fehler ist nicht zu sehen. Allerdings ... ist das auch nicht das komplette Script, es wird ja kein Quellvideo geladen. Nehme mal an, dieses Script wird per Import() an passender Stelle in einem Hauptscript geladen?

Mal kontrollieren, dass:

- am Anfang des Hauptscriptes ein SetMemoryMax() angegeben wird, mit ca. 512 oder so (manche Avisynth-Versionen haben da nen Bug, und ohne SMMax knallt's irgendwann)
- am Ende des Hauptscriptes ausdrücklich ein Return(last) steht - wegen der automatischen Distributor-Geschichte, Erfahrung hat gezeigt mit Return(last) ist's besser, keine Ahnung warum
- Wieviel Threads werden ursprünglich im Hauptscript definiert? Im Zweifelsfall mal auf 4 Threads reduzieren/begrenzen, und dan mal sehen

Überhaupt, warum ist eigentlich nur der MVTools-Teil unter Multithreading? Würde eigentlich auch den FFT3D und SeeSaw mit unter den MTMode(2) nehmen, speziell FFT3D profitiert davon. Und - so wie es jetzt da steht, läuft SeeSaw ja sowieso nur in einem einzigen Thread, ganz ohne MT.

Uuuund ... was ist der Quellfilter? Falls das zufällig DGDecodeNV sein sollte: das hat sowieso gerne mal Probleme mit Multithreading im Script.

Also, ich möchte mich hier nicht allzu weit aus dem Fenster lehnen, aber ich dachte eigentlich auch, dass bei AVC der Standard so ausgelegt ist, dass jeder (normgerechte) Dekoder ein absolut identisches Ergebnis liefern müsste? (War's nicht so, dass die Operationen mit Integer-Operationen durchgeführt werden, statt mit Float?) Gerade das war doch einiges der wichtigen Ziele/Neuerungen im AVC Standard. Beim Mpeg-2 und Mpeg-4/ASP Standard war das ja einer der ewigen & unvermeidlichen Problembereiche, weil da nix definitives festgelegt war, sondern quasi nur ein "Toleranzbereich". Aber AVC sollte beim Dekodieren doch schon deterministisch sein. Oder nicht?

Der "rechte" Screenshot sieht verdächtig nach Rauschfilter-Artefakt aus -- z.B. die "Brille" um die Augenpartie. Evtl. ist's schon in der Source enthalten (Normwandlung), ohne 1:1 Framevergleich kann man's nicht sagen. Falls aber in Handbrake irgendwelche Rauschfilter aktiviert sind, würd' ich die mal ausschalten ...

Mit den Encoder-Einstellungen hat das sehr wahrscheinlich nichts zu tun. SOLCHE Artefakte kriegt man "nur durchs Encodieren" eigentlich gar nicht hin.

Ja, und nein. Mit der Zeile würde Srestore natürlich 24fps 'rausgeben, aber deswegen ist das noch lange nicht richtig. Bei Fieldblending-Normkonversionen ist es ja so, dass das Ursprungsmaterial "x" fps hat (progressiv setzen wir jetzt einfach mal voraus). Der Normkonvertierer zerlegt das in Felder, und produziert dann ein interlactes Video mit "y" fps. Mit diesem interlacten Video fangen "wir" als Endverbraucher an. Jetzt kann man nicht einfach hergehen und bei der Rück-Konvertierung irgendeine FPS-Zahl angeben wie es einem gerade passt, oder weil man 24 vielleicht "schöner" oder "film-ischer" empfinden mag. Man muss schon genau die FPS-Zahl angeben, die im Ursprungsmaterial vorlag. In dem interlacten Fieldblending sind die originalen progressiven Frames versteckt, und zwar genau "x" Stück pro Sekunde. Also muss man auch Srestore anweisen, dass es ein Ergebnis mit genau "x" Frames pro Sekunde produziert. Andernfalls würden entweder gute Frames verworfen (wenn 'frate' kleiner als 'x'), oder es würden Blend-Frames drinbleiben (wenn 'frate' größer als 'x').

Es gibt in der Praxis sowieso fast nur zwei verschiedene Fälle:

a) Man hat PAL-Video mit Fieldblending. Ziel-Framerate für Srestore ist 24fps (oder 23.976).
b) man hat NTSC-Video mit Fieldblending. Ziel-Framerate für Srestore ist 25 fps (oder 24.975).

Alles andere wäre völlig exotisch oder unüblich. Der Fall "29.97fps mit Fieldblending --> 23.976fps" ist zwar denkbar, aber extrem selten. In diesem Fall wird auf der Ersteller-Seite ja normalerweise von vornherein kein Fieldblending verwendet, sondern ganz normaler Pulldown.

(-edit- zumindest wenn es um ursprüngliche FILM-Quellen geht. Es gibt natürlich auch Fälle wo das Originalmaterial echt-Interlaced gewesen ist - Sportaufzeichnungen, Liveshows etc. - und wenn sowas durch einen Normkonvertierer durchgelaufen ist, dann hat man zwar auch Fieldblending, aber das kann dann von Srestore oder RePAL nicht mehr rückgängig gemacht werden.)

Nö, wieso denn? Die Laufzeit bleibt doch die gleiche. Für die Audiospuren ist's egal, ob die Videospur 1h30m mit 30fps läuft, oder 1h30m mit 25fps. Ein Kilo Blei ist nicht schwerer als ein Kilo Federn.

Wenn ich keine Tomaten auf den Augen habe, dann sieht das doch soweit ganz gut aus.

Den interlaced-Parameter für x264 brauchst Du nicht. Das Videomaterial ist durch das Script (wieder) progressiv.

Die Konvertierungsgeschwindikeit ist natürlich stark abhängig von den x264-Einstellungen. Kannst auch "Placebo" nehmen, dann dauert's seeehr viel länger. :zunge: - Mir ging's weiter oben hauptsächlich darum, dass Srestore an sich kein allzugroßer Bremsklotz ist, solange man keinen extra-langsamen Bob-Filter dafür verwendet.