Beiträge von Mike99

Hallo,

meine aktuellen Versuche und Bildvergleiche mit HD-Material haben mich zu der Frage geführt inwieweit es eine zu Seesaw ähnliche Funktion für 1080P gibt?

Das einzige was ich auf die schnelle finden konnte war Finesharp, was aber wohl eher für die Wiedergabe vorgesehen ist, nicht fürs encodieren.

Dideé schreibt ja, dass Seesaw selbst nicht für HD geeignet, ich habe es aber noch nicht ausprobiert.

Es ginge mir dabei nicht um Material was gerade mal DVD-Niveau erreicht, auch nicht um Material was die 1080p perfekt ausnutzt. Ich habe ein paar Scheiben getestet welche erkennbar besser sind als die jeweilige DVD, in der Regel aber auch ein wenig verrauscht. Letzterem begegne ich mit MDegrain3, welches ich auch für SD zusammen mit Seesaw nutze. In der Kombination leidet zwar zwangsläufig die Komprimierbarkeit, dafür sind die Unterschiede auch in der Regel sehr deutlich.

Beste Grüße Michael

So bin ich jetzt eigentlich ganz zufrieden.

Bei Full-HD mit CRF 20 und MDegrain3 lande ich bei etwa 7-8 Frames, zumindest beim aktuell umgewandelten Material.

Die Vergleiche von HD zu FHD sind allerdings noch nicht ganz eindeutig, zumindest bei gleicher Dateigröße, mal scheint mir der Resize besser, mal das Original. Wahrscheinlich wird es doch FHD, dann allerdings bei größerer Datei. Voraussetzung ist natürlich, dass die BD halbwegs gut gemacht ist, was ja leider anscheinend nicht immer der Fall ist. Da bin ich ja beinahe froh, dass ich nur ein wenige besitze.

Ist geklärt, es lag an meiner eigenen Blödheit.

Die Hinweise habe ich ausprobiert, ohne Wirkung, die Auslastung blieb gleich.

Als ich dann die Speicherbegrenzung abschalten wollte fiel mir auf, dass aus irgendwelchen Gründen der erste SetMt-Eintrag weg war, MT also gar nicht zum Zug kommen konnte. Da das bei Stax unter den Optionen steht ist das ja auch nicht immer transparent. Also MT wieder rein und alles läuft auf vollen Touren. Trotzdem vielen Dank für die Mühe.

Gruß Michael

Hallo Selur,

vielen Dank, werde ich morgen testen, aktuell läuft noch eine längere Umwandlung, und dann berichten.

Gruß Michael

Das wären dann vermutlich die x264-Parameter:

x264.exe --preset slow --tune film --crf 20 --output "D:\xyz.h264" "D:\xyz.avs"

Also relativ übersichtlich, ich kann die Preset-Parameter bei Bedarf auch noch angeben.

An der Ecke hätte ich jetzt gar nicht mal überlegt.

Gruß Michael

Edit: Wenn ich den Import weglasse, also das Script zum entrauschen, dann läuft die Kiste wieder mit 100%.

Hallo Selur,

dann hier noch der importierte Rest.

LoadPlugin("G:\Staxrip\Avisynth\mvtools2.dll")
#LoadPlugin("G:\Staxrip\Avisynth\FFT3DFilter.dll")

SetMTMode(2)

super = MSuper(pel=2, sharp=2)

backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=16, overlap=8)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=16, overlap=8)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=16, overlap=8)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=16, overlap=8)

MDeGrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

MTmode wird in Staxrip vorher aktiviert, auch die Speicherbegrenzung für Avisynth fällt mir gerade ein, vielleicht wäre das noch ein Ansatz.

Ich habe feste Werte, eine Parametrierung folgt noch, dann wenn ich mir darüber klar bin, was ich machen möchte, da bin ich leider noch nicht so weit :-).

Gruß Michael

Hallo,

