FFmpeg adota multithreading na CLI com a "refatoração mais complexa" em décadas

Suporte a multithreading na CLI do FFmpeg

• O recurso de suporte a multithreading na interface de linha de comando (CLI) do FFmpeg foi incorporado ao Git do FFmpeg.
• Trata-se de uma mudança feita antes do lançamento do FFmpeg 7.0 no começo do próximo ano, representando uma grande melhoria para esse importante projeto open source amplamente usado em transcodificação de vídeo.
• Agora que processadores multicore se tornaram comuns, essa melhoria é muito benéfica.

Trabalho de refatoração complexo

• Em uma apresentação técnica recente, os desenvolvedores do FFmpeg descreveram esse trabalho de multithreading como "uma das refatorações mais complexas já feitas na CLI do FFmpeg em décadas".
• Os desenvolvedores pedem aos usuários que façam testes e incentivam o envio de problemas encontrados para o FFmpeg Trac.

Mudanças técnicas implementadas

• O patch incorporado inclui a adição de uma infraestrutura de agendamento de transcodificação com reconhecimento de threads, a movimentação da codificação para uma thread separada e várias outras mudanças de baixo nível.
• A transição do FFmpeg para uma arquitetura com threads significa que cada componente (demuxer, decoder, filter, encoder, muxer) já rodava em sua própria thread, mas agora poderá de fato ser executado em paralelo.

Opinião do GN⁺

• O suporte a multithreading no FFmpeg é um avanço importante que pode melhorar bastante a eficiência de tarefas de transcodificação de vídeo.
• Esse trabalho complexo de refatoração trouxe muitos desafios para os desenvolvedores e mostra que o FFmpeg continua se adaptando e evoluindo para os ambientes de computação modernos.
• Será interessante para usuários e desenvolvedores observar qual será o impacto real dessa mudança no desempenho.

[GN⁺]

Opiniões do Hacker News

• Teoria sobre otimização de multithreading/processamento

  • No passado, ler, processar e renderizar uma única imagem levava um tempo considerável, mas com os avanços de hardware e software isso agora é muito mais rápido.
  • Antes, era eficiente ter vários workers processando um único frame, mas hoje um único worker pode processar frames com mais eficiência do que mobilizar vários workers.
  • Os sistemas modernos operam em um ambiente completamente diferente daquele que existia quando o FFmpeg foi criado pela primeira vez, então é necessário repensar como a carga de trabalho deve ser definida, agendada, distribuída, acompanhada e depois reunida no resultado final.
  • Elogia a equipe do FFmpeg por aceitar esse desafio. O FFmpeg é o ápice da infraestrutura open source e um elemento essencial para a construção da civilização.

• Gravação da palestra no evento VDD@Dublin

  • Estava procurando a gravação da palestra, mas não foi fácil encontrá-la nem no site do autor nem aqui.
  • Atualização: encontrou no YouTube!

• Reflexões sobre melhorar o desempenho multicore

  • Os encoders atuais usam várias threads para processar o mesmo frame ao mesmo tempo. O método comum é dividir o frame em várias regiões e fazer com que cada thread processe uma região específica.
  • Como alternativa, propõe processar segmentos entre keyframes de forma independente. Esse método permite paralelizar o codec de maneira geral e eficiente, sem a perda de eficiência de compressão causada por dividir frames em regiões nem o overhead de comunicação entre threads.
  • O problema desse método é que seria necessário carregar na memória frames correspondentes a N*ciclo de keyframe, além do overhead adicional de memória necessário para codificar N frames.
  • Ainda assim, em muitos casos esses problemas provavelmente não seriam grandes obstáculos. Na maioria das situações, usar muita RAM e gerar saída com intervalo fixo entre keyframes é aceitável.
  • Também seria possível combinar o paralelismo dentro do frame com o paralelismo por segmentos entre keyframes para alcançar alto nível de paralelismo minimizando a perda de qualidade.

• O desafio do trabalho contínuo de rebase

  • Fazer rebase continuamente sobre as mudanças que entravam todos os dias era um desafio considerável.
  • Agora que isso foi integrado ao FFmpeg, o trabalho deve ficar muito mais fácil daqui para frente.
  • É uma grande vitória, e isso contribuirá bastante para ganhos de velocidade.

• Expectativa de melhorar o tempo de início do streaming do buffer de display virtual no FFmpeg

  • No projeto LLMStack, usam FFmpeg para transmitir vídeo do navegador.
  • Atualmente, há uma latência perceptível para inicializar o pipeline cada vez que uma ferramenta é chamada.
  • As melhorias no FFmpeg certamente ajudarão nesses esforços de otimização.

• Divulgação de curso sobre a API C do FFmpeg

  • Divulga um curso na Udemy que ensina a API C do FFmpeg.

• Curiosidade sobre o codebase do FFmpeg

  • Não conhece bem o codebase do FFmpeg, mas tem curiosidade sobre como foi possível avançar com as mudanças gradualmente sem um commit gigantesco.
  • Segundo a apresentação, houve 700 commits; fica a dúvida se isso foi feito em um branch separado ou se foi sendo incorporado ao projeto aos poucos.

• Perspectiva de um operador de serviços em nuvem

  • Se você opera um serviço em nuvem como a Netflix, já executa milhares de processos do FFmpeg em cada máquina, então na prática isso já é um trabalho multicore.

• Relato de experiência com processamento de filtros em threads no VapourSynth

  • Já aproveita o processamento de filtros em threads no VapourSynth há quase 10 anos.
  • Esta melhoria no FFmpeg também é excelente, mas não deve mudar muito o fluxo de trabalho de pré-processamento com VapourSynth + codificação com av1an para vídeo de "qualidade".

• Pergunta sobre o suporte multicore do FFmpeg

  • Fica a dúvida se o FFmpeg agora poderá usar multicore em todos os codecs incluídos.
  • Usa FFmpeg com LAME para codificar MP3 em um serviço de hospedagem de áudio, e seria ótimo se fosse possível melhorar o tempo de codificação de arquivos longos.