FFmpeg introduz pipeline de transcodificação multithread

 (ffmpeg.org)
2 pontos por GN⁺ 2023-11-07 | 1 comentários | Compartilhar no WhatsApp
  • A transcodificação multithread da CLI do FFmpeg foi apresentada em sua primeira forma “totalmente funcional” após cerca de 2 anos de trabalho e mais de 700 commits preparatórios
  • Como o escopo das mudanças é grande, ainda existe a possibilidade de que alguns recursos tenham sido quebrados, e testes e revisão seguem como tarefas centrais antes da mesclagem real
  • -fix_sub_duration_heartbeat dificilmente evita comportamento não determinístico em execução assíncrona por causa das suposições de sincronização entre decoder, encoder e muxer
  • O overhead de threading em geral é pequeno, mas em tarefas com pouquíssimo trabalho por pacote o custo pode se destacar mais do que o ganho de desempenho
  • Se o gargalo não estiver concentrado em um único componente e cada componente ainda não estiver totalmente multithread, o uso de CPU e o tempo real de processamento podem melhorar bastante em ambientes multicore

Pontos principais do patch de multithreading da CLI do FFmpeg

  • Após cerca de 2 anos de trabalho e mais de 700 commits preparatórios, a primeira versão “fully functional” da CLI multithread do FFmpeg foi publicada como um conjunto de patches
  • Como a escala das mudanças é grande, pode haver quebras ainda não identificadas, então são necessários testes e revisão com base em casos reais de uso
  • Em geral, o overhead de threading é pequeno, mas em workloads com pouquíssimo trabalho por pacote esse overhead pode se tornar relevante
  • Se a transcodificação não for dominada por um único componente e cada componente ainda não estiver saturado por seu próprio multithreading, o uso de CPU e o tempo de execução podem melhorar em sistemas multicore

Restrições de funcionamento e problemas conhecidos

  • A opção -fix_sub_duration_heartbeat na estrutura atual pressupõe sincronização entre componentes separados
    • O fluxo-alvo é a sincronização do encoder e muxer para o decoder
    • Quando cada componente roda de forma assíncrona, o comportamento se torna fundamentalmente não determinístico
    • Hoje o comportamento já é difícil de prever, mas ao executar com a mesma opção os resultados entre execuções são determinísticos
    • No patch 16/24, essa opção é desativada, e será necessária uma forma melhor de tratá-la