nach meinen diversen Tests mit SD-Material habe ich mich an HD gewagt. Mit die erste (enttäuschende) Erkenntnis war, dass es durchaus möglich ist, dass eine mit Mdegrain und Seesaw "aufpolierte" DVD besser aussehen kann als die entsprechende Blu Ray Disc, naja, wieder Geld zum Fenster rausgeworfen.

Nach dem Wechsel von Windows 7 32bit auf 64bit laufen die Scripts jetzt auch ohne Abbrüche durch.

Grundsätzlich mache ich im Moment nichts anderes als entrauschen mit MDegrain (2 oder 3, teilweise mitfft3d vorgeschaltet).

Laufen tut das ja mittlerweile, nur leider kommt die CPU (4-Kern, Ivy, 3,4 Ghz) trotz MT nicht mehr richtig zum Zuge, sowohl bei HD als auch bei Full-HD. Damit meine ich, dass die Auslastung nicht mehr nahe 100 % liegt, eher schwankend zwischen 50% und 80%.

Auf Anhieb würde ich vermuten, dass die zusätzliche Menge an Bildpunkten die Ursache darstellt. Angepasst habe ich schon blocksize und overlap. Oder vielleicht doch ein Glied in der Filterkette?

FFVideoSource("D:\Video\0005_BR\test.mkv", cachefile="D:\Video\0005_BR\TempFiles\test.ffindex")
AssumeFPS(23.976)
Crop(0,0, -Width % 8,-Height %
ConvertToYV12()
Crop(0,140,-0,-142)
Import("g:\Staxrip\Avisynth\MDeGrain2HD.avsi")

Der Rechner hat 4 GB Hauptspeicher, wenn die Prozesse laufen ist aber immer noch Reserve. Installiert sind die letzten Versionen von Avisynth und MT (Set hat ja für die Tage eine Überarbeitung angekündigt, die scheint aber noch nicht verfügbar zu sein). Grundsätzlich arbeit ich immer mit Staxrip.

Gruß Michael

Scheint endlich geklärt.

Nach diversen unfruchtbaren Vermutungen und Analyseschritten hat sich die verwendete Removegrain-Version (1.0) als Übeltäter herausgestellt. Nach dem Wechsel auf die Version 0.9 läuft das Script jetzt ohne weitere Probleme, unabhängig der Avisynth-Version usw..

In Erinnerung habe ich, dass es mal Probleme mit Sse in den neueren Versionen gab, das Phänomen hier trat aber auch mit der nicht Sse-Variante auf. Hauptsache es läuft jetzt und ich kann mich dem Vergleich von MDegrain2 und MDegrain3 widmen :-).

Hallo Didée,

das sollte keine Kritik sein, bitte nicht falsch verstehen, ich wollte nur sehen ob ich das halbwegs interpretiert bekomme.

Interessieren würde mich allerdings wieso nur ausschließende Intervallgrenzen, also größer und kleiner und nicht wenigstens einmal mit gleich versehen, vorkommen, hätte ich halt anders erwartet, das muss aber in diesem Zusammenhang nicht viel bedeuten :-).

LigH: Die Dll-Dateien liegen alle separat und werden explizit referenziert, bis auf die beiden die bei der Installation reinkopiert worden sind.

Ansonsten arbeite ich im Moment nach dem Außschlussprinzip weiter, im Moment sieht es so aus, also ob der Aufruf von Removegrain in der genannten Zeite die Ursache sein könnte, speziell der Parameter -1, was aber noch nicht sicher ist.

Gruß Michael

Ich versuche gerade den folgenden Ausdruck aus Seesaw zu verstehen:

denoised = defined(denoised) ? denoised : mt_lutxy(clp,clp.removegrain(4,-1),"x "+NRL+" + y < x "+NRL+" + x "+NRL+" - y > x "+NRL+" - y ? ?",chroma="copy first")

