FFmpeg : « Rust est tellement bon qu'on peut être payé 20 000 $ pour le rendre aussi rapide que le C », le framework multimédia écrit en C réagi avec sarcasme à une initiative de Prossimo

Le 15 mai 2025, le compte Twitter officiel de FFmpeg a publié un message acerbe à l'encontre de Rust, le qualifiant de « tellement bon que l'on peut être payé 20 000 $ pour le rendre aussi rapide que C ». Cette remarque visait la récente initiative de Prossimo, qui a proposé une prime de 20 000 $ à quiconque parviendrait à rendre son décodeur AV1, rav1d, aussi rapide que dav1d, une implémentation en C largement reconnue pour sa rapidité. Cette déclaration a ravivé le débat sur les compromis entre sécurité mémoire, performance et coût dans le développement de systèmes critiques.

FFmpeg est l'un des frameworks multimédias open source les plus utilisés au monde, car il permet le traitement audio et vidéo pour des applications telles que VLC, OBS Studio, HandBrake, Jellyfin, etc. et est largement utilisé dans le live-streaming, y compris sur des plateformes comme Twitch.

D'autre part, rav1d est une réimplémentation en Rust du décodeur AV1 dav1d, écrit en C. Bien que Rust soit apprécié pour sa sécurité mémoire, rav1d présente une performance inférieure d'environ 5 % par rapport à dav1d. Pour combler cet écart, Prossimo a lancé une prime de 20 000 $ destinée à toute personne capable d'améliorer la vitesse de rav1d. Cependant, cette initiative a été critiquée entre autres pour ses restrictions géographiques, excluant une grande partie de la communauté des développeurs.


Le Perfomance Bounty

En mars 2023, nous avons annoncé que nous commencions à travailler sur un décodeur AV1 plus sûr et plus performant, appelé rav1d, écrit en Rust. Nous nous sommes associés à Immunant pour effectuer le travail d'ingénierie. En septembre 2024, rav1d était pratiquement terminé et nous avons beaucoup appris au cours du processus. Aujourd'hui, rav1d fonctionne bien - il passe tous les mêmes tests que le décodeur dav1d sur lequel il est basé, qui est écrit en C. Il est possible de construire et d'exécuter Chromium avec lui.

Il y a juste un problème : il n'est pas aussi rapide que la version en C. Nous voulons changer cela et nous avons besoin de votre aide.

