Lançamento do FFmpeg 8.0

 (ffmpeg.org)
2 pontos por GN⁺ 2025-08-23 | 1 comentários | Compartilhar no WhatsApp
  • FFmpeg 8.0 "Huffman" adiciona codecs baseados em computação com Vulkan, além de decodificação e codificação com aceleração por hardware, e vários novos formatos de arquivo e filtros
  • A infraestrutura foi modernizada por completo, e o processo de contribuição e a qualidade do código também foram reforçados
  • Houve avanços importantes nas áreas de codecs de áudio e vídeo, incluindo a estabilização do decodificador VVC, o decodificador xHE-AAC e suporte a MV-HEVC e LC-EVC
  • O projeto continua desempenhando um papel central no avanço das tecnologias multimídia open source, com melhorias contínuas de recursos e de segurança

Introdução ao FFmpeg

  • O FFmpeg é um toolkit completo e de uso geral para processamento multimídia, uma solução flexível e poderosa para gravar, converter e transmitir áudio e vídeo
  • Com comandos simples como ffmpeg -i input.mp4 output.avi, é possível processar vídeo e áudio

23 de agosto de 2025, lançamento do FFmpeg 8.0 "Huffman"

  • Foi lançado o FFmpeg 8.0 "Huffman". Após vários adiamentos e um processo de atualização da infraestrutura, esta se tornou a maior release já feita até hoje
  • Entre os novos recursos estão a adição de decodificadores nativos como APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM e G.728, melhorias no suporte do decodificador VVC para IBC, ACT e Palette Mode, além de codecs como FFv1 (codificação e decodificação) e ProRes RAW (somente decodificação) baseados em computação com Vulkan
  • Foram introduzidas decodificação com aceleração por hardware baseada em Vulkan (por exemplo, VP9, VVC, H264/5) e codificação (AV1, H264/5), além de diversos novos formatos (MCC, G.728, Whip, APV) e filtros (colordetect, pad_cuda, scale_d3d11, Whisper etc.)
  • Uma nova família de decodificadores e codificadores baseados em compute shader, executados sobre Vulkan 1.3, foi adicionada. A estrutura não exige aceleradores especiais de hardware e funciona da mesma forma que a API hwaccel. Para usar os codificadores, é preciso especificar os novos encoders; no momento, apenas FFv1 (codificação e decodificação) e ProRes RAW (decodificação) são suportados. ProRes (bidirecional) e VC-2 (bidirecional) estão em preparação
  • Essa estrutura só pode ser aplicada a codecs otimizados para decodificação paralela, e espera-se que no futuro traga grandes ganhos de desempenho e novos usos, como edição de vídeo não linear e gravação sem perdas, em áreas mais diversas
  • A infraestrutura do projeto também foi amplamente atualizada. O servidor da mailing list foi totalmente substituído, e agora há suporte a colaboração de código baseada em Forgejo em code.ffmpeg.org
  • Recomenda-se que os usuários atualizem para a versão mais recente

Leituras relacionadas

