Vejo que há uma -threads <count>
opção de linha de comando no ffmpeg. Qual é o valor padrão desta opção?
Vejo que há uma -threads <count>
opção de linha de comando no ffmpeg. Qual é o valor padrão desta opção?
Respostas:
depende do codec usado, da versão ffmpeg e da contagem de núcleos da CPU. Às vezes, é simplesmente um segmento por núcleo. Às vezes é mais complexo como:
No libx264, são núcleos x 1,5 para threads de quadro e núcleos x 1 para segmentos de fatia.
A partir de 2014, ele usa um número ideal.
Você pode verificar isso em um computador com vários núcleos examinando a carga da CPU (Linux:, top
Windows: gerenciador de tarefas) com diferentes opções para ffmpeg:
-threads 0
(ótimo);
-threads 1
(rosca única);
-threads 2
(2 threads para, por exemplo, um Intel Core 2 Duo);
nenhum (o padrão, também é ótimo).
Edição de 2015: em uma CPU de 12 núcleos, alguns comandos ffmpeg têm Linux top
mostrando no máximo 200% da CPU (apenas 2 núcleos), independentemente do número atribuído -threads
. Portanto, o padrão ainda pode ser ideal no sentido de "o melhor que esse binário ffmpeg pode obter", mas não ideal no sentido de "explorar completamente minha CPU leet".
Em 2015, no Ubuntu 14.04 com ffmpeg 0.8.10-6, ele usou 1 núcleo em um sistema de 4 núcleos.
htop
mostrou isso; apenas um núcleo foi usado e eu obtive uma taxa de conversão de 16 qps para um vídeo em FullHD.
Usando -threads 4
fez todos os meus núcleos de CPU ir para 100% e eu tenho uma taxa de conversão de 47 fps.
Eu usei o seguinte comando:
$ ffmpeg -i foo.mp4 -y -target pal-dvd -aspect 16:9 dvd-out.mpg
Algumas dessas respostas são um pouco antigas, e eu gostaria de acrescentar que, com a minha ffmpeg 4.1
codificação com libx264
, todos os 6 núcleos / 12 threads do meu sistema Ryzen 5 2600X foram maximizados sem nenhum -thread
argumento.
-vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecode
portanto, existem algumas variáveis a serem isoladas. A adição -threads 12
não teve efeito.
Eu estava brincando com a conversão em um CentOS 6.5 VM (Ryzen 1700 8c / 16t - vm atribuiu 12 de 16 núcleos). As experiências com filmes em 480p renderizaram o seguinte:
Opção de segmento / taxa de conversão (fps a 60 segundos)
(none/default)/130fps
-threads 1/70fps
-threads 2/120fps
-threads 4/185fps
-threads 6/228fps
-threads 8/204fps
-threads 10/181fps
A parte interessante foi o carregamento da CPU (usando htop
para assistir).
O uso de nenhuma -threads
opção acabou na faixa de 130 fps com a carga espalhada por todos os núcleos em um nível de baixa carga.
O uso de 1 thread fez exatamente isso, carregou um núcleo a 100%. Usar qualquer outra coisa resultou em outra situação de carga de propagação.
Como você pode ver, também há um ponto de retornos decrescentes; portanto, você deve ajustar a opção -threads para sua máquina específica. Para minha configuração específica, o uso do -threads 6 (em uma máquina de 12 núcleos) resultou no melhor FPS ao converter o vídeo (de h264 para x264 em uma taxa de bits diferente para forçar uma conversão) e os retornos diminuíram, na verdade, quanto mais threads eu joguei isto.
Também poderia ter sido um problema de memória - ele tinha apenas 1 GB atribuído à VM. Eu posso ajustar isso e ver se isso muda alguma coisa. Ainda assim - mostra que o uso da -threads
opção pode aumentar o desempenho, portanto, execute alguns testes em sua máquina específica em diferentes níveis para encontrar o ponto ideal de suas configurações.
supondo que você tenha o encadeamento ativado, ele atribuiu um número de núcleos 1,5x.
-x264-params sliced-threads=1
. Ou através do uso de -tune zerolatency
.