Hierzu habe ich mir die UPN-Beschreibung durchgelesen und versucht den String in mt_lutxy() umzuformulieren.

Davon ausgehend, dass beim Aufruf NRLIMIT = 0 ist ergibt sich (hoffentlich) folgendes:

"x < y ? x : x > y ? x : y"

Ich hoffe nicht ganz soweit weg zu sein, Klammern und Operatorprioritäten mal aussen vor. Jedenfalls käme dann immer x raus, also das Pixel des ersten Clips wenn ich es halbwegs richtig verstanden haben sollte?

Und wenn x = y dann gar nichts?

Das Thema scheint gar nicht so einfach.

Nach der genannten Änderung sind jetzt 3 Filme durch, es folgt die Gegenprobe mit den alten Einstellungen.

Die Kombi mt-25 und Avisynth 2.60 lief bei mir auch grundsätzlich, in diesem Fall aber auch mit Abbruch wie beschrieben.

Wenn ich hiermit durch bin werde ich auch erstmal aufräumen müssen, da ich einiges von den Staxrip-Applicationen kreuz und überschrieben habe.

Analog habe ich nicht mehr viel, die meisten Sachen gab es irgendwann auf DVD, mir fehlen nur noch zwei Filme (Shadowhunter, Der tödliche Kreis). Das letzte was ersetzt wurde war das blaue Palais, die Qualität könnte da aber besser sein, auf Welt am Draht und Das Millionenspiel musste ich auch lange warten.

Ansonsten ist es eine ziemlich umfangreiche DVD-Sammlung mit geringen HD-Anteilen. Meine ersten Versuche zum Umwandeln habe ich abgebrochen, da trotz übertaktetem Vierkern eine Hochrechnung eine Laufzeit von 2 Jahren ergab bei gegebenem Script-Grundgerüst. Vor allem der Stromverbrauch des übertakteten Rechners war nicht ohne. Die Idee das originale Mpeg2-Video in MKV-Container zu packen war auch nicht ideal, das ging zwar, auch sehr schnell, mir waren aber über 30 Terrabyte dann doch zu viel.

Das sieht heute alles besser aus. Mit einem Core i5 und 4x3,8 komme ich beinahe auf Echzeit (22-25fps), ohne Übertaktung, ca. 45 Watt Stromverbrauch. Selbst preisweite Upscaler (Panasonic Uniphier Pro im entsprechenden Blu Ray Player, MKV-tauglich) unterscheiden sich, sofern man nicht großartig einstellen möchte, kaum noch von einem dedizierten Upscaler (Radiance + DVDO). Im Moment spiele ich mit einem Apple TV3 rum und wundere mich was so ein Kästchen bei 2-3 Watt Verbrauch leistet im Vergleich zum Beispiel zu einem HTPC mit MadVR, der natürlich viel mehr kann, wenn man es möchte.

Daher auch der jetzige Versuch, das nochmal in Angriff zu nehmen und die Scheiben nur noch wie bei der Musik auch als Notreserve im Schrank zu lagern.

Hallo,

die Removegrain-Versionen habe ich schon alle durch, leider, sowohl die 3er, die 2er als auch die statisch verlinkten.

Der Sprung bei den Masktools hängt tatsächlich mit der eingesetzten Avisynth-Variante zusammen, bei 2.58 hatte ich die 25, bei 2.60 die 26 eingesetzt.

Witzigerweise habe ich gerade einen Film zu 100% umwandeln können.

Ich habe angefangen Funktionsteile ausser Gefecht zu setzen in der Hoffnung Zug um Zug den problematischen Teil zu isolieren.

Der Funktionsaufruf war jetzt wie folgt:

sharp0 = source.Seesaw(denoised=preNR, nrlimit=0, nrlimit2=99, bias=49, sstr=1.24, Spower=3, Szp=12, Sdamplo=4, SdampHi=19, Slimit=99, sootheT=0, sootheS=0)

