x264 nutzt die CPU nur zu unter 50% aus

[FatManStanding]

tach,

ich nutze unter ubuntu den x264-encoder um meine videos einzudampfen. der nutzt die cpu aber nur zu unter 50% aus (meist zwischen 39 und 45%). wieso? ich finde keine einstellungen um das zu beschleunigen. gibt es hier einen anderen flachenhals? die x264-cli lautet:

x264 --preset veryfast --pass 1 --bitrate 7700 --profile high --level 4.1 --keyint 24 --min-keyint 1 --b-pyramid strict --sync-lookahead 9 --rc-lookahead 12 --slices 4 --qpmin 10 --qpmax 51 --weightp 2 --threads 6 --sar 1:1 --stats file.stats --output output.mkv input.mkv
x264 --pass 2 --bitrate 7700 --profile high --level 4.1 --ref 4 --keyint 24 --min-keyint 1 --b-pyramid strict --sync-lookahead 9 --rc-lookahead 12 --slices 4 --qpmin 10 --qpmax 51 --trellis 0 --psy-rd 1.00:0.0 --vbv-maxrate 62500 --vbv-bufsize 78125 --threads 6 --sar 1:1 --stats file.stats --output output.mkv input.mkv

ein paar hardware-infos:

Beschreibung: CPU
       Produkt: AMD Ryzen 5 1600 Six-Core Processor
       Hersteller: Advanced Micro Devices [AMD]
       Physische ID: 2c
       Bus-Informationen: cpu@0
       Version: AMD Ryzen 5 1600 Six-Core Processor
       Seriennummer: Unknown
       Steckplatz: AM4
       Größe: 1356MHz
       Kapazität: 3700MHz
       Breite: 64 bits
       Takt: 100MHz

insgesamt 16gb arbeitsspeicher

Beschreibung: DIMM DDR4 Synchron Unbuffered (Unregistered) 2133 MHz (0,5 ns)
          Produkt: F4-3000C16-8GISB
          Hersteller: G-Skill
          Physische ID: 1
          Seriennummer: 00000000
          Steckplatz: DIMM_A2
          Größe: 8GiB
          Breite: 64 bits
          Takt: 2133MHz (0.5ns)

 

[ghecko]

Ist dabei ein einzelner Kern bei 100% ?
Dann nutzt du irgendeinen Filter, der nicht parallelisiert werden kann und auf den die restlichen Threads warten.

//nvmd:

--threads 6

Das sollte wohl 12 sein, sonst nutzt du nur die Hälfte aller verfügbaren CPU-Ressourcen.
6-Kern CPU mit SMT -> 12 Threads.

 

[madmax2010]

Beschreibung: DIMM DDR4 Synchron Unbuffered (Unregistered) 2133 MHz (0,5 ns)

ab auf 3000mhz damit, falls der aegis das schafft..

x264-cli

welche von wo in welcher version? kann gut sein, dass du da einfachw as steinaltes hast

mal ffmpeg probiert?

Wenn du keinere dateien und bessere Qulitaet willst wuerde ich glaich nach h265 gehen

 

[007JamesBond]

Jetzt mal ganz dumm gefragt:
Warum nutzt du diese ganzen Optionen?
Konkret z.B. "--threads 6" und "--slices 4"
Ich kenne mich jetzt nicht mit x264 aus, aber alleine threads=6 scheint schon suboptimal zu sein.
Da würde ich mindestens auf 12 stellen, da der Ryzen 5 1600 ja 12 Threads bearbeiten kann (mit aktiviertem SMT)
Und wenn man nicht weiß, was man tut sollte man solche Optionen weglassen und die Standardwerte/Automatik benutzen...

 

[Amaoto]

Wo liest du denn die Auslastung ab?
Evtl. hast du SMT aktiv und die ~50% ist die Auslastung der logischen (nicht der physischen) Kerne.

 

[madmax2010]

Da würde ich mindestens auf 12 stellen, da der Ryzen 5 1600 ja 12 Threads bearbeiten kann (mit aktiviertem SMT)

das ist beim encoden wenig sinnvoll. Multithreading bringt dann Vorteile, wenn die CPU beim Kontextwechsel auf IO warten muss
kann man schon machen und schadet auch nicht, der speedup ist eher marginal. wenn man den parameter nicth uebergibt, defaultet ffmpeg auf threads = floor(cores*1.5)

 

[ghecko]

das ist beim encoden wenig sinnvoll. Multithreading bringt dann Vorteile, wenn die CPU beim Kontextwechsel auf IO warten muss

