ATUALIZAÇÃO EM 3 DE AGOSTO DE 2017: De acordo com uma nova resposta do usuário 林正浩, o ffmpeg agora tem suporte para codificação do VP9 por meio do VAAPI. Eu ainda não tenho o hardware necessário para testar isso, então minha resposta será de ajuda limitada. Deixarei minha resposta original sobre como codificar o VP9 no software abaixo.
Por algum motivo, o FFmpeg não suporta a codificação VP9 no codificador de hardware QuickSync da Intel, mesmo que eles suportem H.264 e HEVC . Uma pesquisa através do repositório de código fonte do FFmpeg mostra que não é mesmo uma questão de ser desativado, o recurso ainda não foi implementado ainda. Mas se ele estiver disponível em algum momento no futuro, ele deverá ser utilizável de maneira semelhante aos outros codificadores QuickSync: um switch como -c:v vp9_qsv em vez de -c:v libvpx-vp9 deve fazer o trabalho.
O uso da linha de comando do FFmpeg é o mesmo em todas as plataformas, com a exceção notável de que usuários do Windows devem usar NUL em vez de /dev/null para a saída durante a primeira passagem de uma codificação de 2 passagens. Mas como você está fazendo 1 passe e sem perdas, isso não deve afetá-lo.
Se você quiser acelerar suas codificações, a coisa mais óbvia que deve tentar é definir um valor de velocidade de codificação com a opção -speed . Os valores recomendados são números de 0 a 4, com 0 sendo muito, muito lento (pense em -preset placebo em x264, mas pior), mas alta qualidade e 4 são rápidos e de baixa qualidade. O ffmpeg usa -speed 1 por padrão, o que é uma boa troca de velocidade por qualidade para codificação com perdas. No entanto, acabei de fazer um teste de codificação sem perda rápida com diferentes valores de velocidade e notei uma redução de 32% no tamanho do arquivo quando passava de -speed 1 para -speed 0 com codificação sem perdas. O tempo de codificação triplicou, portanto, se usar 0 vale a pena, depende de você. O arquivo produzido por -speed 4 foi apenas 1,1% maior que o produzido por -speed 1 , e foi codificado 43% mais rápido. Então, eu diria que, se você estiver sem perdas e -speed 0 estiver muito lento, é melhor usar -speed 4 .
Outro importante aumento de desempenho de codificação está ativando o multiencadeamento com a opção -threads ; A libvpx não usa automaticamente vários encadeamentos, portanto, isso deve ser definido manualmente pelo usuário. Você também deve definir o número de colunas de blocos com a opção -tile-columns . Essa opção faz com que a libvpx divida o vídeo em vários blocos e codifique esses blocos em paralelo para melhor multitarefa. Você pode encontrar números recomendados para a quantidade de colunas e segmentos de blocos na seção "Recomendações para ladrilhos e encadeamentos" do VP9 do Google guia de codificação . Como você pode ver, o número de encadeamentos usados sobe com o número de blocos, o que significa que dependendo do número de núcleos de CPU disponíveis, seu processador pode não estar totalmente saturado enquanto codifica vídeo de resolução sub-HD. Se você codifica principalmente vídeos de baixa resolução, convém considerar a codificação de vários arquivos ao mesmo tempo.
No entanto, há mais uma outra maneira de acelerar a codificação do VP9: multi-threading em um único bloco de coluna que pode ser ativado com -row mt 1 . A partir de 4 de abril (2017, hello future people), não faz parte de uma versão lançada do libvpx, mas provavelmente estará no libvpx 1.6.2. Se você quiser experimentá-lo antes do próximo lançamento, você precisa compilar as versões git recentes do libvpx e do ffmpeg a partir do código-fonte. Apenas siga o guia de compilação do FFmpeg para sua distribuição, mas em vez de baixar e extrair um tarball de lançamento, faça git pull https://chromium.googlesource.com/webm/libvpx
Quanto ao veryslow predefinido, isso é usado apenas em x264 e x265. A libvpx usa a opção -speed e, além disso, as opções -quality best , -quality good ou -quality realtime para definir quanto tempo o codificador pode gastar codificando um quadro. O padrão é -quality good porque -quality best é tão lento que é inutilizável e -quality realtime deve ser usado para aplicativos de tempo crítico, como vídeo chamadas e livestreaming.