FFmpeg introduit le multithreading dans son CLI via « le refactoring le plus complexe » depuis des décennies

Prise en charge du multithreading dans le CLI de FFmpeg

• La prise en charge du multithreading dans l’interface en ligne de commande (CLI) de FFmpeg a été fusionnée dans le dépôt Git de FFmpeg.
• Il s’agit d’un changement intervenu avant la sortie de FFmpeg 7.0 au début de l’année prochaine, et d’une amélioration majeure pour cet important projet open source largement utilisé pour le transcodage vidéo.
• À l’heure où les processeurs multicœurs sont devenus la norme, cette amélioration est particulièrement bénéfique.

Un travail de refactoring complexe

• Dans une récente présentation technique, les développeurs de FFmpeg ont décrit ce travail sur le multithreading comme « l’un des refactorings les plus complexes réalisés sur le CLI de FFmpeg depuis des décennies ».
• Les développeurs demandent aux utilisateurs d’effectuer des tests et les invitent à signaler tout problème découvert sur FFmpeg Trac.

Les changements techniques mis en œuvre

• Le patch fusionné comprend l’ajout d’une infrastructure de planification du transcodage compatible avec les threads, le déplacement de l’encodage vers un thread séparé, ainsi que plusieurs autres modifications de bas niveau.
• Faire évoluer FFmpeg vers une architecture à threads signifie que chaque composant (demuxer, décodeur, filtre, encodeur, muxer) s’exécutait déjà dans son propre thread, mais peut désormais fonctionner réellement en parallèle.

L’avis de GN⁺

• La prise en charge du multithreading dans FFmpeg constitue une avancée importante susceptible d’améliorer fortement l’efficacité des tâches de transcodage vidéo.
• Ce travail de refactoring complexe a représenté de nombreux défis pour les développeurs, et montre que FFmpeg continue de s’adapter et d’évoluer avec les environnements informatiques modernes.
• Il sera intéressant, pour les utilisateurs comme pour les développeurs, d’observer l’impact concret de ce changement sur les performances réelles.

[GN⁺]

Avis Hacker News

• Théorie sur l’optimisation du multithreading/multiprocessing

  • Autrefois, lire, traiter et rendre une seule image prenait un temps considérable, mais avec les progrès du matériel et des technologies logicielles, c’est désormais bien plus rapide.
  • Avant, il était efficace de faire traiter une image par plusieurs workers, mais aujourd’hui un seul worker peut traiter une image plus efficacement qu’en mobilisant plusieurs workers.
  • Les systèmes modernes évoluent dans un environnement totalement différent de celui de l’époque où FFmpeg a été créé ; il faut donc repenser la manière de définir, planifier, répartir et suivre la charge de travail, puis de la recombiner dans le résultat final.
  • L’auteur félicite l’équipe FFmpeg d’avoir relevé ce défi. FFmpeg est au sommet de l’infrastructure open source, un élément essentiel à la construction de notre civilisation.

• Enregistrement d’une conférence de l’événement VDD@Dublin

  • L’auteur cherchait l’enregistrement de la conférence, mais il n’était pas facile à trouver, ni sur le site de l’auteur ni ici.
  • Mise à jour : trouvé sur YouTube !

• Réflexion sur l’amélioration des performances multicœurs

  • Les encodeurs actuels utilisent plusieurs threads pour traiter simultanément une même image. La méthode courante consiste à découper l’image en plusieurs zones, chaque thread s’occupant d’une zone précise.
  • Comme alternative, l’auteur propose de traiter indépendamment des segments entre images clés. Cette méthode permet de paralléliser les codecs de façon générale et efficace, sans perte d’efficacité de compression due au découpage de l’image en zones, ni surcharge de communication entre threads.
  • Le problème de cette approche est qu’il faut charger en mémoire les images correspondant à N*périodes d’image clé, avec une surcharge mémoire supplémentaire nécessaire pour encoder N images.
  • Cependant, dans de nombreux cas, ces inconvénients ne devraient pas poser de gros problèmes. La plupart du temps, on accepte volontiers une forte consommation de RAM et une sortie avec un intervalle fixe entre images clés.
  • On peut aussi combiner le parallélisme intra-image et le parallélisme par segments d’images clés afin d’obtenir un haut niveau de parallélisme tout en minimisant la dégradation de qualité.

• Le défi d’un travail de rebase continu

  • Rebaser en continu les changements qui arrivaient chaque jour représentait un défi considérable.
  • Maintenant que c’est intégré à FFmpeg, le travail sera beaucoup plus simple à l’avenir.
  • C’est une grande victoire, et cela contribuera fortement aux gains de vitesse.

• Attente d’une amélioration du temps de démarrage du streaming de tampons d’affichage virtuel avec FFmpeg

  • Le projet LLMStack utilise FFmpeg pour streamer la vidéo du navigateur.
  • À l’heure actuelle, il existe une latence perceptible au démarrage du pipeline à chaque appel d’outil.
  • Les améliorations de FFmpeg aideront certainement dans ce travail d’optimisation.

• Promotion d’un cours sur l’API C de FFmpeg

  • L’auteur fait la promotion d’un cours Udemy qui enseigne l’API C de FFmpeg.

• Curiosité à propos de la base de code de FFmpeg

  • L’auteur ne connaît pas très bien la base de code de FFmpeg, mais se demande comment des changements peuvent être introduits progressivement sans passer par un énorme commit.
  • La présentation mentionne 700 commits ; l’auteur se demande s’il s’agissait d’une branche séparée ou si le travail a été fusionné petit à petit dans le projet.

• Point de vue d’un opérateur de services cloud

  • Lorsqu’on exploite un service cloud comme Netflix, on exécute déjà des milliers de processus FFmpeg sur chaque machine ; c’est donc, par essence, déjà une charge de travail multicœur.

• Retour d’expérience sur le traitement des filtres threadés de VapourSynth

  • L’auteur apprécie depuis près de dix ans le traitement des filtres threadés dans VapourSynth.
  • Cette amélioration de FFmpeg est excellente, mais elle ne changera probablement pas grand-chose au workflow de prétraitement VapourSynth + encodage av1an pour l’encodage vidéo « de qualité ».

• Question sur la prise en charge multicœur de FFmpeg

  • L’auteur se demande si FFmpeg peut désormais utiliser le multicœur avec tous les codecs inclus.
  • Il utilise FFmpeg avec LAME pour encoder des MP3 pour un service d’hébergement audio, et il aimerait pouvoir réduire le temps d’encodage des fichiers longs.