mt_masktools bei verwendung mit TempGaussMC_beta3

  • Problemereignisname: APPCRASH
    Anwendungsname: x264-r2164.exe
    Anwendungsversion: 0.120.2164.0
    Anwendungszeitstempel: 4f2d9b7f
    Fehlermodulname: mt_masktools-26.dll
    Fehlermodulversion: 2.0.48.0
    Fehlermodulzeitstempel: 4d1e0f0c
    Ausnahmecode: c0000005
    Ausnahmeoffset: 000a3951
    Betriebsystemversion: 6.1.7601.2.1.0.256.4
    Gebietsschema-ID: 1031
    Zusatzinformation 1: 0a9e
    Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
    Zusatzinformation 3: 0a9e
    Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789

    Ich habe Avisynth 2.6 laufen. Sollte man trotzdem besser das mt_masktools-25.dll nehmen ?
    script wie folgt:

  • Zitat

    Ich habe Avisynth 2.6 laufen. Sollte man trotzdem besser das mt_masktools-25.dll nehmen ?

    Ich hab mt_masktools-25 [914 KB] und Avisynth MT rennt.

    Hab aber auch SetMemoryMax(512) als oberstes im Script.
    Dann kommen,Import und LoadPlugins
    Quelle
    ConvertToYV12.......
    Ev.noch Crop....
    Erst dann SetMTmode(2)

    ffm2s habe ich nicht,dafür brauche ich Avisynth nicht.

    Rest weiss Didée oder LigH.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Ok, macht nix. mt_masktools-25 crashed auch.
    SetMemoryMax(512) für HD Material erscheint mir etwas wenig ...

    ConvertYUY2() ist nur um VirtualDubMod unter win7 nutzen zu können

  • Der zweite Parameter (Thread-Anzahl) ist nur beim ersten Aufruf von SetMTMode sinnvoll.

    Auch bezweifle ich, dass CoreAVC via DirectShowSource so extrem viel schneller und auch noch zuverlässig genug ist, im Vergleich zu anderen Methoden. Aber das kann ich nicht selber testen.

  • Zitat

    Ok, macht nix. mt_masktools-25 crashed auch.
    SetMemoryMax(512) für HD Material erscheint mir etwas wenig ...

    Hab auf Win7 64 Bit und unter XP Avisynth 2.60 MT am Laufen.Aber die 32 Bit.Version von Avisynth und soeben nochmals nachgeschaut auch nur die 25.dll von MT_masktools....aus dem QTGMC-Paket.
    Wobei auf einem PC [i7 2600K 8GB Ram] abwechslungsweise mit W7 oder mit XP gearbeitet werden,2 sep.HDDs natürlich.
    Also insgesamt eine Avisynth Version aber auf 3 Systemen.

    SetMemoryMax habe ich von ursprünglich 1024 auf 888 und dann auf 512 runtergesetzt.
    Kann mir zwar vorstellen dass das zuwenig ist für HD Material.Das muss ein anderer Anwender ausprobieren.
    Weiss eigentlich gar nicht warum ich Avisynth einsetzen soll für HD Material,meine anderen Tools reichen da aus.

    Zitat

    ConvertYUY2() ist nur um VirtualDubMod unter win7 nutzen zu können


    Ja,der mpc zeigt kein Bild an bei YV12,VDubMod egal ob die V.2 oder die "Neuere" V3 wie auch VirtualDub 1.9.11 könnens aber.

    VDub fehlt hier auf keinem PC,ohne dies fühle ich mich nackt und das bei diesen winterlichen Temps.nee.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Grundsätzlich masktools-25 für Avisynth 2.5, masktools-26 für Avisynth 2.6. Das passt schon, und der Fehler liegt auch nicht bei den MaskTools. Höchstwahrscheinlich ein Speicherproblem (zuwenig desselben), und weil im TGMC ziemlich viele Operationen mit den MaskTools durchgeführt werden, gibt es halt eine relativ hohe Wahrscheinlichkeit, dass der Schwarze Peter im Moment des Crashs gerade bei den MaskTools sitzt.

    Das Script von hier und heute braucht ca. 1.7 GB, nur für Avisynth.

    Wenn dann noch ein Encoder hinterherkommt, womöglich noch x264, womöglich mit etwas aufwändigeren Einstellungen, dann knallt's schneller als man "Huch" sagen kann.


    Jedes Windows kommt mit dem Taskmanager daher. Selbigen bitte benutzen, um nachzuschauen, wie die Speicherzuweisungen aussehen. Faustregel: wenn irgrendein "Arbeitssatz" oder die "zugesicherte Größe" über 1'700'000 hinausgeht, dann wird die Luft langsam dünn.

  • LigH: Hab zur Zeit nichts anderes als den CoreAVC da sich DiAVC auf win7 nicht aktivieren läßt. Hab DG schon was auf dem doom9 board gepostet, der sagt aber: "richtie dich an den DiAVC support" ... OMG ob dabei was rauskommt.
    Ansonsten bleibt ja der FFMPegSource, aber der hat ja besagte "Probleme" wenn das interlace Material nicht gaz so sauber ist - und das kommt bei BVB-S(2) schon mal vor ;)
    BTW: Es gibt auch Leute die keine NVIDIA Grafikkarten besitzen...

    Goldwingfahrer : Ich benutze ebenfalls die 32-Bit Version auf einem 64-Bit Win 7 System. Bin jetzt wieder umgestiegen auf die masktools-26 und nachdem ich den ganzen Prozess mit 'avs2pipe' (gcc Version) getrennt habe läuft es erst mal (mal schauen wie lange).

    Didée: Ich habe den Speicher jetzt auf 1000 begrenzt - laut Taskmanager geht die Speicherauslastung jetzt nur auf ca. 1200 hoch und durch den avs2pipe hat x264 seinen eigenen Thread mit ca 250 - 300 MB.
    Das mit dem SetMemoryMax() ist mir immer noch nicht so ganz klar. Obergrenze hin oder her, es scheint als ob Avisynth trotzdem auch mehr allokieren kann und tut wenn dies notwendig wird.
    Ansonsten bleibt die Frage: Wie kommt man auf einen vernünftigen Wert für's Speichermanagement ? Bei x264 könnte man mit dem lookahead spielen aber bei Avisynth ... ?

  • bleibt die Frage: Wie kommt man auf einen vernünftigen Wert für's Speichermanagement ?


    Mit nichts könnte man diese Frage treffender beantworten, als mit einem Zitat von Lennard "Pille" McCoy:

    "Schätzen, Mr. Spock! Sie sollen SCHÄTZEN!"


    Zitat

    Das mit dem SetMemoryMax() ist mir immer noch nicht so ganz klar. Obergrenze hin oder her, es scheint als ob Avisynth trotzdem auch mehr allokieren kann und tut wenn dies notwendig wird.


    Genau so ist es. :)

    SetMemoryMax bestimmt "nur", wie groß der Framecache von Avisynth maximal werden darf. Zum Gesamt-Speicherbedarf gehören aber noch ein paar andere Kleinigkeiten dazu. Nur ein Beispiel: Jeder x-beliebige Plugin/Filter kann "seine eigenen" Speichersegmente verwenden, um seinen Filter-Job zu erledigen (Lookup-Tables oder sonstwas). Dieser Speicher zählt natürlich zu dem Speicher den Avisynth verbraucht, unterliegt aber nicht der "Verwaltung" von Avisynth. Deswegen ist der tatsächliche Speicherbedarf üblicherweise höher als das, was man mit SetMemoryMax angegeben hat.

    Und deswegen ist die weitverbreitete Formel "viel hilft viel" hier wieder mal falsch. Bei SetMemoryMax gilt eigentlich: SO klein WIE MÖGLICH. Abhängig vom jeweiligen Script gibt einen Mindestwert "X" für SetMemoryMax, ab dem das Script optimal läuft. Setzt man den Wert größer, gewinnt man nichts mehr.
    Die Untergrenze ist aber genau so schwierig. Es gibt eine kritische Untergrenze, unterhalb dessen ein Script nicht funktioniert. (manche Versionen geben tatsächlich die Fehlermeldung "Ooops, it seems we've run out of memory, folks!" aus.) Das ist aber selten das Problem. Häufiger kann es sein, dass ein Script mit uz kleinem SetMemoryMax durchaus funktioniert, nur eben zu langsam: wenn der Frame-Cache zu klein ist, um alle "Zwischenergebnisse" zu cachen, die zur Berechnung des aktuellen Frames notwendig sind, dann muss ggf. eben eine (/mehrere, /viele) bereits durchgeführte Berechnung(/en) nochmal durchgeführt werden.


    Ergo: es bleibt schwierig. :)


    Zur "Entschuldigung" von Avisynth muss man sagen: das grundlegende Framework ist schon ziemlich alt. Als Ben Rudiak das Ding im Jahr 2000 erfunden hat, da hat er wohl nicht damit gerechnet, wie sich der Speicherbedarf mit den Jahren entwickelt würde. Anno 2000 hatte man im Home-PC typischerweise 64 MB RAM drin, mit 128 MB war man König, und die 2GB-Prozessgrenze war eher ein "theoretischer" Wert, der kaum jemanden wirklich interessiert hat.

  • Wenn SetMemoryMax nur den FrameCache beinhaltet, ist 512MB dann nicht schon ne Menge?
    1920*1080 = 2073600pixel
    32 Bit = 4 Byte (32bit sollte mit Avisynth 2.0 ja theoretisch möglich sein, ob in der Praxis alle Filter soviel Bit unterstützen ist wieder ne andere Sache)
    -> 1 FullHD Bild wären also ca. 8MB, und 512MB wäre Platz für 64Bilder

  • Ja, und? Da kannste mal sehen, wie schnell sowas weggeht. Mit MVTools geht das ganz fix ... und das obwohl die Werte kleiner sind. Q/TGMC rechnet ja (normalerweise) alles in YV12, also nur ca. 12bit pro Pixel.

    Hier schonmal angedeutet

    Mit pel=2 ist der Super-Clip eines 1920x1080-Clips schon mal 1936x5614 groß. MDegrainX erstellt intern kompensierte Frames. Plus die explit kompensierten Frames für den temporalen LMode. Bei doppelter Anwendung ala "clip.Mdegrain.Mdegrain" muss der ganze Super+Mdegrain Rotz erst einmal berechnet werden, aufs Ergebnis kommt erneut ein MSuper und wiederum MDegrain. Davor, dazwischen und danach finden haufenweise kleine Clip-Manipulationen statt. Fang' mal an zu rechnen. Und dann will ja noch MT machen, schließlich hat man ja soo viele Kerne die man unbedingt nutzen muss. Mit MT wächst der (vorher schon ernorme) Speicherbedarf nochmal linear unter O(n) - der lineare Faktor ist zwar deutlich kleiner als 1, aber trotzdem. Lass die 1Thread-Belastung 1.2GB sein, plus *0.12 für jeden Thread. Jetzt rechne nochmal. (Bzw. das, was Pille dem Spock empfohlen hat.)

    Gerade bei "temporaler Verkettung/Verschachtelung" verbrauchen die MVTools Speicher mit einer solchen Großzügigkeit, dass einem z.B. ... nein, ich sag nicht was mir in den Sinn kommt. Politische Bemerkungen besser vermeiden.


    Wie schon mehrfach erwähnt:

    "Wenn MVTools nur 1% so viel Developer-Power erhalten würde wie x264, dann wäre vieles viel besser."

    Mit 0.000000001% Entwicklungspower geht nix vorwärts, und es bleibt halt, wie es ist.

  • Die Frage ist kann man den Speicherbedarf eines Skriptes abschätzen und so zu verhindern das man Skripte startet die mehr Speicher brauchen als zur Verfügung stehen?
    Interessiert mich vor allem, weil ich Avisynthskripte in Hybrid als Input akzeptiere und so eventuell schon vor der Joberstellung&Co angeben kann, dass ein Skript wohl vermutlich crashen wird.

    Cu Selur

  • Wenn ich nicht sicher bin und schätzen will, dann mache ich folgendes:

    - SetMemoryMax(1500) am Anfang (wenn 1600~1700 nicht zum Öffnen reichen sollte, braucht man eigentlich eh' nimmer weitermachen)

    - Taskmanager öffnen

    - Script in Vdub öffnen, im Taskmanager die Speicherbelegung von Vdub anschauen. Die Belegung direkt nach dem Öffnen ist so ne Art Minimum.

    - zwei- bis fünfmal mal Pfeil-rechts, dann nochmal die Speicherauslastung anschauen. Das wäre dann das wünschenswerte Maximum.

    Beide Werte jeweils minus 10 Prozent, wg. Vdub selbst, und wg. Avisynth-Tralala der nicht mit dem Framecache zusammenhängt.
    => sehr ungenau und hemdsärmelig, aber man kriegt 'ne einigermaßen realistische "Hausnummer".


    Glaube nicht, dass man den Speicherbedarf (sinnvoll) programmatisch ermitteln kann. Wenn das so einfach wäre, dann hätte IanB sicher schon sowas wie einen ShowMemoryAllocation() Befehl eingebaut.

    Wenn's speziell um QTGMC geht (gibt ja fast nix anderes was so viel Speicher belegt - MCTemporalDenoise ist auch noch so ein Monster, und vielleicht noch AnimeIVTC), dann könnte man verschiedene Szenarien vor-testen (Faktoren: a) Frame-Dimensionen und b) QTGMC-Presets), und die ermittelten Erfahrungswerte dann bei der Scripterstellung anwenden.

  • Zitat

    Wenn's speziell um QTGMC geht (gibt ja fast nix anderes was so viel Speicher belegt - MCTemporalDenoise ist auch noch so ein Monster, und vielleicht noch AnimeIVTC), dann könnte man verschiedene Szenarien vor-testen (Faktoren: a) Frame-Dimensionen und b) QTGMC-Presets), und die ermittelten Erfahrungswerte dann bei der Scripterstellung anwenden.


    Nicht nur, aber auch. :) -> werde mal die Tage diesbezüglich mal ein paar Daten sammeln

  • Hm, da Windows (im Gegensatz zu Linux) nicht sehr gesprächig ist was die Speicherauslastung einzelner Module angeht, bestände da nicht die Möglichkeit mit einem "geeigneten" (?) debugger das Ganze mal zu verfolgen ?
    Eine weitere Frage währe sicher wieviele Frames den Q/TGMC "auf Vorrat" speichert bevor er sie an x264 weitergibt. Deshalb ja meine Idee den lookahead von x264 zu verkleinern. Dann braucht nicht eine so große Vorratsdatenspeicherung (:D) zu erfolgen. Oder liege ich da falsch ...

  • Von AviSynth wird eigentlich immer nur Bild für Bild angefordert, insofern haben x264-Parameter eigentlich keine Auswirkungen auf den Speicherverbrauch von AviSynth. Soweit ich das verstehe...

    Aber wenn sich x264 und AviSynth bei 32-bit-Adressierung ein 2-GB-Segment teilen, dann ist eine ausgewogene Belegung sicher nützlich.

  • LigH: Bin deshalb jetzt auf avs2pipe umgestiegen. Habe aber noch keinen erfolgreichen Test absolviert ...

    Selur: Wenn "immer nur ein Frame" von AviSynth geliefert wird, dann sollte sich doch der Speicherbedarf unter Einbeziehung eines Worst-Case-Szenarios (z.B Szenensprung - da ändert sich besonders viel zum Vorgängerbild) doch berechnen lassen...
    Ich weiß zwar nicht wie Didée auf die Werte aus Post #10 kommt aber folgt man diesem Beispiel so kommt man auf ca. 25MB pro Bild - bleibt die Frage wieviel davon vorrätig gehalten werden. Ich hätte auf +/- 3 geschätzt ...

  • Was Du übersiehst ist, dass Avisynthfilter&-skripte zur Berechnung eines einzelnen Frames eventuell mehrere andere Frames im Speicher halten. :)
    Wenn man z.B. temporal Filtert ist nicht nur ein Frame im Speicher, sondern:
    1. das Source Frame
    2. die angrenzenden Frames (die bei der temporalen Betrachtung angeschaut werden)
    3. eventuelle modifizierte Kopien der einzelnen Frames
    4. das Ergebnis Frame
    Komplizierter wird es dann in der Berechnung noch wenn sich Parameter wie Farbsampling, Auflösung usw. zwischen den einzelnen gespeicherten Frames unterscheiden und diese Frame alle zusammen wieder durch andere Scripte gejagt werden.

    Zitat

    bestände da nicht die Möglichkeit mit einem "geeigneten" (?) debugger das Ganze mal zu verfolgen ?


    Sicher, dass würde aber voraussetzen, dass man alles komplett als Sourcecode vorliegen hat, kompiliert und dann in einem DebugMode laufen lässt, dann könnte man sicher mit Valgrind und Vergleichbarem einiges Aussage, das ist allerdings ein riesiger Aufwand der einiges an Wissen von dem der ihn durchführen will erfordert,.. (vor allem, wenn der Sourcecode nicht in einer einzelnen Sprache geschrieben worden ist; das debuggen jeder einzelnen .dll ist sicher nicht praktikabel)

    Cu Selur

  • Auch wenn's Selur schon beantwortet hat ..... das folgende hab ich vorhin Offline geschrieben, also wird's auch gepostet. ;)

    --------------------------------

    Zitat

    Ich weiß zwar nicht wie Didée auf die Werte aus Post #10 kommt

    Nach der McCoy'schen Schätz-Methode. Siehe Post#12.

    (Sprich: Auf die Zahlen brauch'st mich nicht festnageln, und erst recht nicht anderswo zitieren. Zwar sind die Zahlen "nicht unrealistisch", tatsächlich bleiben es aber aus der Luft gegriffene Phantasiezahlen. Es ging nur ums Grundprinzip.)


    Zitat

    folgt man diesem Beispiel so kommt man auf ca. 25MB pro Bild

    Aber es ist nicht so einfach. Es ist viel schwieriger.

    Beispiel:

    a) TemporalSoften(3,x,x) => Avisynth muss 7 Quell-Frames gleichzeitig im Speicher halten.

    Sinnbild: der Jongleur balanciert eine Stange. Auf jedem Ende liegen 3 Teller.

    b) TemporalSoften(3,x,x).Temporalsoften(3,x,x) => Avisynth muss auf 7 Quellframes zurückgreifen, die Filterung durchführen, ... und das insgesamt 7 Mal, um dann 7 bereits gefilterte Frames im Speicher zu halten, und hernach den 2. Filterschritt durchzuführen. (Bedingt Zugriff auf 13 Source-Frames für einen Output-Frame, und zwischendurch muss so einiges "gecached" werden.)

    Sinnbild: der Jongleur balanciert eine Stange. Auf jedem Ende liegt wiederum jeweils eine Stange, auf deren Enden wiederum jeweils drei Teller liegen.

    Na, merkt man schon, dass es komplexer wird? Möchte jemand die Jonglage b) ausprobieren? Mit dem eigenen Geschirr?

    Und dabei ist das noch Baby-einfach.


    Anderes Beispiel:

    (A)
    v1 = last
    v2 = v1.Filter1()
    v3 = v2.Filter2()
    v4 = v3.Filter3()
    v5 = v4.Filter4()
    return v5

    Das ist eine rein lineare Filterkette. Cache-Pressure ist sehr gering. Nicht der Rede wert.


    (B)
    v1 = last
    v2 = v1.Filter1()
    v3 = v2.Filter2()
    v4 = v3.Filter3()
    return stackhorizontal(v2,v3,v4,v5)

    Und gleich wird es anders. Bei A) könnte jeder "Zwischenschritt" vom Prinzip her sofort "verworfen" werden, sobald der nächste Zwischenschritt fertig berechnet ist. Nun aber in Beispiel B) müssen ALLE gleichzeitig im Speicher gehalten werden (weil sie wiederverwendet werden).
    Diesen Umstand ist z.B. in TGMC sehr häufig: am Anfang wird etwas berechnet, dann kommen "hunderte" andere Operationen, und gegen später wird wieder irgendwas gegen das vom Anfang verrechnet.


    (C)
    v1 = last
    v2 = v1.Filter1()
    v3 = v2.Filter2()
    v4 = v3.Filter3()
    stackhorizontal(v2,v3,v4,v5)
    TemporalSoften(3,x,x)
    return(last)

    Diesen Fall erkläre ich jetzt nicht. "Left as an exercise for the reader." ;)


    Nur weil etwas harmlos aussieht (ein Script aus 5 Zeilen kann doch nicht sonderlich "komplex" sein, wenn es 1000-Zeilen-Scripte gibt, die schnell+problemlos laufen?!?), muss es noch lange nicht harmlos SEIN. Komplexitäten durch gegenseitige Abhängigkeiten können sehr schnell explodieren. Und insbesondere die Abhängigkeiten von Temporal-Filtern sind Dynamit.


    Vergleiche z.B. Das Schachbrett-Reiskorn-Szenario. Ein Korn, zwei Körner, vier Körner ... gäääähhhn, langweilig ... aber hoppla, für das 64. Feld bräuchte man zusätzliche Planeten, um dort Reis anzubauen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!