Mit Auslastung aller Threads kann man je nach Material gut 30-40% rausholen. Lohnt sich durchaus.

 

[up.whatever]

Probier's doch mal mit einem passenden preset und lass die ganzen anderen Parameter weg. Und 2-pass mit fester Bitrate ist nur dann sinnvoll, wenn du eine vorgegebene Dateigröße treffen musst, sonst ist der CRF Modus eigentlich immer besser.

 

[FatManStanding]

die x264-version ist die aktuelle r2917. das ist die aktuelle aus dem ubuntu-repo. das problem hab ich schon länger, scheint also unabhängig von der version zu sein. auch das "weglassen der ganzen anderen parameter" bringt da nichts.

ich habe aber eine andere vermutung, dass es am decodieren der quelldatei liegt. aktuell rechnet x264 mit um die 60fps. bekommt man irgendwie (z. b. über einen x264-log) heraus, ob x264 einfach nicht mehr daten verarbeiten kann, weil es durch das decodieren der quelle nicht mehr bilder pro sekunden bekommt?

ich guck mal ob ffmpeg mit libx264 bessere ergbnisse liefert. da müsste ich aber erst die command line anpassen, glaube ffmpeg nutzt da andere einstellungen.

 

[ghecko]

ich habe aber eine andere vermutung, dass es am decodieren der quelldatei liegt.

oder einfach mal kurz den threadcount auf 12 erhöhen? ist ziemlich sicher die Lösung.

 

[sTyLzYo]

stell mal von veryfast auf fast oder medium, und wie schon erwähnt die anzahl der threads erhöhen

qualität wird dadurch erhöht, kostet aber auch mehr leistung

 

[Angel Of Death]

Standardgemäß wählt x264 das 1,5-fache der CPU-Cores als Threads. Wären beim 1600 also 18 (12x1,5)
Entweder diesen Parameter weglassen oder eben --threads 18
Dann sollte die Auslastung bei 99-100% liegen.

 

[FatManStanding]

die threads hochzusetzen ändert wie zu erwarten war nichts. denn wie schon gesagt hab ich das ganze auch komplett ohne den parameter --threads versucht und x264 die standardwerte nutzen lassen - hatte auch keinen effekt.

aber: ffmpeg mit libx264 nutzt im 1 pass knapp 65% und im 2 pass dann 95%.

ffmpeg -i input -c:v libx264 -preset veryfast -pass 1 -b:v 4000k -profile high -level:v 4.1 -x264-params keyint=24:min-keyint=1 -b-pyramid strict -slices 4  -f null /dev/null
ffmpeg -i input -c:v libx264 -preset veryfast -pass 2 -b:v 4000k -profile high -level:v 4.1 -x264-params keyint=24:min-keyint=1 -b-pyramid strict -slices 4 output

 

[Angel Of Death]

Achso wenn es um den First Pass geht dann ist es wohl normal, wenn nicht "slow first pass" aktiviert ist.

 

[FatManStanding]

Der 1 pass scheint immer langsamer zu sein, bei x264 gehen aber beide langsam und bei ffmpeg nicht. ich vermute weiterhin den input-filter als flaschenhals.

 

[Bob.Dig]

Warum überhaupt two-pass? Nutzt man heute eigentlich nicht mehr.

 

[FatManStanding]

Was hat sich denn 'heute' zu 'gestern' geändert?

 

[ghecko]

Was hat sich denn 'heute' zu 'gestern' geändert?

Heute muss eine Filmdatei nicht mehr genau auf eine 700MB große CD passen. Es macht halt einfach keinen Sinn mehr, auf eine gewisse Größe hin zu kodieren, wenn die eigentliche Maßeinheit eine konstante Qualität des Bildmaterials sein sollte.

Der erste Pass verschwendet also nur deine Zeit und Energie, das Ergebnis wird sowieso verworfen und dient nur als Referenz, damit die finale Größe beim 2. Durchgang passt.

 

[FatManStanding]

Mit einem quantizer gibst du eine mindestqualität an. Wenn das Material älter ist als so ca. 2005 kann es sein die Dateien werden sehr groß, im Extremfall größer als eine bluray. Das kann z. B. an vertauschten Material liegen. Wenn man dann noch viele Serienepisoden hat die alle sehr groß werden macht ein 2pass sehr wohl Sinn.

 

[Bob.Dig]

@FatManStanding Klar, wenn man weiß was man tut, keine Frage. Man könnte nun aber stattdessen auch hingehen und entsprechende Filter drauf werfen, welche das Ergebnis wieder aufhübschen. Das kostet aber richtig CPU-Power.