Avisynth, Virtualdubmod und der Ramverbrauch

    Ich habe hier ein Avisynth-Script mit

    22 avcsource Quelldateien (1080p)
    66 trim Befehlen
    2 Dissolve Aufrufen
    1 Black-Clip Aufruf

    Pro trim Befehl wird eine Variable erzeugt (video01, video02...).

    Insgesamt sind das also 22+66+2+1 = 91 Variablen.

    Nachdem die Schnitte via + konkateniert sind erfolgt noch ein Crop und ein Lanczosresize.

    Das Script funktioniert und lässt sich in Virtualdubmod vom ersten bis zum letzten Frame betrachten.
    Spiele ich das Script in VDM ab steigt der Ramverbrauch bis auf 500mb +-30mb.
    Encode ich es allerdings (XviD), steigt der Ramverbrauch auf über 546mb und der Encodingvorgang stoppt ohne Abbruch. Die CPU-Last klettert in dem Moment von 30% auf einem 6-Kern System auf runde 90%.

    Was könnte ich da nun tun? Hab bereits sehr kleine setmemorymax(16) und serh große probiert (2048).

    Edit: Im moment müht sich gerade xvid_encraw damit ab. Bisher sieht es gut aus, ich hoffe nur ich hab alle Settings richtig übertragen.
    Edit2: Auch xvid_encraw blieb irgendwann stehen. Jetzt ackert x264 dran herum.

    4 Mal editiert, zuletzt von -TiLT- (10. Dezember 2010 um 15:20)

    So, ein kleiner Push:

    Habe das ganze jetzt mit x264 encoded, in 2 Passes und keine Probleme dabei gehabt. Der Ramverbrauch ging dabei auf annährend 2GB rauf.

    Wenn ich jetzt drauf tippen müsste, würde ich sagen, damit kommt XviD nicht zurecht.

    Könnte ihr mir vielleicht helfen mein Script weniger Ramhungrig zu gestalten? Hier ist es:

    Zitat

    Der Ramverbrauch ging dabei auf annährend 2GB rauf.


    liegt vermutlich an den lookahead-Einstellungen in x264

    Zitat

    Könnte ihr mir vielleicht helfen mein Script weniger Ramhungrig zu gestalten?


    Nur mal so am Rand kann man nicht einfach ein .dga file über alle files machen, so dass man nur eine Videoquelle hat und diese dann schneiden?

    Wie, "einmal"?

    Trim() kopiert einen Ausschnitt aus einem Clip in einen neuen Clip. Wer also aus einem langen Stück mehrere kurze Stücke braucht, der sollte das lange Stück in einer Variablen aufbewahren, solange es gebraucht wird. Und ja, die kurzen Stücke existieren erst mal einzeln, bevor sie wieder zusammengesetzt werden.

    Hinweis: Immer die selbe Variable - auch "last" implizit - durch Trim() mehrfach nacheinander zu zerstückeln kann gewisse Nebenwirkungen haben, wenn man nicht ganz genau über die Framenummernverschiebung nachdenkt.

    Zitat von Selur

    Nur mal so am Rand kann man nicht einfach ein .dga file über alle files machen, so dass man nur eine Videoquelle hat und diese dann schneiden?

    Wäre sicherlich möglich gewesen, ich habe nur nicht damit gerechnet, dass ich derartige Probleme bekommen werde. Würde ich das jetzt machen, müsste ich sämtliche Schnitte umrechnen.

    Vielleicht lässt sich ja Avisynth anweisen, dass es für lineares encoding nicht mehr benötigte Anteile aus dem Ram entfernt (sollte es das nicht sowieso tun)?

    Na, das wage ich mittlerweile zu bezweifeln, Selur. So dermaßen "unoptimiert" ist AviSynth bestimmt nicht. Vielleicht braucht man wirklich nur ein paar Tipps von den Entwicklern im englischen doom9-Forum, wie man mit seinem eigenen Skriptaufbau AviSynth dabei helfen kann, Sparpotenzial frühzeitig zu erkennen.

    LigH: sehe ich schon so,.. :)
    Ist zwar einiges besser geworden mit 2.58 und die einzelnen Routinen werden zwar effizienter, aber soweit mir bekannt ist die generelle Speicherverwaltung immer noch weit davon entfernt 'Sparpotenzial frühzeitig zu erkennen'.
    Ist generell aber schwer zu sagen, was sich bei Avisynth so tut, da die Changelogeinträge ja bewusst kurz gehalten sind.

    Also spontan fallen mir 2 Sachen dazu ein, entweder du versuchst ein paar Schnipsel zu einem großen verlustfreien zu encoden und wieder einzu binden.
    Also z.B.:

    Zitat

    video19 = trim(source07,0,1475)
    video20 = trim(source07,1502,5588)
    [...]
    video37 = trim(source11,0,11829)
    video38 = trim(source11,12182,16772)

    zu Source2.avi encoden

    Oder wenn Variablensparen hilft mal sowas versuchen:
    Statt immer eine neue variable pro trim zu erstellen, einfach viele trims kombinieren.

    Bsp:

    video02 = source2.trim(0,4749) + source02.trim(7225,8254) + source02.trim(8351,8508) + ... + source02.trim(11763,12066)


    Ein Vesuch ist es wert^^


    Achja, VdubMOD verbraucht mehr Ram als ein aktuelles Vdub!!
    Bei mir lag der Unterschied bei ca. 200MB (VdubMOD ~600MB, Vdub 1.9.10 ~400MB)

    Laut englischem Forum sollte es wohl vorteilhaft sein, möglichst wenige Source-Filter zu verwenden, und der Cache kann gering gehalten werden, da ja nur Schnittfunktionen genutzt werden. Also Selurs erster Vorschlag - ein dga-Index über alle - könnte bereits der beste sein.

    Dann ist jetzt im Prinzip die Sache geklärt, außer, dass noch unklar ist, ob man die Quelldateien vor dem Indexieren konkatenieren muss, oder ob es reicht die Quelldateien auf einmal an DGAVCIndex zu überreichen.

    Und ich schau mal, dass ich hier irgendwie 100GB für einen lossless x264 zusammenkratzen kann.

    Welche Softwaredecoder können lossless x264 verarbeiten? Ich meine mal gelesen zu haben, dass da nicht jeder Decoder mitspielt.

    Hm, oder ob man das irgendwie noch mit mplayer/mencoder durchpipen kann... *kopfkratz*
    Nie gemacht leider.

    Ligh: Vielen lieben Dank fürs Durchreichen zu Doom9!

    Hm, ffdshow wäre ne Idee. Lossless x264 hatte ich angedacht, weil x264 das Script ja einwandfrei rendert. Ausreichend Ram ist ja vorhanden, das Problem liegt ja anscheinend am Ramlimit von XviD.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden