FFmpeg introduit un pipeline de transcodage multithread

 (ffmpeg.org)
2 points par GN⁺ 2023-11-07 | 1 commentaires | Partager sur WhatsApp
  • Le transcodage multithread de la CLI FFmpeg a été dévoilé dans une première version « entièrement fonctionnelle » après environ 2 ans de travail et plus de 700 commits préparatoires
  • En raison de l’ampleur des changements, certaines fonctionnalités peuvent encore être cassées, et les tests et la revue restent les tâches clés avant une fusion effective
  • -fix_sub_duration_heartbeat a du mal à éviter un comportement non déterministe en exécution asynchrone à cause des hypothèses de synchronisation entre le décodeur, l’encodeur et le muxer
  • La surcharge liée au threading est généralement faible, mais sur des tâches avec très peu de travail par paquet, son coût peut devenir plus visible que le gain de performances
  • Si le goulot d’étranglement n’est pas concentré dans un seul composant et que chaque composant n’est pas déjà multithreadé, l’utilisation CPU et le temps réel de traitement peuvent nettement s’améliorer en environnement multicœur

Points clés du patch de multithreading pour la CLI FFmpeg

  • Après environ 2 ans de travail et plus de 700 commits préparatoires, une première version « fully functional » de la CLI FFmpeg multithread est publiée sous forme de série de patchs
  • Vu l’ampleur des modifications, des régressions non détectées restent possibles, d’où la nécessité de tests et de revue fondés sur des cas d’usage réels
  • Dans les cas généraux, la surcharge du threading est faible, mais sur les workloads où la quantité de travail par paquet est très faible, cette surcharge peut devenir significative
  • Si le transcodage n’est pas dominé par un seul composant et que les différents composants ne sont pas déjà saturés par leur propre multithreading, l’utilisation CPU et le temps d’exécution peuvent s’améliorer sur les systèmes multicœurs

Contraintes de fonctionnement et problèmes connus

  • L’option -fix_sub_duration_heartbeat repose, dans la structure actuelle, sur une synchronisation entre composants séparés
    • Le flux concerné est une synchronisation de l’encodeur et du muxer vers le décodeur
    • Si chaque composant s’exécute de manière asynchrone, le comportement devient fondamentalement non déterministe
    • Même actuellement, le comportement est difficile à prévoir, mais avec la même option, les résultats restent déterministes d’une exécution à l’autre
    • Dans le patch 16/24, cette option est désactivée et une meilleure solution de traitement est nécessaire

Composition de la série de 24 patchs

  • La série comprend au total 24 patchs
    • Les patchs 01-09/24 sont des correctifs préparatoires et peuvent être poussés avant le reste de la série
    • Les patchs 10-17/24 déplacent l’encodage et le filtrage dans des threads et appliquent les changements préparatoires nécessaires
      • À ce stade, le threading est un « faux » threading où le thread principal attend la fin des autres threads, il ne s’agit donc pas encore d’une exécution réellement parallèle
      • Comme la surcharge temporaire peut être importante ou que certains cas limites peuvent être cassés, il est plus approprié de pousser l’ensemble une fois la série complète prête
    • Le patch 18/24 est le plus gros patch individuel et ajoute un scheduler de transcodage, mais il n’est pas encore réellement fonctionnel à ce stade
    • Les patchs 19-24/24 convertissent les composants individuels pour utiliser le scheduler
      • Ils sont séparés pour faciliter la revue, mais devraient être fusionnés lors du push final
  • Les ressources associées sont disponibles dans la récente présentation VDD et dans la branche ffmpeg_threading

À lire aussi

