O uso do FFmpeg pela Meta: o segredo do processamento de mídia em larga escala

• A Meta executa o FFmpeg dezenas de bilhões de vezes por dia e conseguiu migrar totalmente de uma versão fork interna para o FFmpeg upstream
• Para eliminar a diferença de funcionalidades entre o fork interno e a versão open source, colaborou com a FFlabs e a VideoLAN para implementar no upstream a codificação paralela multilanes e recursos de métricas de qualidade em tempo real
• Processa mais de 1 bilhão de uploads de vídeo por dia e realiza, com uma única linha de comando do FFmpeg, codificações em múltiplas resoluções e codecs para reprodução via DASH
• A estrutura eficiente de threading implementada nas versões 6.0 a 8.0 do FFmpeg foi baseada no design da Meta e oferece ganhos de eficiência de codificação para todos os usuários
• O MSVP (Meta Scalable Video Processor), ASIC projetado internamente, foi integrado por meio da API padrão de hardware do FFmpeg, garantindo consistência entre os pipelines de software e hardware
• Por meio de investimento contínuo no FFmpeg, desenvolvido há mais de 25 anos, a Meta reforça ao mesmo tempo novas experiências de vídeo e a estabilidade de sua plataforma

---

O papel do FFmpeg e o desafio da Meta

• O FFmpeg é uma ferramenta padrão da indústria para processamento de mídia, com suporte a diversos codecs de áudio e vídeo e formatos de contêiner, permitindo edição e conversão de mídia por meio de cadeias complexas de filtros
• A Meta executa os binários ffmpeg (CLI principal) e ffprobe (utilitário para consultar propriedades de arquivos de mídia) dezenas de bilhões de vezes por dia, e tem requisitos adicionais que vão além do processamento de arquivos individuais
• Por muito tempo, dependeu de um fork interno para implementar por conta própria recursos que não existiam no upstream da época, como codificação multilanes baseada em threads e cálculo de métricas de qualidade em tempo real

A divergência do fork interno e a necessidade de voltar ao upstream

• À medida que o fork interno foi se distanciando consideravelmente do upstream do FFmpeg, a diferença entre os conjuntos de funcionalidades aumentou gradualmente
• Ao mesmo tempo, novas versões do FFmpeg passaram a oferecer suporte a novos codecs e formatos de arquivo, além de melhorias de estabilidade, tornando necessário também suportar as versões open source mais recentes para acomodar sem interrupções a variedade de vídeos enviados pelos usuários
• Como ficou cada vez mais difícil evitar regressões ao fazer rebase das alterações internas, a Meta colaborou com desenvolvedores do FFmpeg, a FFlabs e a VideoLAN para eliminar completamente o fork interno e migrar para o uso exclusivo da versão upstream

Construindo transcodificação multilanes eficiente (VOD e livestreaming)

• Quando um usuário faz upload de um vídeo, são gerados conjuntos de múltiplas codificações para reprodução via DASH (Dynamic Adaptive Streaming over HTTP), oferecendo codificações com diferentes resoluções, codecs, taxas de quadros e níveis de qualidade
  • O player de vídeo do app pode alternar entre as codificações em tempo real com base em sinais como as condições da rede
• A forma mais simples seria processar cada lane sequencialmente com uma linha de comando FFmpeg separada, mas mesmo com execução paralela cada processo realiza trabalho duplicado (decodificação repetida, overhead de inicialização do processo), o que é ineficiente
• Ao decodificar os frames apenas uma vez em uma única linha de comando do FFmpeg e depois enviá-los para cada codificador de saída, é possível eliminar a duplicação da decodificação e reduzir o overhead de inicialização de processos
  • Como a Meta processa mais de 1 bilhão de uploads de vídeo por dia, qualquer economia computacional por processo se traduz em um grande ganho de eficiência no total
