Wie viele Threads verwendet ffmpeg standardmäßig?

Ich sehe, dass es eine -threads <count>Befehlszeilenoption in ffmpeg gibt. Was ist der Standardwert dieser Option?

Dies hängt vom verwendeten Codec, der ffmpeg-Version und der Anzahl der CPU-Kerne ab. Manchmal ist es einfach ein Thread pro Kern. Manchmal ist es komplexer wie:

Bei libx264 sind dies Cores x 1.5 für Frame-Threads und Cores x 1 für Slice-Threads.

Ab 2014 wird eine optimale Anzahl verwendet.

Sie können dies auf einem Multi-Core-Computer überprüfen, indem Sie die CPU-Auslastung (Linux : top, Windows: Task-Manager) mit verschiedenen Optionen für ffmpeg untersuchen:

• -threads 0 (optimal);

• -threads 1 (Single-Threaded);

• -threads 2 (2 Threads für zB einen Intel Core 2 Duo);

• none (Standardeinstellung, auch optimal).

2015 edit: Auf einer 12-Kern-CPU haben einige ffmpeg-Befehle Linux topmit höchstens 200% CPU (nur 2 Kerne), unabhängig von der Anzahl der Kerne -threads. Die Standardeinstellung ist also möglicherweise immer noch optimal im Sinne von "so gut wie diese ffmpeg-Binärdatei sein kann", jedoch nicht optimal im Sinne von "Meine leere CPU voll ausnutzen".

In 2015 unter Ubuntu 14.04 mit ffmpeg 0.8.10-6 wurde 1 Kern auf einem 4-Kern-System verwendet. htopzeigte dies; Es wurde nur ein Kern verwendet, und ich habe eine Konvertierungsrate von 16 fps für ein FullHD-Video erhalten.

Wenn -threads 4ich alle meine CPU-Kerne zu 100% ausnutze, erhalte ich eine Konvertierungsrate von 47 fps.

Ich habe den folgenden Befehl verwendet:

$ ffmpeg -i foo.mp4 -y -target pal-dvd -aspect 16:9 dvd-out.mpg

Einige dieser Antworten sind ein bisschen alt, und ich möchte nur hinzufügen, dass bei meiner ffmpeg 4.1Codierung mit libx264alle 6 Kerne / 12 Threads meines Ryzen 5 2600X-Systems ohne -threadArgumente ausgereizt wurden .

Ich habe mit der Konvertierung in eine CentOS 6.5 VM gespielt (Ryzen 1700 8c / 16t - vm hat 12 von 16 Kernen zugewiesen). Experimente mit 480p-Filmen ergaben folgende Ergebnisse:

Thread-Option / Conversion-Rate (fps @ 60 secs)

(none/default)/130fps
-threads 1/70fps
-threads 2/120fps
-threads 4/185fps
-threads 6/228fps
-threads 8/204fps
-threads 10/181fps

Der interessante Teil war das Laden der CPU ( htopum es zu beobachten).
Verwenden Sie keine -threadsOption, die im Bereich von 130 fps mit einer auf alle Kerne verteilten Last bei niedriger Last aufgewickelt wurde.
Die Verwendung von 1 Thread hat genau das bewirkt und einen Kern zu 100% geladen. Die Verwendung von etwas anderem führte zu einer anderen Spread-Load-Situation.

Wie Sie sehen, ist auch die Rendite rückläufig, sodass Sie die Option -threads für Ihren bestimmten Computer anpassen müssen. Speziell für mein Setup ergab die Verwendung von -threads 6 (auf einem 12-Core-Computer) die besten FPS beim Konvertieren des Videos (von h264 zu x264 mit einer anderen Bitrate, um eine Konvertierung zu erzwingen) und die Rückgaben verringerten sich tatsächlich, je mehr Threads ich hineingeworfen habe es.

Es könnte auch ein Speicherproblem gewesen sein - der VM wurde nur 1 GB zugewiesen. Ich kann das optimieren und sehen, ob sich etwas ändert. Trotzdem zeigt sich, dass die Verwendung dieser -threadsOption die Leistung steigern kann. Führen Sie daher einige Tests auf Ihrem bestimmten Computer auf verschiedenen Ebenen durch, um den Sweet Spot für Ihre Setups zu finden.

Vorausgesetzt, Sie haben Threading aktiviert, wurden 1,5-mal so viele Kerne zugewiesen.