Composição do conjunto de 24 patches

  • O conjunto de patches é composto por 24 partes no total
    • 01-09/24 são correções preparatórias e podem ser enviadas antes do restante da série
    • 10-17/24 movem codificação e filtragem para threads e fazem as mudanças preparatórias necessárias
      • O threading nessa etapa é “falso”, no sentido de que a thread principal espera a conclusão das outras, então ainda não há execução realmente paralela
      • Como o overhead temporário pode ser grande ou alguns corner cases podem quebrar, é mais adequado enviar isso depois que o conjunto completo estiver pronto
    • 18/24 é o maior patch individual e adiciona o scheduler de transcodificação, mas nesse ponto ele ainda não funciona de fato
    • 19-24/24 convertem componentes individuais para usar o scheduler
      • Eles foram separados para facilitar a revisão, mas devem ser combinados no envio final
  • Materiais relacionados podem ser vistos no vídeo recente da apresentação no VDD e no branch ffmpeg_threading

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-07
Opiniões no Hacker News

  • Em um servidor ARM de 4 núcleos, ficou cerca de 2 vezes mais rápido, e o overhead da paralelização não parece ser grande
    ffmpeg_threading/ffmpeg levou 7,771 segundos, enquanto o ffmpeg existente levou 13,841 segundos, com uso de CPU de 218% e 114%, respectivamente

    • Aqui, não foi usada aceleração por hardware no lado da decodificação, e a saída de vídeo também foi removida
      Fico curioso para saber como seria usando aceleração por hardware tanto para decodificação quanto para codificação de vídeo em uma placa NVIDIA: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Fico curioso sobre quais partes estão sendo multithreaded. A compressão de vídeo já é multithread, e não sei bem quanto à descompressão de vídeo
      As outras operações parecem ter um custo de desempenho relativamente pequeno, então, embora a melhoria seja bem-vinda, imagino que o impacto real seja bastante limitado

  • Teria sido melhor linkar https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... em vez do tweet
    No fim, o ponto principal do tweet também é esse link

    • Agora dá para chamar simplesmente de post. O limite de 280 caracteres também não existe mais, e textos longos só ficam recolhidos por padrão

  • Para entender isso, é bom assistir à apresentação do Anton no VideoLAN Dev Days 2023: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • A apresentação foi boa, e fiquei curioso sobre o que ele tinha em mente com dynamic pipelines e “scripting (Lua?)” em “Future directions”
      Isso me faz imaginar um caminho para lidar de forma mais poderosa com animação de propriedades
    • Já passei por muitos dos problemas relacionados a Extras mostrados no slide por volta dos 33 minutos do vídeo
    • Eu realmente quero assistir à apresentação, mas a qualidade do áudio é tão ruim que fica difícil me concentrar. Não sei como ainda conseguem estragar tanto assim hoje em dia
    • Não sei qual parte é difícil de entender. No domínio de transcodificação de vídeo, multithread é usado com outro significado?

  • O tweet aponta para http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655..., que por sua vez referencia o código em https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • O tweet aponta para a lista de discussão, que é a fonte oficial do patchset. Para continuar lendo, basta escolher “Next in Thread”

  • Fico curioso se isso será aplicado automaticamente ou se será preciso combinar parâmetros de linha de comando de forma complicada

  • Fico curioso se existe algum software de edição de vídeo que use ffmpeg
    Em certo momento pensei em criar algo que desenhasse formas em SVG e usasse ffmpeg, ou que adicionasse uma UI, ou apenas texto, mas não cheguei a começar
    O Avidemux tem um pouco essa vibe, e o interior do ffmpeg é bem cru; como ele não foi feito para ser acessado por uma GUI, um editor baseado nele provavelmente seria lento, estranho e difícil de manter
    Algo como um editor modular que gerasse prévias com um descritor de comandos ou um visualizador de pipeline parece possível
    O ffmpeg é poderoso, mas o fato de ser usado apenas pela linha de comando acaba afastando alguns usuários. No passado escrevi um script em Python que recebia um número aleatório de clipes e criava um mosaico com o filtro xstack, mas não foi fácil

  • Seria bom se as pequenas tarefas de transcodificação que faço para o Plex ficassem mais rápidas
    Minha placa de vídeo não oferece suporte a transcodificação por hardware, então estou animado

  • Eu estava procurando formas de aumentar a velocidade de transcodificação, e uma era a aceleração por GPU, enquanto a outra era aumentar o número de threads
    Só que é difícil encontrar o número ideal de threads

    • Não dá para usar otimização de hiperparâmetros para encontrar o valor ideal? Com ferramentas como Sherpa ou Scikit-optimize, dá para varrer um espaço de busca com número de threads, tipo de entrada, tipo de CPU etc.
    • Para a maioria das tarefas, basta ajustar o número de threads ao número de vCPUs. Ou seja, conte núcleos com hyper-threading como 2
      Mas, se possível, aceleração por GPU é muito melhor

  • Fico curioso sobre quais são os requisitos de licença para uma implantação em larga escala do ffmpeg. Em que casos é preciso pagar?

    • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
      http://ffmpeg.org/legal.html
      Ou seja, é gratuito, mas, se você usar alguns módulos, pode haver problemas ao misturá-lo com código proprietário
    • A forma comum de usar ffmpeg dentro de software proprietário é compilar estaticamente a versão do ffmpeg usada e vinculá-la ao executável, ou fazer o software proprietário chamá-lo como um executável separado

  • É bom ver o FFmpeg melhorando. Espero que em breve também vejamos suporte a Dolby AC4