• O fork interno da Meta oferecia ainda otimizações para codificação de vídeo paralela: o FFmpeg tradicional executava em série por frame ao usar vários codificadores, mas a Meta passou a executar todas as instâncias de codificador em paralelo para obter maior paralelismo
• Graças às contribuições de desenvolvedores do FFmpeg (incluindo FFlabs e VideoLAN), uma estrutura de threading mais eficiente começou a ser implementada a partir do FFmpeg 6.0 e foi concluída no 8.0
  • Ela foi diretamente influenciada pelo design do fork interno da Meta e ficou registrada como o refatoramento mais complexo do FFmpeg em décadas
  • Isso traz uma codificação mais eficiente para todos os usuários do FFmpeg

Métricas de qualidade em tempo real (livestreaming)

• Métricas de qualidade visual são usadas para expressar numericamente a qualidade perceptiva da mídia e quantificar a perda de qualidade causada pela compressão
  • Métricas de referência: comparam a codificação original com a codificação distorcida
  • Métricas sem referência: avaliam a qualidade sem o original
• O FFmpeg consegue calcular métricas de qualidade como PSNR, SSIM e VMAF usando duas codificações já existentes em uma linha de comando separada após o término da codificação, mas no livestreaming é necessário calcular isso em tempo real
• Ao inserir um decodificador de vídeo atrás do codificador de vídeo de cada lane de saída, obtém-se o bitmap dos frames após a compressão e, comparando-o com os frames anteriores à compressão, é possível gerar métricas de qualidade em tempo real para cada lane de codificação em uma única linha de comando do FFmpeg
• A partir do FFmpeg 7.0, com contribuições de desenvolvedores da FFlabs e da VideoLAN, a decodificação in-loop foi ativada, eliminando totalmente a dependência do fork interno para essa funcionalidade

Critérios para contribuições ao upstream e patches exclusivos internos

• Recursos como métricas de qualidade em tempo real e threading eficiente trazem ganhos de eficiência para diversos pipelines baseados em FFmpeg dentro e fora da Meta, por isso foram contribuídos ao upstream
• Em contrapartida, patches altamente especializados para a infraestrutura da Meta e difíceis de generalizar são mantidos apenas internamente
• O FFmpeg oferece suporte por API padrão a decodificação, codificação e filtragem aceleradas por hardware para NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV e outros
• O MSVP (Meta Scalable Video Processor), ASIC próprio de transcodificação de vídeo da Meta, também recebeu suporte por meio da mesma API padrão, permitindo usar ferramentas comuns em diferentes plataformas de hardware
  • Como o MSVP é usado apenas na infraestrutura interna da Meta, desenvolvedores externos do FFmpeg não têm acesso ao hardware para testar e validar, então esse patch continua interno
  • Ao fazer rebase para versões mais recentes do FFmpeg, a Meta garante robustez e correção por meio de validação extensiva

Investimento contínuo no FFmpeg

• Com os recursos de codificação multilanes e métricas de qualidade em tempo real, a Meta eliminou completamente o fork interno em todos os pipelines de VOD e livestreaming
• Graças à API padrão de hardware do FFmpeg, consegue oferecer suporte em paralelo ao ASIC MSVP e aos pipelines baseados em software com atrito mínimo
• A Meta planeja continuar investindo no FFmpeg, desenvolvido ativamente há mais de 25 anos, por meio de parceria com desenvolvedores open source, gerando benefícios para a Meta, para a indústria e para os usuários

[GN⁺]

Comentários do Hacker News

• À medida que o fork interno foi ficando cada vez mais defasado, passamos a trabalhar com os desenvolvedores do FFmpeg para integrar os recursos de que precisávamos ao FFmpeg oficial
  Com isso, foi possível abandonar completamente a versão interna e operar apenas com a versão upstream
  Alguns dizem que “dava para contribuir mais”, mas a essência do open source é que todos compartilham os benefícios

  • Acho que não dá para negar que a Meta contribui para a comunidade
    Já nos beneficiamos de inúmeros projetos, como React e React Native
  • Mas, se esses recursos surgiram de demandas de empresas gigantescas, a maioria dos usuários não sente esses benefícios na prática
    No fim, esse tipo de estrutura parece favorecer apenas quem já tem poder
  • Sem dúvida é uma mudança positiva, mas houve um período em que os interesses internos vieram primeiro
    Ainda assim, o fato de a Meta ter aberto muita coisa para o ecossistema open source funciona como um diferencial no setor
  • Não devemos esquecer que nenhuma big tech poderia existir sem uma base em open source
  • Contribuir com open source em si é ótimo, mas não gostei do tom do post no blog
    Expressões como “só agora integramos ao upstream” soaram como uma tentativa de maquiar falhas do passado
    Misturar linguagem de marketing em blog técnico incomoda do ponto de vista do leitor