1 commentaires

 
GN⁺ 2023-11-07
Avis sur Hacker News

  • Sur un serveur ARM à 4 cœurs, c’est devenu environ 2 fois plus rapide, et le surcoût de la parallélisation semble faible
    ffmpeg_threading/ffmpeg a pris 7,771 secondes, contre 13,841 secondes pour ffmpeg classique, avec une utilisation CPU respective de 218 % et 114 %

    • Ici, l’accélération matérielle côté décodage n’est pas utilisée, et la sortie vidéo a aussi été supprimée
      Je me demande ce que ça donnerait sur une carte NVIDIA avec accélération matérielle à la fois pour le décodage et l’encodage vidéo : ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Je me demande quelle partie est multithreadée. La compression vidéo l’est déjà, mais je connais moins bien la décompression vidéo
      Le reste des opérations semble avoir un coût relativement faible en termes de performances, donc l’amélioration est bienvenue, mais son impact réel sera probablement assez limité

  • Il aurait sans doute mieux valu lier https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... plutôt qu’un tweet
    Le cœur du tweet, c’est de toute façon ce lien

    • Maintenant, on peut simplement dire post. Il n’y a plus de limite à 280 caractères, les longs messages étant simplement repliés par défaut

  • Pour comprendre le sujet, mieux vaut regarder la présentation d’Anton au VideoLAN Dev Days 2023 : https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • La présentation était bonne, et je me demande ce qu’il avait en tête avec les dynamic pipelines et le « scripting (Lua ?) » mentionnés dans « Future directions »
      Ça fait imaginer une orientation plus puissante pour gérer l’animation de propriétés
    • J’ai vraiment souvent rencontré des problèmes liés aux Extras montrés sur la diapo vers 33 minutes
    • J’aimerais vraiment regarder la présentation, mais la qualité audio est tellement mauvaise qu’il est difficile de rester concentré. Je ne comprends pas comment on peut encore rater ça à ce point aujourd’hui
    • Je ne vois pas ce qu’il y a de difficile à comprendre. Le terme multithread a-t-il un autre sens dans le domaine du transcodage vidéo ?

  • Le tweet renvoie vers http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655..., qui renvoie ensuite au code https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • Le tweet pointe vers la mailing list, source officielle du patchset. Pour continuer, il suffit de choisir « Next in Thread »

  • Je me demande si cela s’applique automatiquement, ou s’il faut combiner des paramètres en ligne de commande de façon compliquée

  • Je me demande s’il existe des logiciels de montage vidéo qui utilisent ffmpeg
    J’avais un temps envisagé de faire quelque chose qui dessinerait des formes en SVG et utiliserait ffmpeg, avec une UI, ou qui ajouterait simplement du texte, mais je ne m’y suis jamais mis
    Avidemux donne un peu cette impression, et les entrailles de ffmpeg sont assez brutes, donc un éditeur basé dessus serait probablement lourd, étrange et difficile à maintenir s’il fallait l’exposer via une GUI
    En revanche, un éditeur modulaire capable de générer des aperçus avec un interpréteur de commandes ou un visualiseur de pipeline semble possible
    ffmpeg est puissant, mais son usage uniquement en ligne de commande constitue un frein pour certains utilisateurs. J’avais autrefois écrit un script Python qui prenait un nombre aléatoire de clips et créait une mosaïque avec le filtre xstack, et ce n’était pas simple

  • J’aimerais bien que les petits travaux de transcodage pour Plex aillent plus vite
    Ma carte graphique ne prend pas en charge le transcodage matériel, donc c’est prometteur

  • Je cherchais des moyens d’accélérer le transcodage, et l’un consistait à utiliser l’accélération GPU, l’autre à augmenter le nombre de threads
    Cela dit, il est difficile de trouver le nombre optimal de threads

    • Pourquoi ne pas utiliser de l’optimisation d’hyperparamètres pour trouver la meilleure valeur ? Des outils comme Sherpa ou Scikit-optimize pourraient explorer un espace de recherche incluant le nombre de threads, le type d’entrée, le type de CPU, etc.
    • Pour la plupart des tâches, il suffit d’aligner le nombre de threads sur le nombre de vCPU. Donc un cœur avec hyperthreading compte pour 2
      Cela dit, si possible, l’accélération GPU est bien préférable

  • Je me demande quelles sont les exigences de licence pour un déploiement ffmpeg à grande échelle. Dans quels cas faut-il payer ?

    • « FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg. »
      http://ffmpeg.org/legal.html
      En d’autres termes, c’est gratuit, mais l’usage de certains modules peut poser problème si on les mélange à du code propriétaire
    • La manière courante d’utiliser ffmpeg dans un logiciel propriétaire consiste soit à compiler statiquement la version de ffmpeg utilisée et à la lier dans l’exécutable, soit à faire en sorte que le logiciel propriétaire l’appelle comme exécutable séparé

  • C’est bien de voir FFmpeg s’améliorer. J’espère qu’on verra aussi bientôt la prise en charge de Dolby AC4