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:, topWindows: 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 topmostrando 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.
htopmostrou 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 4fez 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.1codificação com libx264, todos os 6 núcleos / 12 threads do meu sistema Ryzen 5 2600X foram maximizados sem nenhum -threadargumento.
-vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecodeportanto, existem algumas variáveis a serem isoladas. A adição -threads 12nã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 htoppara assistir).
O uso de nenhuma -threadsopçã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 -threadsopçã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.