Combien de threads ffmpeg utilise-t-il par défaut?

Je vois qu'il existe une -threads <count>option de ligne de commande dans ffmpeg. Quelle est la valeur par défaut de cette option?

cela dépend du codec utilisé, de la version de ffmpeg et du nombre de cœurs de votre processeur. Parfois, il s'agit simplement d'un fil par noyau. Parfois, c'est plus complexe comme:

Avec libx264, les cœurs x 1,5 pour les threads de trame et les cœurs x 1 pour les threads de tranches.

À partir de 2014, il utilise un nombre optimal.

Vous pouvez le vérifier sur un ordinateur multicœur en examinant la charge du processeur (Linux:, topWindows: gestionnaire de tâches) avec différentes options de ffmpeg:

• -threads 0 (optimal);

• -threads 1 (à filetage unique);

• -threads 2 (2 threads pour un processeur Intel Core 2 Duo, par exemple);

• none (la valeur par défaut, également optimale).

Édition 2015: sur un processeur à 12 cœurs, certaines commandes ffmpeg ont Linux topaffichant au plus 200% cpu (seulement 2 cœurs), quel que soit le nombre attribué -threads. Donc, la valeur par défaut peut toujours être optimale dans le sens de "aussi bon que ce que le binaire ffmpeg peut obtenir", mais pas optimale dans le sens de "exploiter pleinement mon processeur leet".

En 2015 sur Ubuntu 14.04 avec ffmpeg 0.8.10-6, il utilisait 1 cœur sur un système à 4 coeurs. htopa montré cela; un seul cœur a été utilisé et j'ai obtenu un taux de conversion de 16 ips pour une vidéo FullHD.

En utilisant -threads 4tous mes cœurs de processeur aller à 100% et j'ai eu un taux de conversion de 47 fps.

J'ai utilisé la commande suivante:

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

Certaines de ces réponses sont un peu anciennes, et je voudrais juste ajouter qu'avec mon ffmpeg 4.1codage avec libx264, tous les 6 cœurs / 12 fils de mon système Ryzen 5 2600X ont été maximisés sans aucun -threadargument.

Je jouais avec la conversion dans une VM CentOS 6.5 (Ryzen 1700 8c / 16t - vm affecté à 12 cœurs sur 16). Les expériences avec des films 480p ont eu les effets suivants:

Option de fil / Taux de conversion (i / s @ 60 s)

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

La partie intéressante était le chargement du processeur (en utilisant htoppour le regarder). N'utilisant
aucune -threadsoption, nous nous sommes retrouvés dans la plage des 130 ips avec une charge répartie sur tous les cœurs à un niveau de charge faible.
En utilisant exactement 1 thread, le noyau était chargé à 100%. Toute autre utilisation a entraîné une autre situation de charge dispersée.

Comme vous pouvez le constater, il existe également un risque de rendements décroissants. Vous devez donc ajuster l’option -threads pour votre machine. Pour ma configuration en particulier, l’utilisation de -threads 6 (sur une machine à 12 coeurs) donnait le meilleur FPS lors de la conversion de la vidéo (de h264 à x264 à un débit différent pour forcer la conversion) et renvoyait en fait à mesure que j’ai jeté un plus grand nombre de threads. il.

Cela aurait également pu être un problème de mémoire: 1 Go seulement avait été attribué à la machine virtuelle. Je peux modifier cela et voir si cela change quelque chose. Néanmoins, cela montre que l’utilisation de cette -threadsoption peut augmenter les performances. Par conséquent, effectuez des tests sur votre machine particulière à différents niveaux pour trouver la configuration idéale.

en supposant que le threading soit activé, il attribue un nombre de cœurs 1,5x.