Lições de linguagem Assembly do FFmpeg

• Lições de linguagem Assembly do FFmpeg são um material de estudo open source projetado para permitir uma compreensão profunda de como os computadores funcionam internamente
• Este repositório oferece exemplos reais e exercícios práticos da linguagem Assembly usada no FFmpeg
• Conhecimento de ponteiros na linguagem C e de matemática de nível de ensino médio é um pré-requisito para o estudo
• Com isso, é possível desenvolver a capacidade de contribuir diretamente para o projeto open source FFmpeg
• Há suporte para perguntas e discussões por meio de um canal no Discord

---

Introdução às lições de linguagem Assembly do FFmpeg

• FFmpeg School of Assembly Language é uma lição open source criada para ajudar você a iniciar uma das jornadas mais interessantes, desafiadoras e recompensadoras da programação
• Por meio dessas lições, é possível aprender com código real como a linguagem Assembly é escrita no FFmpeg e entender de forma sistemática o que está acontecendo dentro do computador

Conhecimentos necessários

• É essencial ter compreensão da linguagem C, especialmente do conceito de ponteiros
  • Caso você não conheça C, é necessário estudar primeiro o livro "The C Programming Language"
• Também é necessário ter conhecimento de matemática de nível de ensino médio (escalares e vetores, adição, multiplicação etc.)

Estrutura das lições e como utilizá-las

• Este repositório no GitHub inclui lições em etapas e exercícios correspondentes a cada lição (os exercícios ainda não foram enviados)
• Ao concluir todo o curso, você terá capacidade prática para contribuir diretamente com o projeto FFmpeg

Suporte da comunidade

• É possível participar de perguntas, respostas e discussões por meio do servidor do Discord (https://discord.com/invite/Ks5MhUhqfB)

Traduções para outros idiomas

• As lições também estão disponíveis em francês e espanhol, o que amplia a acessibilidade para desenvolvedores de diferentes idiomas

[GN⁺]

Comentários no Hacker News

• Só de imaginar a escala do FFMPEG já impressiona; até melhorias minúsculas de desempenho podem economizar milhares ou dezenas de milhares de horas de computação, é realmente um projeto útil
  • Acho admirável a obsessão da equipe do FFMPEG por desempenho; imagino como seria bom se todo projeto tivesse essa mesma postura
  • Ainda assim, gostaria que houvesse uma API de verdade no sentido tradicional (não algo imperativo, mas realmente na forma de biblioteca); não é fácil entender a linha de comando atual, que parece uma linguagem própria
• Houve uma discussão anterior em 2025-02-22, com 222 comentários disponível aqui
• Fico curioso sobre como, na prática, se encontram hotspots causados por assembly não otimizado gerado pelo compilador, e também se faz sentido escrever diretamente uma representação intermediária como LLVM IR em vez de assembly específico por arquitetura
  • Muitos dos problemas que as pessoas imaginam são diferentes dos problemas reais; na prática, não se trata de “assembly não otimizado”, mas do nível que se pode esperar de um compilador C; os principais fatores são os seguintes: há uma implementação genérica em C para os loops e versões adicionais em asm/SIMD por hardware, mas as características de SIMD variam entre plataformas e dificultam a generalização; diferenças entre versões de compilador podem impedir que todos os usuários aproveitem a melhor implementação; o modelo de memória de C e o uso de char * atrapalham a otimização; intrinsics e recursos de auto-vectorization às vezes entram em conflito; no Intel C, os intrinsics às vezes tornam o assembly mais legível por causa dos nomes de função complicados criados pela Microsoft
  • Normalmente, usam-se ferramentas como vtune ou uprof para analisar hotspots de benchmark no nível da ISA; não sei bem quais são as ferramentas para ARM; escrever manualmente uma representação intermediária como LLVM IR não traz muito ganho na prática; na maioria dos casos, só se escreve assembly diretamente para problemas específicos de arquitetura; compiladores C/C++ em geral geram código bem otimizado, mas código vetorizado muitas vezes exige mudar o próprio algoritmo, tornando inevitável o uso de intrinsics, e nesse caso o código perde portabilidade e passa a parecer assembly; além disso, há overhead no código gerado pelo compilador; por isso, muitas vezes é melhor escrever direto em assembly e deixar para o humano cuidar de coisas como alocação de registradores e ordenação de instruções; no fim, só medindo para saber se um assembly escrito à mão é melhor do que o gerado pelo compilador; benchmark é indispensável
  • Escrever LLVM IR diretamente não faz muito sentido; se o objetivo for código vetorial, vale primeiro tentar pragmas de vetorização e, se isso falhar, usar intrinsics ou uma linguagem como ISPC; não há ganho real em usar IR; mesmo que você queira resolver por conta própria problemas de alocação de registradores ou seleção de instruções do compilador, ao escrever em IR o compilador ainda vai reconstruir aquilo como código normal; no fim, o IR só acrescenta uma camada instável e mais difícil de usar; se a meta é produzir o melhor assembly manual possível, o correto é escrever logo em assembly
• É uma pena que não comece com uma introdução simples, praticando os exemplos em um assembler real como o NASM
• Eu esperava insights ou macetes vindos da enorme experiência acumulada no projeto, mas não tive muita sensação de conexão direta com o ffmpeg em si; vendo apenas alguns capítulos, parece mais conteúdo geral de introdução a assembly
• Acho que seria bom incluir no repositório GitHub também o material das aulas de matemática necessárias para o FFmpeg Assembly Lessons; se tudo estivesse reunido em um só lugar, seria mais fácil começar
  • Não sou o autor, mas se o leitor só tem conhecimentos básicos de programação em C e quer contribuir de fato com codecs de vídeo, existe uma quantidade considerável de conhecimento prévio até chegar a algo como o algoritmo de Cooley-Tukey, e isso ainda é só o básico
• Fico curioso sobre como esses códigos assembly garantem portabilidade entre diferentes CPUs
  • Pelo que entendo, o processamento que roda em C genérico também serve como baseline, e para as principais arquiteturas existem versões de assembly escritas à mão
  • Na prática, o alvo é só x86-64
• Li com bastante interesse; sinto que tutoriais especializados por domínio são muito melhores
• Há um uso bem excessivo do pré-processador de macros do nasm, o que provavelmente tornaria bem difícil portar para outro assembler
  • Fico me perguntando por que exatamente seria necessário portar para outro assembler
  • Gostaria de saber em que parte isso aconteceu; no código das aulas, na prática, quase não há código de verdade