Ja.
Genau mein Problem
Ja.
Genau mein Problem
Kommt mir ganz entgegen, weil ichs ja eh nach dem Deinterlacing anwenden will. Da ich sonst die Befürchtung habe, dass TGMC da durcheinander kommt, bzw. schlechtere Ergebnisse liefert, was bei dem sh0dan Script auch der Fall ist, meiner Meinung nach zumindest.
Sind doch aber zwei von einander unabhängige Funktionen. ChubbyDeRain & ChubbyRain2. Oder sehe ich das falsch? Oder sollen die beide drüber laufen? Werde ich wohl erst am Donnerstag testen können.
Da stellt sich mir jetzt nur noch die Frage wie sinnvoll es ist ein so starkes Rainbowing vollständig unterdrücken zu wollen. Also was den Qualitätsverlust für den Rest angeht. Also so im ersten Vergleich scheint deine Methode keine Nachteile zu haben. Ich muss das mal in Bewegung sehen
Mein Problem ist aktuell auch vielmehr, nicht, dass es nicht weggeht, sondern sich durch meine bisherige Lösung verstärkt.
Oh man, irgendwie schaff ich es nicht hier Dateien hochzuladen für den Anhang.
DeDot habe ich gerade mal ausprobiert. Da sieht das Bild wie das Original ohne DeDot aus.
Erst mit sehr niedrigen Werten beim sh0dan Script tut sich was, aber das dürfte zuviel an den Farben zerstören.
Hier mal das besagte Video:
http://www.mediafire.com/?nt1am9n62ahz8tz
In dem Video tragen irgendwie alle so abgedrehte Hemden.
Gibt es bessere DeRainbow Skripte als DeRainbow-sh0dan.avs? Das bekommt zwar die meisten Rainbows recht gut weg, aber unter bestimmten Bedingungen verstärkt es die Rainboweffekte. Meiner Meinung nach dann, wenn sie recht stark sind.
Ja, deswegen hatte ich ja auch geschrieben, dass ichs nicht nachvollziehen kann. Nur weil sich der Encoder hinhängt, sollte die GUI, die ja nur ein Skript generiert, diesem eigentlich nicht folgen. Wird vlt der Absturz irgendwie nicht richtig abgefangen. Keine ahnung. Aber gut, dann weiß ich zumindest, dass es nicht an StaxRip liegt. Das hilft mir auch schon mal weiter. Danke
Ja, mit der Art von Zeitverlust hast du auch wieder recht. Hm. Na ich hoffe es lässt sich doch noch mit SetMemoryMax() unter Kontrolle bringen.
Also nach meinen Tests heute brauche ich für eine Minute Film 22:53 mit MT und 26:25 ohne. Macht für mich schon einen Unterschied. Würde also nur ungern auf MT verzichten.
Ich experimentiere zur Zeit damit Filter in MT() einzubinden. Im Moment TGMC. Dabei hat sich gezeigt, dass StaxRip dann sehr instabil wird. Erklären kann ich mir das nicht. Mit SetMTmode() bekomme ich Speicher Fehler gemeldet und mit MT() stürzt StaxRip einfach ab. Gibt es da Möglichkeiten dagegen? Kann es an zu wenig Speicher liegen (2GB)? Material ist 576i. SetMemoryMax() werd ich auch nochmal probieren. Aber ich kann nicht nachvollziehen warum das StaxRip beeinflussen sollte. Wenn x264 abstürzt, das könnte ich dagegen eher verstehen.
Ah, da sollte nur eine sein. Dann isses das. Aber was soll mir das sagen? Das mit MT was nich ganz stimmt, bzw. nicht bei allen Filtern ne gute Idee is?
Hm, cooles preset. Das wär doch was für mich
Aber hast schon recht. Und dein Beispiel fand ich auch überzeugend. Hatte ja selbst schon im anderen Fehler entdeckt. Werde ich mir nocheinmal ansehen und Geschwindigkeit testen. Auch nochmal von NNEDI3. Danke für den Tipp.
EDIT: Meinst mit Speicherfehler, dass mein Arbeitsspeicher hin is? Müsst wohl mal nen memtest drüberlaufen lassen. Würde mich aber recht wundern.
EDIT2: Was wolltest du mir eigentlich mit dem "Übrigens: ColorBars()" sagen? Ich komm einfach nich drauf Dass es bei mir auch mit 8 Threads läuft?
EDIT3: Also mit NNEDI2 hab ich volle CPU Last. Bringts da MT überhaupt noch?
Oh, das Gegenrezept hab ich nur nicht richtig verstanden Du meintest 4 Pixel Overlap reichen. Warum hast du dann jetzt 16 im Beispiel? 4x4? Und die Bildquali ist dadurch dann so gut wie als wenn man es ohne MT encoden würde? Also ich habs mal verglichen, es gibt zwar unterschiede, aber scheinbar keine qualitative Beeinträchtigung.
Ah, man muss das SetMTmode noch vor dem LoadPlugin haben. Ich habs direkt vor den Filter. Ok. So nach einem Test, bekomme damit leider ziemlich oft:
StaxRip has crashed!
System.AccessViolationException: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.
Also ich habs mal genau so probiert, also SetMTmode(5,2) in die erste Zeile des Skripts plus SetMTmode(2) oder nichts vor TGMC, habe dann aber immer nur eine Last von um 80%. Fehlen also fast 20%.
Zu NNEDI2 hatte ich doch mal mit dir eine kleine Diskussion. In meinem Videobeispiel hatte das deutlich schlechtere Ergebnisse geliefert als EEDI2
Ja, ich möchte schon die möglichst beste Qualität. Aber danke für den Tipp. Werde SLrad mal verringern und dann Quali-Test machen. Wäre wirklich schön, wenn das noch einen Tick schneller würde, ohne Qualitätsverlust. Muss ich nachher mal einen Geschwindigkeitstest unterziehen
Hm, also ich habe mal die Qualität von MT mit normalen Encodes verglichen. Mit MT habe ich so eine Art Horizontales Tearing. Das ist wohl das was Didée bereits vorausgesehen hat. Toll, damit ist MT für mich nicht zu gebrauchen :heul:
EDIT: Ich habe jetzt auch mal SetMTMode in allen möglichen Modes ausprobiert auch SetMTMode(5,2), aber die CPU Last hängt immer irgendwo bei 80% rum. Nicht wie bei MT mit 98%. Damit dürfte es mir von der Geschwindigkeit her kaum etwas bringen
Also es geht mit MT jetzt scheinbar einen ganzen Tick schneller. Nach ersten Tests ca. 2,1fps statt 1,6fps ohne MT (gleiche AviSynth Version), und auch die CPU Last bleibt jetzt scheinbar konstant auf über 90%. Aber dafür hängt sich StaxRip mit MT jetzt recht oft hin. Das is ziemlich blöde bei Batch Encodes.
EDIT: Und danke für den Tipp mit der neueren Avisynth-MT Version.
EDIT2: Was mir jetzt auch wieder auffällt ist, dass, seit ich TGMC verwende, öfter mal am Anfang des h264 Encodes erstmal für Minuten CPU Last (jetzt über 90% vorher nur 50%) produziert wird, ohne dass ein Encoding stattfindet. Zumindest steht die h264 Datei auf Größe 0 und auch im StaxRip Log Fenster steht keine Prozent Angabe. Was macht der da nur?
EDIT3: Hm, nur was jetzt neu ist, dass der Speicherverbrauch konstant ansteigt Ich brechs mal ab. Hatte das Video vorhin schonmal angefangen zu encoden, da war das noch nicht. Habe ich auch schon öfter beobachtet. Dass es mal ist und mal nicht, bei dem gleichen Video.
EDIT4: Habe das Video jetzt nochmal neugestartet, jetzt macht er was er soll.
Hm, klingt jetzt bisschen danach, als würdest für TGMC von MT eher abraten.
Und was das swappen angeht, habe ich noch nie erlebt dass das x264 nie tut. Egal wie viel Speicher noch frei ist.
Hatte noch ein AviSynth 2.57. Werd das neue dann mal installieren wenn der Encode mal fertig wird. Oder vielleicht auch gleich, weil der schon wieder auf 50% gefallen is
Hat SetMemoryMax(700) irgendwelche Auswirkungen auf die Encoding Qualität? Im Moment braucht x264 436 MB RAM und 476 MB Swap.
MultiThreading is gut. Funktioniert das AviSynth-MT denn schon gut? Und wie muss man es noch steuern?
EDIT: Ohje, ich bin schon froh, wenn ich über 1,8 fps habe. Wow das muss ich unbedingt haben
Einfach mein TGMC Skript in MT() rein?
EDIT2: Hm, wie ist das? Die modifizierte avisynth.dll version is jetzt noch 2.5.7.5. Aber du meintest doch, dass diese Version noch Speicherprobleme hatte.
EDIT3:
MT("TempGaussMC_beta2(2,2,3,4,0,4,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)",threads=2)
Bringt folgende Fehlermeldung:
Avisynth open failure:
Script error: expected a , or )
CPUZ sagt, dass ich zwei Cores und zwei Threads habe. Heißt das ich habe insgesamt nur zwei Threads oder vier durch die zwei Cores?
EDIT4:
Ah mit
MT("""TempGaussMC_beta2(2,2,3,4,0,4,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)""",threads=2)
scheint es jetzt zu gehen.
Kein SetMemoryMax(). Was meinst du mit Avisynth-Multithreading? mt_masktools.dll werden verwendet, falls du das meinst. Ausstattung sind 2GB. WinXP 32-bit.
Quelle is 576i.
Oh, stimmt. Hatte ja einiges an Infos vergessen.
Also ich encode mit StaxRip (kein VirtualDub im Boot), x264 mit Preset Slower, Tune Film, Mode Quality. Im Moment ist es ist ein Bach Encode, aber das Phänomen tritt auch bei Einzelnen auf. Wie gesagt, Test an ein und dem gleichen File, und während dem Encode eines Files.
Speicher liegt bei ca 1,94 GB von 2 GB. Hab auch schon versucht alles mögliche freizuschaufeln (1,3 GB dann), weil ich auch dachte es liegt daran, hat aber die Nacht über, der Encode dauert jetzt schon ein zwei Tage, nichts daran geändert.
MBTree Lookahead konnt ich nicht finden. Nur einen RC Lookahead der bei 60 liegt. Ansonsten ist MB Tree aktiviert.
EDIT: Gerade isser mal wieder bei 80-90%. Speicher 1,95 GB. Versteh ich nich.
EDIT2:
Die Konfiguration von TGMC verwende ich gerade:
TempGaussMC_beta2(2,2,3,4,0,4,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)