1 comentários

 
GN⁺ 2025-08-23
Comentários do Hacker News

  • Agradece aos desenvolvedores e colaboradores do FFmpeg

    • Sempre usou o FFmpeg sempre que precisou de automação de áudio/vídeo, e a maioria das ferramentas de vídeo online também usa essa ferramenta como motor principal ou como wrapper de UI
    • Hoje também descobriu que existe o projeto FFmpeg.Wasm (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • Compartilha a experiência de, em janeiro de 2024, extrair frames de um filme de animação de 1993 em intervalos de 15 minutos, fazer upscale com Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) e depois recompor os frames resultantes em 4K
    • Pensa que, se tivesse adicionado uma UI a esse fluxo de trabalho, poderia ter virado uma ferramenta parecida com as populares Topaz AI de hoje em dia
    • Também compartilha uma imagem de amostra com upscale (imagem de amostra)
    • Mesmo quando não usa ffmpeg diretamente, usa com frequência ferramentas que o incorporam
      • Recentemente fez upscale de um anime antigo e de baixa qualidade extraído de um DVD via k4yt3x/video2x, foi fácil de instalar e vinha com libffmpeg embutido
      • Na hora da codificação, foi possível usar os mesmos argumentos do FFmpeg
      • Para escolher os melhores parâmetros, codificou cenas curtas com vários conjuntos de parâmetros no ffmpeg e depois extraiu imagens estáticas novamente com ffmpeg para comparar

  • Fica feliz que o FFmpeg tenha introduzido codificadores e decodificadores de vídeo baseados em compute shaders

    • Os codecs amplamente suportados por hardware são basicamente H.264, H.265 e AV1, então seria bom se outros codecs também pudessem ter aceleração por plataforma, mesmo que com alguma perda de eficiência
    • O novo codificador ProRes parece útil para um projeto em andamento
    • Entende a explicação de que codecs genéricos amplamente usados não são adequados para decodificação paralela, então o suporte é difícil
    • Seria preciso usar dezenas de milhares de threads, mas dependências de dados entre frames e entre tiles dificultam a paralelização
    • O codificador talvez tenha um pouco mais de flexibilidade do que o decodificador, mas codificar algo como VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) com compute shaders ainda parece um desafio

    • Compartilha novamente a alegria pela implementação de codificadores/decodificadores de vídeo em compute shaders

      • No passado, como só existiam interfaces de hardware padronizadas em silício, já foi motivo de piada quando perguntou se codificadores/decodificadores baseados em Vulkan seriam algo genérico
      • É muito legal que essas melhorias também estejam disponíveis em hardware antigo, e espera que isso abra caminho para novos codecs e melhorias gerais de qualidade

    • Não acompanha o estado da arte em decodificadores há mais de 10 anos, mas intuitivamente imagina que a aceleração por GPU ajudaria muito no pós-processamento, quando os dados viram pixels

      • A descompressão inicial poderia ficar na CPU, depois os dados descomprimidos seriam enviados para a GPU para a transformação final, como aplicação de vetores de movimento, iDCT etc.
      • Se o frame final já estiver como textura de GPU, o overhead de exibição também seria pequeno
      • Fica curioso para saber o quanto essa intuição está correta

    • Sempre se impressiona com o talento dos mantenedores do FFmpeg, e acha incrível que façam esse tipo de trabalho difícil de graça

    • Estas notas de versão são muito interessantes

      • Nas últimas semanas, fez um decodificador ProRes com compute shaders em WebGPU, e ele funciona rápido o suficiente (acha que a Apple provavelmente usaria aceleração de hardware própria)
      • Esse caminho também parece combinar bem com o novo codec APV do Android
      • A especificação do bitstream do ProRes foi submetida à SMPTE, mas foi difícil encontrar informações sobre o ProRes RAW
      • Acha muito interessante estarem surgindo implementações por software e por compute, e imagina que os desenvolvedores do ffmpeg provavelmente fizeram engenharia reversa
      • Pelo código, não parece muito diferente do ProRes comum
      • Documento de especificação do ProRes

  • Sempre fica impressionado quando usa o FFmpeg (mesmo que precise voltar ao manual ou pedir ajuda a um LLM, inclusive quando usa uma GUI que monta comandos a partir de opções visuais)

    • Parece ter se tornado uma multitool essencial de transcodificação
    • Acha que foi uma boa decisão adotar processamento baseado em Vulkan 1.3
    • Ontem também descobriu que o Asahi Linux no Mac suporta o mesmo padrão

    • Deixa a observação espirituosa de que os argumentos do FFmpeg são a “engenharia de prompt original”

    • LLMs e ferramentas complexas de linha de comando como FFmpeg e ImageMagick formam uma combinação fantástica

      • Parece até uma UI/UX futurista perfeita, em que basta descrever em linguagem natural o que se quer fazer e isso é realizado na hora
      • Imagina, por exemplo, um cenário em que todas as imagens de uma pasta são recortadas para um tamanho específico, a saturação é ajustada, tudo é salvo em TIFF, montado em loop de vídeo e codificado para web de uma vez só

    • LLMs funcionam muito bem como interface para o FFmpeg

  • Compartilha, em tom de piada mas com fundo de verdade, que desperdiça 50% do esforço montando comandos complexos de CLI para ffmpeg e os outros 50% brigando com escape de shell

    • Especialmente ao colocar texto sobre vídeo, o escape de texto parece muito difícil
    • Pergunta se alguém encontrou uma forma perfeita de chamar ffmpeg em Python com muitos argumentos, como filtros (r-strings? heredocs? etc.)

  • Pergunta se existe um bom frontend GUI que facilite lidar com os diversos recursos do FFmpeg

    • Às vezes só precisa fazer remux, ou apenas combinar streams de vídeo/áudio no mesmo codec

    • Destaca que combinar vídeos parece simples, mas na prática há mais variáveis e problemas do que parece

      • Variáveis como timebase, offset inicial, crop de frame, diferença de FPS, B-frames e open GOP podem causar problemas em certos ambientes de reprodução
      • No áudio também existem várias variáveis, como diferenças de sample rate
      • O programa Lossless-Cut foi mencionado, e o recurso de verificação de compatibilidade é útil
      • Mas converter os vídeos para MPEG-TS antes de juntá-los ajuda a contornar vários problemas, e pode ser feito rapidamente em um ramdisk
      • Também compartilha uma sequência de linha de comando ffmpeg que pode ser usada como exemplo

    • Handbrake cumpre bem esse papel

      • Em termos de recursos, é suficiente e, embora esteja um pouco antigo, ainda é bastante útil

    • Para usuários de Mac, recomenda o ffWorks (https://www.ffworks.net/index.html)

      • A maioria dos recursos fica facilmente acessível, e ele também oferece processamento em lote e presets
      • O desenvolvedor dá um suporte muito ativo, é um dos aplicativos preferidos dele, e ele até faz doação porque acha que vale muito a pena
      • Handbrake e Losslesscut também são excelentes, mas parece não haver em outras plataformas nenhum app que rivalize com o nível de acabamento do ffWorks

    • Acha que, para ele, o melhor frontend é o ChatGPT

      • Se descrever em linguagem natural o que quer fazer, ele gera comandos de ffmpeg com bastante precisão

    • Recomenda conferir o programa Lossless-cut

  • Compartilha um link para conferir o changelog do FFmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • Expressa brevemente que é uma notícia interessante

    • Pergunta se esse vídeo é sátira ou se está falando sério

  • Opina que o ffmpeg talvez seja a quarta biblioteca mais usada, depois de SSL, zlib e sqlite (partindo da ideia de que vídeo estará realmente em todo lugar em 2025)

    • Acha difícil concordar, porque processamento de vídeo costuma ser necessário principalmente em servidores que recebem mídia

      • Menciona que a maioria dos celulares não processa vídeo com ffmpeg

    • curl pode estar mais acima, e “SSL” tem várias implementações, então os números ficam dispersos

    • Sugere como fonte de dados os logs de métricas Fastly da infraestrutura do NixOS (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md)

    • Acha que há várias bibliotecas mais usadas que o ffmpeg, como Qt, libpng e libusb

    • Vale a pena conferir também as estatísticas de pacotes do Arch Linux (https://pkgstats.archlinux.de/packages)

  • Acha especialmente legal a implementação de compute shaders em Vulkan, principalmente para FFv1 e ProRes RAW

    • Como isso contorna completamente os decodificadores de hardware de função fixa, fica curioso sobre o impacto na largura de banda de memória
    • A codificação aritmética adaptativa ao contexto do FFv1 parece intrinsecamente sequencial, então parece difícil ganhar velocidade, o que torna surpreendente o fato de estarem obtendo melhorias muito grandes
    • Fica curioso se a abordagem paraleliza vários símbolos ao mesmo tempo ou por slices, já que tradicionalmente havia motivos para a aceleração de codificação aritmética em GPU ser difícil, e quer saber quais trade-offs a equipe do ffmpeg fez
    • Se alguém tiver experiência de profiling dessa implementação, gostaria de ouvir sobre ocupação e escolha de largura de banda na etapa de decodificação de entropia

  • O ffmpeg está por trás de uma quantidade enorme de ferramentas

    • O público em geral muitas vezes não percebe o quanto o ffmpeg contribuiu para a indústria de mídia
    • É a ferramenta à qual sempre recorre quando precisa de automação de áudio/vídeo