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

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 fuites mémoire et les erreurs d’allocation ne sont pas une fatalité si les développeurs exploitent les outils disponibles dans l’écosystème du langage.

Ainsi, plutôt que de dénigrer le C++ pour son absence de mécanismes de sécurité intégrés à la Rust, il conviendrait de promouvoir les bonnes pratiques de développement, les outils de débogage avancés et les bibliothèques modernes comme RAII, unique_ptr, shared_ptr, ou encore Valgrind.

Dans sa vidéo intitulée « Rust Devs Think We’re Hopeless; Let’s Prove Them Wrong (with C++ Memory Leaks)! », Mamadou Babaei défend avec humour et technicité la capacité des développeurs C++ à gérer efficacement la mémoire, sans recourir aux mécanismes de sécurité stricts de Rust. Il démontre comment détecter les fuites mémoire en C++ en utilisant l'outil _CrtDumpMemoryLeaks fourni par la bibliothèque d'exécution C (CRT) de Microsoft.

Et d'indiquer :

« Lorsque les développeurs Rust pensent à nous, les gens du C++, ils imaginent une lignée maudite - un traumatisme générationnel transmis de malloc à free. Pour eux, chaque ligne de C++ que nous écrivons est comme jouer à la roulette russe - sauf que les six chambres sont chargées de comportements non définis.

« Ils nous regardent comme si nous étions sans espoir. Comme si nous étions à deux doigts d'une thérapie. Mais vous savez quoi ? Nous n'avons pas besoin d'une nounou pour le compilateur. Pas de vérificateur d'emprunts. Pas de durée de vie. Pas de modèles de propriété. Pas de magie noire. Même Valgrind n'est pas nécessaire. Juste des pointeurs bruts, de la détermination brute, et un peu de santé mentale douteuse.

« Dans cette vidéo, je vais donc vous montrer comment traquer les fuites de mémoire comme si vous étiez né avec un pointeur dans une main et un débogueur dans l'autre ».


Conclusion

La critique de FFmpeg envers Rust met en lumière les défis liés à l'adoption de nouveaux langages dans des systèmes critiques. Bien que Rust offre des avantages en termes de sécurité mémoire, il est essentiel de peser soigneusement les compromis en termes de performance et d'accessibilité de la communauté. Ce débat souligne la nécessité d'une évaluation approfondie des besoins spécifiques de chaque projet avant de choisir la technologie la plus appropriée.

Source : Prossimo

Et vous ?

Jusqu'à quel point la sécurité mémoire de Rust justifie-t-elle les éventuels compromis en termes de performance, surtout dans des projets comme les décodeurs vidéo qui nécessitent une vitesse maximale ?

Devrait-on privilégier des langages comme C qui offrent des performances brutes, ou bien adopter des langages modernes comme Rust, qui ajoutent une couche de sécurité au prix de performances potentiellement réduites ?

Les restrictions géographiques dans des initiatives comme la prime de Prossimo sont-elles justifiées, ou risquent-elles d'exclure des talents internationaux qui pourraient apporter des améliorations majeures ?

Est-il raisonnable d'attendre qu'une personne puisse optimiser un décodeur écrit en Rust pour atteindre les performances de C, ou bien est-ce une tâche trop ambitieuse ?

Est-il réaliste de penser que Rust pourrait remplacer des langages comme C ou C++ dans des applications à haute performance, ou bien devrait-il être réservé à des projets où la sécurité mémoire est une priorité absolue ?

Les projets comme le noyau Linux ou FFmpeg devraient-ils adopter Rust dans leurs bases de code, ou vaut-il mieux se concentrer sur l'amélioration des solutions existantes en C et C++ ?