• Espero que Fabrice Bellard seja devidamente recompensado quando se aposentar
  Muitas empresas ganharam dinheiro graças ao software dele

• É bom ver que as novas versões do FFmpeg passaram a suportar vários codecs e formatos,
  mas, numa escala em que a Meta o executa bilhões de vezes por dia, fico curioso para saber se ela tem participado continuamente dessas melhorias

  • [comentário excluído]

• Executar isso dezenas de bilhões de vezes por dia é uma escala realmente absurda
  Eu já percebo overhead rodando apenas alguns milhares de vezes por dia em tarefas automatizadas de montagem de vídeo
  O recurso single-decode multi-output reduziu o tempo de processamento em 40%

  • Nessa escala, o uso de RAM também deve ser inimaginável
    Felizmente, com a queda recente no preço da memória, a relação custo-benefício de melhorar o open source ficou ainda maior

• A abordagem de aumentar a paralelização executando instâncias de encoder em paralelo faz sentido
  Mas eu gostaria de ver um recurso de paralelização no eixo do tempo (time-axis parallelization)
  Se o vídeo de entrada for dividido por keyframes e codificado em paralelo, dá para ganhar velocidade sem perda de qualidade

  • Mas será que dá para prever com antecedência a posição dos keyframes?
    Normalmente o encoder os posiciona dinamicamente para ganhar eficiência, então a divisão prévia pode ser difícil
  • Também fico pensando se a análise de movimento feita pelo encoder ao analisar quadros P/B não poderia ser calculada uma vez e reutilizada em várias codificações

• Obrigado à equipe da Meta pelas contribuições ao ffmpeg e ao ffprobe
  Espero que no futuro também considerem apoio financeiro para qualidade de código, documentação e eventos da comunidade

• A frase “o fork interno foi ficando cada vez mais velho” é relatável demais
  A propósito, no FFmpeg 8 o mapeamento de cores entre HDR e SDR funciona perfeitamente

  • Antes eu sofria com problemas de cópia automática de metadados, então é ótimo ver isso resolvido
  • É bom ouvir novidades depois de tanto tempo, e o progresso é impressionante

• Achei interessante a notícia de que o Sovereign Tech Fund da Alemanha fez uma doação ao FFmpeg

  • O STF alemão doou cerca de US$ 150 mil, mas só o custo anual de um engenheiro da Meta já deve passar do dobro disso
    Provavelmente a Meta mantém uma equipe dedicada à codificação de mídia e contribui com algo de mais de US$ 1 milhão por ano em valor
  • Mas a conta oficial do FFmpeg comentou que “o apoio da Meta é bem-vindo, mas não está em um nível sustentável”
    Ver tweet relacionado
  • Fico curioso para saber quanto a Meta realmente doou
    Dizem que o STF alemão apoiou com €157.580 em 2024/2025
  • É um tanto irônico que a Meta ganhe bilhões de dólares e ainda assim doe menos que um fundo estatal
  • [comentário excluído]

• Felizmente, os servidores do FFmpeg estão aguentando porque processam apenas conteúdo leve
  Se fossem vídeos pesados, já teriam sobrecarregado

• O mesmo post no HN já tinha sido publicado há 6 dias
  Não entendo por que dariam downvote só por eu ter colocado esse link

  • Pelo que eu entendo, republicações são aceitáveis, desde que não sejam feitas repetidamente pelo mesmo usuário
  • [comentário excluído]