MultiThreading mit AviDemux_Cli (Command Line Interface)

  • Hallo,

    kann man MultiThreading bei Avidemux_Cli aktivieren?


    Wenn ich Videos über Avidemux_qt4 mit X264 encode, dann werden hier beide Prozessorkerne ausgelastet.
    Wenn ich das gleiche Projekt mit AviDemux_Cli abarbeite, dann wird nur ein Kern belastet.

    Ich habe die Wiki durch und auch sämtliche Einstellungen in der GUI bzgl. x264 abgegrast, aber nichts gefunden, was mich weiterbringt.

  • Dort stand alles auf Auto.
    Wenn ich es auf "3" stelle, ändert sich nichts. Die Kerne sind in der Summe nur knapp über die Hälfte ausgelastet.


    Ich werd mal im Avidemux-Forum nachfragen.
    Besonders dringend ist es nicht, da ich noch nur eine DualCore-CPU habe und oft mehrere Videos gleichzeitig transcode.

  • Dort stand alles auf Auto.
    Wenn ich es auf "3" stelle, ändert sich nichts. Die Kerne sind in der Summe nur knapp über die Hälfte ausgelastet.

    Du bist aber sicher, dass es in der GUI Version mit exakt den selben Einstellungen funktioniert?

    Der Flaschenhals kann durchaus auch woanders liegen...

  • Oh Schidde.

    Jetzt, da du es sagst, fällt mir auf, dass ich 2 wichtige Sachen unterschlagen hatte. Sorry.

    1. benutze ich die V4532, weil ich nur damit AAC per Kommandozeile verwenden kann

    2. habe ich beim Testen an einigen Einstellungen bei X264 gedreht, die du mir empfohlen hattest.

    Wenn ich die gleichen Einstellungen in der GUI lade, dann lastet die meine CPU auch nicht mehr zu 100% aus.


    Geändert habe ich ausgehend von den Standardeinstellungen der v4532:

    Quantizer=23
    MaxRefFrames=3
    Mixed Refs=an
    Max Consecutive=16
    Adaptive DCT=optimal

    Ich hab das gerade mal ausprobiert und die Einstellungen in obiger Reihenfolge einzeln gesetzt und jedesmal die CPU-Auslastung geprüft.
    Es liegt an Adaptive DCT=optimal.

    Wenn ich das auf "fast", dann bekomme ich 100% CPU-Last.

    Ich habe lange herumprobiert, um die optimalen Einstellungen zu finden und auf dieses Adaptive DCT möchte ich nicht verzichten, weil es die Datei 10 bis 20% kleiner macht, wodurch ich den Quantizer eine Stufe höher stellen kann.

    Das Problem liegt dann wohl nicht an AviDemux, sondern an x264.

    Wenn ich das richtig sehe, dann kann man diese Einstellung in dem offiziellen Release von Avidemux gar nicht machen. Dann hoffe ich einfach mal, dass das noch optimiert wird.


    Danke für den Denkanstoß.

  • Zitat

    Max Consecutive=16
    Adaptive DCT=optimal

    Kein wunder, dass es langsam ist! Die Einstellungen "Adaptive DCT" sollte eigentlich "Adaptive B-Frame Decision" heißen, ist ein "Übersetzungsfehler" in Avidemux. Die Einstellung "Optimal" (--b-adapt 2) ist auf jeden Fall stark zu empfehlen! Sie ist aber recht langsam und bis dato nicht multi-threaded. Daher solltest du die Anzahl der aufeinanderfolgenden B-Frames auf einen sinnvollen Wert vermindern! 16 B-Frames sind mit der "neuen" Methode nicht mehr sinnvoll. Ich würde 3-4 verwenden. Mehr als 4 B-Frames werden ohnehin ganz selten benutzt. Das war übrigens schon früher so...

    Zitat

    Wenn ich das auf "fast", dann bekomme ich 100% CPU-Last.

    Wenig überraschend. Mit "fast" (--b-adapt 1) sind auch 16 B-Frames noch ausreichend schnell. Trotzdem wird er ganz selten wirklich so viele B-Frames setzten!
    Mit "Optimal" (--b-adapt 2) und 3-4 B-Frames wirst du deutlich bessere Ergebnisse erhalten. Insbesondere kommt die neue Methode erheblich besser mit "Fades" zurecht.

    Zitat

    Wenn ich das richtig sehe, dann kann man diese Einstellung in dem offiziellen Release von Avidemux gar nicht machen. Dann hoffe ich einfach mal, dass das noch optimiert wird.

    Du solltest dir auf jeden Fall das aktuelle SVN Build besorgen, das letzte "Milestone" Build ist hoffnungslos veraltet (insbesondere auch die enthaltene x264 Version)


    --[EDIT]--

    Okay, hab gerade gesehen, dass gestern ein neues "Milestone" Build veröffentlicht wurde. Hab auch gleich mal die Seite aktualisiert:
    http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux

    Daher gilt die Aussage mit den SVN Builds vorübergehend erstmal nicht. Zur Zeit ist das "v2.4.4 Final" Build am neusten ;)

  • Nicht zu empfehlen da langsam würde ich ja verstehen aber warum nicht sinnvoll?
    Kannst Du das erklären?

    Ich meinte "sinnvoll" im Sinne des "Kosten/Nutzen" Verhältnis.

    Wenn man mit "--bframe 16" und "--b-adapt 2" enkodiert, dann sieht das Ergebnis ungefähr so aus:

    Zitat

    x264 [info]: consecutive B-frames: 8.4% 52.2% 33.7% 2.8% 0.7% 0.8% 0.3% 0.0% 0.0% 0.4% 0.0% 0.0% 0.0% 0.6% 0.0% 0.0% 0.0%

    Man beachte, dass die erste Zahl für "0" B-Frames steht. Es werden also überhaupt nur in ~3% der Fälle mehr als 3 B-Frames benutz.

    Damit ergibt sich gegenüber "--bframe 3" nur ein marginaler Vorteil, aber es ist auf jeden Fall deutlich langsamer.

    Man handelt sich also viel zusätzlichen Rechenaufwand ein, ohne dadurch ein besseres Ergebnis zu erhalten. Ich nenne das wenig sinnvoll ;)

    Da kann man seine Rechenzeit bei anderen Optionen sinnvoller verbraten...

Jetzt mitmachen!

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