Notre décodeur rav1d basé sur Rust est actuellement environ 5% plus lent que le décodeur dav1d basé sur le C (la quantité exacte varie un peu en fonction du benchmark, de l'entrée et de la plateforme). Cette différence est suffisamment importante pour poser problème aux utilisateurs potentiels et, franchement, elle nous dérange. L'équipe de développement a travaillé d'arrache-pied pour atteindre la parité des performances. Nous avons fait appel à deux autres contractants qui ont de l'expérience dans l'optimisation de ce genre de choses. Nous avons écrit sur le travail d'optimisation que nous avons effectué. Cependant, nous n'avons toujours pas réussi à atteindre la parité des performances et, pour être franc, nous ne savons pas vraiment ce qu'il faut faire ensuite.

Après nous être creusé la tête pour trouver des options, nous avons décidé d'offrir une prime de 20 000 $ pour que rav1d atteigne la parité de performance avec dav1d. Nous espérons que les gens pourront nous aider à faire progresser les performances de rav1d jusqu'à ce qu'elles atteignent le niveau requis, et idéalement, nous et la communauté Rust apprendrons quelque chose sur la façon dont les performances de Rust se comparent à celles de C.

Le règlement officiel se trouve ici, mais pour résumer :

• Le concours est ouvert aux personnes ou aux équipes de personnes résidant légalement aux États-Unis, au Royaume-Uni, dans l'Union européenne, dans l'Espace économique européen, en Suisse, au Canada, en Nouvelle-Zélande ou en Australie.
• Le règlement fournit des instructions pour l'évaluation comparative des améliorations des performances.
• Vous travaillez à l'amélioration des performances. Vos améliorations peuvent concerner rav1d, le compilateur Rust ou la bibliothèque standard Rust.
• Les décodeurs dav1d et rav1d partagent exactement les mêmes optimisations de code assembleur de bas niveau - vous ne pouvez pas modifier cet assembleur. Vous devez améliorer le code Rust (ou le compilateur Rust), ce qui constitue la différence entre dav1d et rav1d. Vous ne pouvez pas introduire dans rav1d du code dans un langage autre que Rust. Nous vous encourageons à poser vos questions dès le début dans les problèmes ou en nous envoyant un email afin d'éviter d'investir lourdement dans quelque chose qui pourrait ne pas être éligible !
• Faites fusionner vos améliorations de performance dans le projet concerné selon le processus de contribution standard du projet et sous sa (ses) licence(s) open source, puis envoyez-nous un email selon les instructions des règles officielles pour participer et potentiellement être récompensé pour votre contribution.
• À la fin du concours (probablement parce que nous avons atteint notre objectif ou que le temps est écoulé), nous diviserons, à notre discrétion, la prime proportionnellement entre les plus grands contributeurs aux gains de performance.

La réaction de FFmpeg

Commentant le récent programme de primes de performance de Prossimo pour rav1d, FFmpeg a mentionné que « Rust est tellement bon qu'on peut être payé 20 000 $ pour le rendre aussi rapide que le C ». Difficile de ne pas y voir du sarcasme puisque les langages utilisés pour créer et maintenir ses outils sont le C, C++ et l'assembleur.

Le Performance Bounty a pour but de combler un écart de performance où rav1d est environ 5% plus lent que dav1d. Prossimo offre une récompense de 20 000 $ à quiconque parviendra à combler cet écart.

Ils ont mis en place un ensemble de règles qui empêchent la plupart des gens de contribuer, limitant cette prime à certaines régions et excluant une grande partie de la communauté mondiale des développeurs.

[TWITTER]<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Rust is so good you can get paid $20k to make it as fast as C:<a href="https://t.co/HVDokmLk5r">https://t.co/HVDokmLk5r</a></p>— FFmpeg (@FFmpeg) <a href="https://twitter.com/FFmpeg/status/1922814549033447800?ref_src=twsrc%5Etfw">May 15, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> [/TWITTER]

Ont-ils raison ?

L'industrie des technologies de l'information s'est progressivement tournée vers Rust, un langage de programmation réputé pour sa sécurité mémoire et ses performances. La Maison Blanche des États-Unis a même officiellement approuvé le passage à des langages de programmation sans risque pour la mémoire dans un rapport de l'Office of the National Cyber Director (ONCD) datant de 2024.

« En tant que nation, nous avons la capacité - et la responsabilité - de réduire la surface d'attaque dans le cyberespace et d'empêcher des catégories entières de bogues de sécurité d'entrer dans l'écosystème numérique, mais cela signifie que nous devons nous attaquer au problème difficile de l'adoption de langages de programmation sans danger pour la mémoire », écrit l'Office of the National Cyber Director (ONCD) de la Maison Blanche qui cite le Rust parmi les langages à adopter.

Toutefois, l'adoption de Rust ne s'est pas faite sans controverse. C'est notamment le cas des efforts déployés pour l'intégrer dans le noyau Linux, qui se sont heurtés à des résistances et à des tensions internes, un incident récent ayant provoqué des frictions et entraîné la création d'une politique relative au noyau Rust afin d'éviter de futurs conflits.

Malgré une adoption croissante, de nombreux membres de la communauté des développeurs continuent de se demander si les avantages de Rust l'emportent vraiment sur ceux des langages de longue date comme le C.

« C++ n'a pas besoin d'une nounou comme le vérificateur d'emprunts de Rust »

Depuis l’essor de Rust dans les milieux de la sécurité et du développement système, une idée reçue semble s’installer : le C++ serait intrinsèquement dangereux. Ses critiques mettent en avant la complexité de sa gestion manuelle de la mémoire, source supposée d’erreurs fréquentes et de vulnérabilités critiques.

Mais ce discours occulte une réalité plus nuancée : le C++ n’est pas dangereux par nature, il est exigeant. Comme le rappelle Mamadou Babaei, développeur professionnel de jeu, les...