Ile wątków domyślnie używa ffmpeg?

Widzę, że -threads <count>w ffmpeg dostępna jest opcja wiersza poleceń. Jaka jest domyślna wartość tej opcji?

zależy to od używanego kodeka, wersji ffmpeg i liczby rdzeni procesora. Czasami jest to po prostu jeden wątek na rdzeń. Czasami jest to bardziej złożone, takie jak:

W przypadku libx264 jest to rdzeń x 1,5 dla wątków ramy i rdzeń x 1 dla wątków plastra.

Od 2014 roku używa optymalnej liczby.

Możesz to sprawdzić na komputerze wielordzeniowym, badając obciążenie procesora (Linux:, topWindows: menedżer zadań) z różnymi opcjami ffmpeg:

• -threads 0 (optymalne);

• -threads 1 (jednowątkowy);

• -threads 2 (2 wątki np. Dla Intel Core 2 Duo);

• brak (domyślnie, również optymalnie).

Edycja 2015: na 12-rdzeniowym procesorze niektóre polecenia ffmpeg mają Linuksa toppokazującego najwyżej 200% procesora (tylko 2 rdzenie), bez względu na to, jaką liczbę podano -threads. Tak więc wartość domyślna może być nadal optymalna w sensie „tak dobrego, jak ten plik binarny ffmpeg”, ale nie optymalna w znaczeniu „pełnego wykorzystania mojego najlepszego procesora”.

W 2015 r. Na Ubuntu 14.04 z ffmpeg 0.8.10-6 używało 1 rdzenia w systemie 4-rdzeniowym. htoppokazał to; zastosowano tylko jeden rdzeń, a ja uzyskałem współczynnik konwersji 16 fps dla wideo FullHD.

Używając sprawiłem, -threads 4że wszystkie moje rdzenie procesora spadły do ​​100%, a ja uzyskałem współczynnik konwersji 47 fps.

Użyłem następującego polecenia:

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

Niektóre z tych odpowiedzi są nieco stare i chciałbym dodać, że przy moim ffmpeg 4.1, kodowaniu za pomocą libx264, wszystkie 6 rdzeni / 12 wątków mojego systemu Ryzen 5 2600X zostały zmaksymalizowane bez żadnego -threadargumentu.

Bawiłem się konwersją w CentOS 6.5 VM (Ryzen 1700 8c / 16t - vm przypisano 12 z 16 rdzeni). Eksperymenty z filmami 480p przyniosły następujące efekty:

Opcja wątku / współczynnik konwersji (fps @ 60 s)

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

Interesującą częścią było ładowanie procesora (używanie go htopdo oglądania).
Bez -threadsużycia opcji zwijanej w zakresie 130 klatek na sekundę z rozkładem obciążenia na wszystkie rdzenie przy niskim obciążeniu.
Za pomocą 1 wątku zrobił to dokładnie, załadował jeden rdzeń na 100%. Używanie czegokolwiek innego skutkowało kolejną sytuacją obciążenia rozkładaniem.

Jak widać, istnieje również punkt malejących zwrotów, dlatego trzeba dostosować opcję -wątków dla konkretnej maszyny. W przypadku mojej konfiguracji użycie -wątków 6 (na maszynie 12-rdzeniowej) przyniosło najlepszy FPS podczas konwersji wideo (z h264 na x264 przy innej szybkości transmisji bitów w celu wymuszenia konwersji) i zwroty faktycznie zmniejszyły się, im więcej wątków wrzuciłem to.

Mógł to być także problem z pamięcią - do maszyny wirtualnej przypisano tylko 1 GB. Mogę to poprawić i sprawdzić, czy to coś zmieni. Mimo to - pokazuje, że użycie tej -threadsopcji może zwiększyć wydajność, dlatego uruchom kilka testów na konkretnej maszynie na różnych poziomach, aby znaleźć swoje ulubione ustawienia.

zakładając, że masz włączone wątkowanie, przypisano 1,5-krotną liczbę rdzeni.