Es wurde der Parameter denoised hinzugefügt.

Daher ist folgende Zeile jetzt anders verarbeitet worden:

denoised = defined(denoised) ? denoised : mt_lutxy(clp,clp.removegrain(4,-1),"x "+NRL+" + y < x "+NRL+" + x "+NRL+" - y > x "+NRL+" - y ? ?",chroma="copy first")

Wenn ich die Syntax korrekt interpretiere wird der zweite Teil hinter dem Fragezeichen nun nicht mehr ausgeführt.

Leider ist ein Film zu 100% noch kein verlässlicher Anhaltspunkt, das passiert auch so hin und wieder. Daher habe ich gleich zwei weitere auf den Weg gebracht. Falls die beiden ebenfalls durchlaufen ist die Wahrscheinlichkeit relativ hoch, dass hier das Problem liegt /lag.

Gruß Michael

Beide abgestürzt, einmal wie oben, einmal mod16, einmal bei 10%, einmal immerhin bei 16%.

Zum debuggen gibt es ja vermutlich nichts passendes? Zumindest hätte ich nichts gefunden.

Vielleicht lasse ich noch eine Windows-Neuinstallation laufen, man greift ja nach jedem Strohhalm :).

Ansonsten habe ich mal ansatzweise versucht die beiden Scripte im Editor nebeneinander zu legen (Seesaw und LSFMOd) und zu vergleichen, was für mich aber schwerer Tabak ist. Eventuell macht der Ansatz Zug um Zug Teile wegzulassen mehr Sinn, auch wenn es dann inhaltlich sicher nicht immer einen Sinn ergibt.

Hallo Didée,

schonmal vielen Dank für die Hinweise, da fehlt tatsächlich was, sorry.

Da ich mit Staxrip arbeite habe ich in den Einstellungen die Angaben hinterlegt welche immer am Anfang auszuführen sind.

Das aufrufende Script sieht dann z.B. so aus:

LoadPlugin("G:\StaxRip\Applications\DGMPGDec\DGDecode.dll")
SetMemoryMax(512)
SetMTMode(5)

