Leçons d’assembleur pour FFmpeg

• Les leçons d’assembleur pour FFmpeg sont une ressource d’apprentissage open source conçue pour permettre de comprendre en profondeur le fonctionnement interne d’un ordinateur
• Ce dépôt propose des exemples concrets et des exercices pratiques autour du langage assembleur utilisé dans FFmpeg
• Des connaissances en pointeurs en C et un niveau de mathématiques de lycée sont requis pour suivre l’apprentissage
• Cela permet de développer les compétences nécessaires pour contribuer directement au projet open source FFmpeg
• Une aide pour les questions et les discussions est proposée via un salon Discord

---

Présentation des leçons d’assembleur pour FFmpeg

• FFmpeg School of Assembly Language est une leçon open source conçue pour vous faire commencer l’un des parcours les plus intéressants, exigeants et gratifiants de la programmation
• Cette leçon permet d’apprendre à partir de vrai code comment l’assembleur est écrit dans FFmpeg et de comprendre de manière structurée ce qui se passe à l’intérieur de l’ordinateur

Connaissances requises

• Une compréhension du langage C est indispensable, en particulier du concept de pointeur
  • Si vous ne connaissez pas le C, il faut d’abord étudier le livre "The C Programming Language"
• Des connaissances en mathématiques de niveau lycée (scalaires et vecteurs, addition, multiplication, etc.) sont nécessaires

Structure des leçons et mode d’utilisation

• Ce dépôt GitHub comprend des leçons progressives et des exercices associés à chaque leçon (les exercices n’ont pas encore été mis en ligne)
• Une fois l’ensemble du parcours terminé, vous disposerez de compétences pratiques permettant de contribuer directement au projet FFmpeg

Support communautaire

• Il est possible de poser des questions et de participer aux discussions via le serveur Discord (https://discord.com/invite/Ks5MhUhqfB)

Traductions multilingues

• Les leçons sont également disponibles en français et en espagnol, ce qui améliore l’accessibilité pour les développeurs de différentes langues

[GN⁺]

Commentaires sur Hacker News

• Rien que d’imaginer l’ampleur de FFMPEG est impressionnant ; même un tout petit gain de performances peut économiser des milliers, voire des dizaines de milliers d’heures de calcul, c’est vraiment un projet utile.
  • Je trouve admirable l’obsession de l’équipe FFMPEG pour les performances ; j’imagine à quel point ce serait bien si tous les projets adoptaient cette attitude.
  • Cela dit, j’aimerais qu’il y ait une vraie API au sens traditionnel du terme — pas impérative, mais sous la forme d’une véritable bibliothèque — car il n’est pas facile de comprendre une ligne de commande qui ressemble à un langage maison comme aujourd’hui.
• Une discussion précédente a eu lieu le 2025-02-22, avec 222 commentaires, consultable ici.
• Je me demande comment on repère concrètement les hot spots causés par de l’assembleur non optimal généré par le compilateur, et s’il est pertinent d’écrire directement une représentation intermédiaire comme LLVM IR plutôt que de l’assembleur spécifique à chaque architecture.
  • Beaucoup des problèmes auxquels pensent les gens ne correspondent pas aux vrais enjeux. En pratique, il ne s’agit pas d’« assembleur non optimal », mais plutôt de ce qu’on peut attendre d’un compilateur C. Les principaux facteurs sont les suivants : il existe une implémentation C générique des boucles et des versions asm/SIMD ajoutées selon le matériel, mais les caractéristiques SIMD diffèrent selon les plateformes, ce qui rend la généralisation difficile ; les différences de version de compilateur peuvent empêcher certains utilisateurs de profiter de la meilleure implémentation ; le modèle mémoire du C et l’usage de char * gênent les optimisations ; les intrinsics et l’auto-vectorisation peuvent aussi entrer en conflit ; et, en Intel C, les intrinsics utilisent parfois des noms de fonctions complexes créés par Microsoft, au point que l’assembleur peut être plus lisible.
  • En général, on analyse les hot spots de benchmark au niveau ISA avec des outils comme vtune ou uprof ; je ne connais pas bien les outils pour ARM. Écrire soi-même une représentation intermédiaire comme LLVM IR n’a pas vraiment beaucoup d’intérêt en pratique. Dans la plupart des cas, on n’écrit de l’assembleur à la main que pour des problèmes propres à une architecture. Les compilateurs C/C++ génèrent généralement du code bien optimisé, mais pour du code vectorisé il faut souvent changer l’algorithme lui-même, ce qui rend l’usage d’intrinsics inévitable ; dans ce cas le code devient moins portable et ressemble déjà à de l’assembleur. En plus, il y a le surcoût du code généré par le compilateur. Il vaut donc souvent mieux écrire directement en assembleur et gérer soi-même l’allocation des registres, l’ordonnancement des instructions, etc. Au final, pour savoir si de l’assembleur codé à la main est meilleur que ce que génère le compilateur, il faut mesurer ; un benchmark est indispensable.
  • Écrire directement du LLVM IR n’a pas grand intérêt. Si le but est de produire du code vectoriel, il vaut mieux commencer par des directives de vectorisation (pragmas) et, si cela échoue, utiliser des intrinsics ou un langage comme ISPC. Il n’y a pas vraiment de gain à passer par l’IR. Même si l’on veut corriger soi-même les problèmes d’allocation de registres ou de sélection d’instructions du compilateur, écrire en IR fait qu’au final le compilateur reconstruit quand même le code à sa manière. En pratique, l’IR ne fait qu’ajouter une couche instable et plus difficile à utiliser. Pour produire le meilleur assembleur codé à la main, il vaut simplement mieux écrire directement en assembleur.
• C’est dommage que cela ne commence pas par une introduction simple avec des exemples réellement praticables dans un assembleur comme NASM.
• J’espérais des idées ou un savoir-faire issus de la vaste expérience accumulée dans le projet, mais je n’ai pas vraiment ressenti de lien direct avec ffmpeg ; en ne regardant que quelques chapitres, cela donne plutôt l’impression d’un contenu d’initiation générale à l’assembleur.
• Je me dis qu’il serait peut-être utile d’inclure aussi dans le dépôt GitHub les supports de cours de mathématiques nécessaires pour les FFmpeg Assembly Lessons ; si tout était rassemblé au même endroit, il serait plus facile de commencer.
  • Je ne suis pas l’auteur, mais si le lecteur ne connaît que les bases de la programmation en C et veut réellement contribuer à un codec vidéo, il y a énormément de connaissances préalables à couvrir avant d’arriver à des sujets comme l’algorithme de Cooley-Tukey — et cela ne reste encore que le minimum.
• Je me demande comment ce code assembleur assure sa portabilité sur différents CPU.
  • À mon avis, le traitement en C générique sert aussi de base, et il existe des versions en assembleur écrites à la main pour les principales architectures.
  • En pratique, seule l’architecture x86-64 est visée.
• Lecture très intéressante ; j’ai trouvé qu’un tutoriel spécialisé dans un domaine est bien meilleur.
• Il y a un usage vraiment excessif du préprocesseur de macros de nasm, au point que le portage vers un autre assembleur risque de devenir assez difficile.
  • Je me demande bien pourquoi il faudrait le porter vers un autre assembleur.
  • Je me demande dans quelles parties c’était le cas ; dans le code du cours, il y a en fait très peu de code.