MPEG2Source("H:\Vob\Film1\SZ_32\VIDEO_TS\VTS_01_1 temp files\VTS_01_1.d2v")
Crop(0,0, -Width % 8,-Height %
ConvertToYV12()
Crop(0,86,-0,-90)
Import("g:\Staxrip\Avisynth\sswfft.avsi")

Der letzte Importbefehl ruft dann das zuerst genannte Script auf.

Davon ausgehend sollte die Problematik mit dem Speicher ausgeschlossen werden können.

In der aktuellen Variante (liegt auf meinem "Rechenknecht" und war daher hier nicht mit dabei) gibt es auch leider schon die Anweisung Return(last) am Ende, das hatte ich beim Durchsuchen des Forums gefunden mit dem von Dir genannten Hinweis, kann sogar sein, dass das von Dir stammte.

Die Reduktion auf 4 Threads kann ich noch versuchen. Allerdings habe ich das ganze schon auf zwei Rechnern getestet, einmal Zweikern, einmal Vierkern, jeweils Ivy Bridge (vielleicht liegt hier das Problem?). Der Vierkernrechner sollte mit 8 Threads normalerweise arbeiten, der andere mit 4, soweit mit meine Architekturkenntnisse da nicht im Stich lassen.

Den MtMode(2) hatte ich schon an verschiedenen Stellen stehen (auch den Mode 3). Seltsamerweise hatte ich eine höhere Framerate wenn Mode 2 nach FFT3D stand. Das war aber in einer anderen Evolutionsstufe des Scripts, daher werde ich das ebenfalls noch ändern.

Was mir noch einfällt: Crop ist nicht Mod 16, wäre vielleicht auch noch einen Versuch wert?

So läuft jetzt und sieht wie folgt aus:

LoadPlugin("G:\StaxRip\Applications\DGMPGDec\DGDecode.dll")
SetMemoryMax(512)
SetMTMode(5,4)

MPEG2Source("H:\Vobneu\MainMovie\DRAGONHEART\VIDEO_TS\VTS_01_1 temp files\VTS_01_1.d2v")
Crop(0,0, -Width % 8,-Height %
ConvertToYV12()
Crop(0,74,-4,-74)
Import("g:\Staxrip\Avisynth\sswfft.avsi")

Das aufgerufende Script (mal wieder ohne Sse3):

LoadPlugin("g:\Staxrip\Avisynth\mvtools2.dll")
LoadPlugin("g:\Staxrip\Avisynth\mt_masktools-25.dll")
LoadPlugin("g:\Staxrip\Avisynth\RemoveGrainS.dll")
LoadPlugin("g:\Staxrip\Avisynth\RepairS.dll")
LoadPlugin("g:\Staxrip\Avisynth\FFT3DFilter.dll")


source = last


SetMTMode(2,4)


preNR = source.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=4,bw=16,bh=16,ow=8,oh=8)


sharp0 = source.Seesaw(nrlimit=0, nrlimit2=99, bias=49, sstr=1.24, Spower=3, Szp=12, Sdamplo=4, SdampHi=19, Slimit=99, sootheT=0, sootheS=0)


preNR_super = preNR.MSuper(pel=2, sharp=2)


super2 = sharp0.MSuper(pel=2,sharp=2,levels=1)


backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(preNR_super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(preNR_super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, overlap=4)


source.MDeGrain2(super2, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=350)


Return(last)




#  SeeSaw v0.3e (02 Jan 2006)
#
#  (Full Name: "Denoiser-and-Sharpener-are-riding-the-SeeSaw" )
#
#  This function provides a (simple) implementation of the "crystality sharpen" principle.
#  In conjunction with a user-specified denoised clip, the aim is to enhance
#  weak detail, hopefully without oversharpening or creating jaggies on strong
#  detail, and produce a result that is temporally stable without detail shimmering, 
#  while keeping everything within reasonable bitrate requirements.
#  This is done by intermixing source, denoised source and a modified sharpening process,
#  in a seesaw-like manner.
#
#  This version is considered alpha.  
#
#  Usage:
#
#  a = TheNoisySource
#  b = a.YourPreferredDenoising()
#  SeeSaw( a, b, [parameters] )
#
#  You're very much encouraged to feed your own custom denoised clip into SeeSaw.
#  If the "denoised" clip parameter is omitted, a simple "spatial pressdown" filter is used.
#
#
#  Fiddled together by Didée, for your pleasure.
#




# =======  Main function  =======


function SeeSaw( clip  clp, clip "denoised", 
 \               int   "NRlimit",int "NRlimit2", 
 \               float "Sstr",   int "Slimit", float "Spower", float "SdampLo", float "SdampHi", float "Szp",
 \               float "bias",   int "Smode",    int "sootheT",  int "sootheS", float "ssx",     float "ssy")
{
ssx      = default( ssx,      1.0 )       # supersampling factor x  /  SeeSaw doesn't require supersampling urgently. 
ssy      = default( ssy,      ssx )       # supersampling factor y  /  if at all, small values ~1.25 seem to be enough.
NRlimit  = default( NRlimit,    2 )       # absolute limit for pixel change by denoising
NRlimit2 = default( NRlimit2, NRlimit+1)  # limit for intermediate denoising
Sstr     = default( Sstr,     1.5 )       # Sharpening strength (don't touch this too much)
Slimit   = default( Slimit, NRlimit+2 )   # positive: absolute limit for pixel change by sharpening
                                          # negative: pixel's sharpening difference is reduced to diff=pow(diff,1/abs(limit))
Spower   = default( Spower,     4 )       # exponent for modified sharpener
Szp      = default( Szp,     16+2 )       # zero point - below: overdrive sharpening - above: reduced sharpening
SdampLo  = default( SdampLo, Spower+1 )   # reduces overdrive sharpening for very small changes
SdampHi  = default( SdampHi,   24 )       # further reduces sharpening for big sharpening changes. Try 15~30. "0" disables.
bias     = default( bias,      49 )       # bias towards detail ( >= 50 ) ,  or towards calm result ( < 50 )
Smode    = default( Smode,     ssx<1.35 ? 11 : ssx<1.51 ? 20 : 19 )
sootheT  = default( sootheT,  49 )        # 0=minimum, 100=maximum soothing of sharpener's temporal instableness.
                                          # (-100 .. -1 : will chain 2 instances of temporal soothing.)
sootheS  = default( sootheS,   0 )        # 0=minimum, 100=maximum smoothing of sharpener's spatial effect.


Szp   = Szp / pow(Sstr, 1.0/4.0) / pow( (ssx+ssy)/2.0, 1.0/2.0 ) 
SdampLo = SdampLo / pow(Sstr, 1.0/4.0) / pow( (ssx+ssy)/2.0, 1.0/2.0 )


ox=clp.width
oy=clp.height
xss = m4(ox*ssx)
yss = m4(oy*ssy)
NRL   = string( NRlimit  )
NRL2  = string( NRlimit2 )
NRLL  = string( int(round( NRlimit2 * 100.0/bias - 1.0 )) )
SLIM  = string( abs(Slimit) )
BIAS1 = string( bias )
BIAS2 = string( 100-bias )
#ZRP   = string( abs(Szp) )
#PWR   = string( abs(Spower) )
#DMP   = string( SdampLo )


denoised = defined(denoised) ? denoised : mt_lutxy(clp,clp.removegrain(4,-1),"x "+NRL+" + y < x "+NRL+" + x "+NRL+" - y > x "+NRL+" - y ? ?",chroma="copy first")


NRdiff = mt_makediff(clp,denoised,chroma="process")
tame   = mt_lutxy(clp,denoised,"x "+NRLL+" + y < x "+NRL2+" + x "+NRLL+" - y > x "+NRL2+" - x "+BIAS1+" * y "+BIAS2+" * + 100 / ? ?")
head   = tame.sharpen2(Sstr,Spower,Szp,SdampLo,SdampHi,4)
# head = head.mt_merge(tame,tame.prewitt(multiplier=1.0).mt_expand().removegrain(20))


(ssx==1.0 && ssy==1.0) ? repair(tame.sharpen2(Sstr,Spower,Szp,SdampLo,SdampHi,Smode),head,1,-1,-1) 
 \                     : repair(tame.lanczosresize(xss,yss).sharpen2(Sstr,Spower,Szp,SdampLo,SdampHi,Smode),head.bicubicresize(xss,yss,-.2,.6),1,-1,-1).lanczosresize(ox,oy)


#SootheSS(last,tame,sootheT,sootheS)
sharpdiff= mt_makediff(tame,last)


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


Slimit>=0 ? mt_lutxy(last,sharpdiff,"y 128 "+SLIM+" + > x "+SLIM+" - y 128 "+SLIM+" - < x "+SLIM+" + x y 128 - - ? ?",chroma="copy first")
 \        : mt_lutxy(last,sharpdiff,"y 128 == x x y 128 - abs 1 "+SlIM+" / ^ y 128 - y 128 - abs / * - ?",chroma="copy first")


return( last )
}




# =======  Modified sharpening function  =======


function sharpen2(clip clp, float strength, float power, float zp, float lodmp, float hidmp, int rgmode) 
{
STR  = string( strength )
PWR  = string( 1.0/float(power) )
ZRP  = string(    ZP    )
DMP  = string(   lodmp  )
HDMP = (hidmp==0) ? "1" : "1 x y - abs "+string(hidmp)+" / 4 ^ +"


mt_lutxy( clp, clp.RemoveGrain(rgmode,-1,-1), \
           "x y == x x x y - abs "+ZRP+" / "+PWR+" ^ "+ZRP+" * "+STR+" * x y - 2 ^ x y - 2 ^ "+DMP+" + / * x y - x y - abs / * "+HDMP+" / + ?",chroma="copy first")
return( last )
}




# =======  Soothe() function to stabilze sharpening  =======




# =======  MOD4-and-atleast-16 helper function  =======


function m4(float x) {x<16?16:int(round(x/4.0)*4)}

Ich hatte das zwischenzeitlich reinkopiert, auch wegen der Tests mit AVSP. Soothe hatte ich entfernt, da nicht von mir genutzt.

Gruß Michael

Hallo,

folgendes Script habe ich nach Hinweisen hier und bei Doom9 im Test:

LoadPlugin("D:\Staxrip\Avisynth\mvtools2.dll")
LoadPlugin("D:\Staxrip\Avisynth\mt_masktools-26.dll")
LoadPlugin("D:\Staxrip\Avisynth\RemoveGrainSSE3.dll")
LoadPlugin("D:\Staxrip\Avisynth\RepairSSE3.dll")
LoadPlugin("D:\Staxrip\Avisynth\FFT3DFilter.dll")


Import("D:\Staxrip\Avisynth\SeeSaw.avs")


source = last


preNR = source.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=4,bw=16,bh=16,ow=8,oh=8)


sharp0 = Seesaw(source, preNR, nrlimit=0, nrlimit2=99, bias=49, sstr=1.24, Spower=3, Szp=12, Sdamplo=4, SdampHi=19, Slimit=99, sootheT=0, sootheS=0)


SetMTMode(2)


preNR_super = preNR.MSuper(pel=2, sharp=2)


super2 = sharp0.MSuper(pel=2,sharp=2,levels=1)


backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(preNR_super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(preNR_super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, overlap=4)


source.MDeGrain2(super2, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=350)

Mit dem Ergebnis bin ich sehr zufrieden, aber leider kommt es zu unregelmäßigen Abstürzen beim x264 Encoding.

Mal läuft ein Video durch, dann wieder Abbruch, bei verschiedenen Abarbeitungsständen jeweils beim gleichen Film.

Die Fortschrittsanzeige von Staxrip hält an, der Encoder läuft unter Auslastung eines CPU-Kernes weiter, tut aber eigentlich nichts mehr, zumindest wird nichts mehr auf die Platte geschrieben.

Erstmal habe ich einen (unwahrscheinlichen) Fehler der Oberfläche ausgeschlossen = analoges Problem unter Megui.

Dann nocht diverse Tests mit z.B. verschiedenen Avisynth-Varianten (2.58, 2.60), den Encoder aktualisiert, verschiedene SetMtMode-Einstellungen getestet, auf SSse3 verzichtet, ....

Der Fehler bleibt konstant erhalten, es sei denn ich lasse nur SetMtMode(5) stehen, dann läuft die Verarbeitung durch, allerdings mit unterirdischem Tempo.

Ein ähnliches Script mit LSFMod anstelle Seesaw läuft ohne Probleme, auch eine reduzierte Variante nur Mdegrain oder Mdegrain + fft läuft ebenfalls durch.

Leider habe ich es mit LSFMod noch nicht geschafft nah genug an das Ergebnis von Seesaw ranzukommen, dann könnte ich ja dabei bleiben.

Im Moment habe ich jedenfalls keine Idee was ich noch versuchen könnte bzw. woher das Problem kommt. Nachdem was ich gelesen habe müsste Seesaw ja grundsätzlich für MT geeignet sein.

Beste Grüße Michael

Ich ziehe das menschliche Auge vor, auch wenn es sich leicht täuschen lässt.

Erste Instanz ist ein ordentlicher LCD am PC, dann noch ein 46er-LCD-TV von dem ich etwa 2 Meter weg bin. Der LCD am PC ist deutlich gnadenloser. Diese "objektiven" bzw. maschinellen Vergleiche sind mir nicht so ganz geheuer. Bezüglich Musik gehe ich auch so vor, und bin bisher z.B. von kostspieligen Kabeln usw. verschont geblieben ;)-

Gibt es eigentlich auch ABX-Vergleiche im Videobereich?

Beste Grüße Michael

Zitat von LigH

Wenn du tatsächlich das Zwischenergebnis verlustlos als Videodatei speichern wolltest (auch wenn das u.U. riesengroß werden kann, je nach Bildfläche und Spieldauer evtl. einige 'zig GB), dann könntest du z.B. das Video in VirtualDub öffnen, als Codec den ffdshow-VfW-Codec auswählen und ihn auf FFV1 konfigurieren. Dies wäre ein verlustloser Codec, der YV12-Video speichern kann. Er packt das Video ein wenig kräftiger als die ffdshow-Variante von HuffYUV. Auch die verlustlose Encodierung in AVC-Lossless mit x264 (Quantisierungsfaktor = 0) wäre eine Möglichkeit.

AVC-Losless muss ich mir mal ansehen, das war mir noch gar nicht aufgefallen. Dürfte aber für die Praxis (zuminest für meine) nicht so sinnvoll sein.

War denn der Rest der Annahmen im ersten Beitrag so korrekt?

Irgendwie schade, dass man mpeg2 nicht nativ "verwursteln" kann.

Beste Grüße Michael

Aktuell führe ich mit verschiedenen Filterscripten und x264-Parametern Umwandlungsversuche durch (Laufzeit und Qualität) und vergleiche das Ergebnis mit dem Orginalvideo.

Zusätzlich hatte ich die Hoffnung, irgendwie das nur gefilterte Video, also nach kompletter Avisynth-Verarbeitung und vor der Encodierung durch X264 in den Vergleich mit einbeziehen zu können.

Ich hoffe verstanden zu haben, dass das Video, damit es in Avisynth bearbeitet werden kann, über z.B. DGDecode decodiert und anschließend prozessiert wird. Daraus ziehe ich den Schluss, dass es am Ende der Avisynth-Verarbeitung nur in entkomprimierter Form vorhanden ist. Das würde dann bedeuten, dass ich es nur entweder unkomprimiert zwischenspeichern kann (auf welchem Weg, wäre mir aber nicht klar) oder alternativ die Wahl hätte, es wieder zu encodieren.

Gewünscht hätte ich mir ja eigentlich, dass ich ein mpeg2-Video prozessieren und es in dem Format erhalten kann ohne es erneut encodieren zu müssen.

Die einzige Möglichkeit, die ich bisher finden konnte wäre das Script in einen entsprechenden Player einzubinden und beim Abspielen des Videos dann anzuwenden.

Diese Empfehlung würde ich sogar noch ein Stück erweitern.

Ich bin mittlerweile soweit, dass ich für beinahe jede neue Scriptversion welchen Tools auch immer ein eigenes Unterverzeichnis anlege, allerdings nicht unterhalb des Avisynth-Plugin-Verzeichnisses sondern auf meinem Datenlaufwerk. Letzteres muss man nicht, da ich aber aus aktuellem Experemtierwahn auch Windows öfter platt mache ist das ganz sinnvoll weil es dann erhalten bleibt.

So kann ich in jedem Script durch explizite Verweise immer genau das laden was ich möchte und kann jederzeit wieder auf als funktionierend bekannte Konfigurationen zurückgreifen. Damit kann man dann prüfen, ob das aktuelle Problem mit einer "guten" Konfiguration auch Auftritt. In der letzten Woche waren das z.B. ein YV12-Cropping-Problem und ein fehlerhafter X264-Build.

Beste Grüße Michael