- Meta exécute FFmpeg des dizaines de milliards de fois par jour et a réussi à migrer complètement de sa version forkée en interne vers FFmpeg upstream
- Pour combler l’écart fonctionnel entre le fork interne et la version open source, l’entreprise a collaboré avec FFlabs et VideoLAN afin d’implémenter en amont l’encodage parallèle multi-lane et des fonctions de métriques de qualité en temps réel
- En traitant plus d’un milliard d’uploads vidéo par jour, Meta réalise, avec une seule ligne de commande FFmpeg, des encodages multi-résolution et multi-codec pour la lecture DASH
- La structure de threading efficace implémentée dans les versions FFmpeg 6.0 à 8.0 repose sur la conception de Meta et améliore l’efficacité de l’encodage pour tous les utilisateurs
- Le circuit ASIC conçu en interne, MSVP (Meta Scalable Video Processor), a été intégré via l’API matérielle standard de FFmpeg afin d’assurer la cohérence entre les pipelines logiciels et matériels
- Grâce à un investissement continu dans FFmpeg, développé depuis plus de 25 ans, Meta renforce à la fois les nouvelles expériences vidéo et la stabilité de sa plateforme
Le rôle de FFmpeg et les défis de Meta
- FFmpeg est un outil de traitement média standard de l’industrie prenant en charge de nombreux codecs audio/vidéo et formats conteneurs, et permettant l’édition et la conversion via des chaînes de filtres complexes
- Meta exécute chaque jour des dizaines de milliards de fois les binaires ffmpeg (CLI principal) et ffprobe (utilitaire de consultation des propriétés des fichiers média), avec des besoins allant au-delà du simple traitement fichier par fichier
- Pendant longtemps, l’entreprise s’est appuyée sur un fork interne pour implémenter elle-même des fonctionnalités absentes d’upstream à l’époque, comme l’encodage multi-lane basé sur les threads et le calcul de métriques de qualité en temps réel
Divergence du fork interne et nécessité de revenir à l’upstream
- Le fork interne s’étant fortement éloigné de FFmpeg upstream, l’écart entre les ensembles de fonctionnalités n’a cessé de se creuser
- Dans le même temps, les nouvelles versions de FFmpeg apportaient la prise en charge de nouveaux codecs et formats de fichiers ainsi que des améliorations de stabilité ; il fallait donc aussi prendre en charge les dernières versions open source afin d’accepter sans interruption la diversité des contenus vidéo uploadés par les utilisateurs
- Comme il devenait difficile d’éviter les régressions lors du rebase des modifications internes, Meta a collaboré avec les développeurs de FFmpeg, FFlabs et VideoLAN pour abandonner entièrement son fork interne et passer à une utilisation exclusive de la version upstream
Mise en place d’un transcodage multi-lane efficace (VOD et live streaming)
- Lorsqu’un utilisateur upload une vidéo, Meta génère plusieurs ensembles d’encodage pour la lecture DASH (Dynamic Adaptive Streaming over HTTP), avec des encodages variant par résolution, codec, fréquence d’images et niveau de qualité
- Le lecteur vidéo de l’application peut basculer en temps réel entre ces encodages selon des signaux comme l’état du réseau
- L’approche la plus simple consiste à traiter chaque lane séquentiellement avec une ligne de commande FFmpeg distincte, mais même en exécution parallèle, chaque processus effectue des travaux redondants (décodage répété, surcoût de démarrage de processus), ce qui est inefficace
- Avec une seule ligne de commande FFmpeg, il est possible de ne décoder les frames qu’une seule fois avant de les envoyer à chaque encodeur de sortie, ce qui permet d’éliminer les décodages redondants et de réduire le surcoût de démarrage des processus
- Comme Meta traite plus d’un milliard d’uploads vidéo par jour, les économies de calcul par processus se traduisent globalement par un gain d’efficacité considérable
- Le fork interne de Meta ajoutait en plus des optimisations pour l’encodage vidéo parallèle : alors que FFmpeg exécutait auparavant plusieurs encodeurs en série, frame par frame, l’ensemble des instances d’encodeur était exécuté en parallèle afin d’obtenir un niveau de parallélisme supérieur
- Grâce aux contributions des développeurs de FFmpeg (dont FFlabs et VideoLAN), un threading plus efficace a commencé à être implémenté à partir de FFmpeg 6.0 pour être finalisé dans la version 8.0
- Cette évolution a été directement influencée par la conception du fork interne de Meta et est présentée comme le refactoring FFmpeg le plus complexe depuis des décennies
- Elle apporte à tous les utilisateurs de FFmpeg les bénéfices d’un encodage plus efficace
Métriques de qualité en temps réel (live streaming)
- Les métriques de qualité visuelle servent à exprimer numériquement la qualité perceptuelle d’un média afin de quantifier la perte liée à la compression
- Métriques de référence (reference metrics) : comparent un encodage source à un encodage dégradé
- Métriques sans référence (no-reference metrics) : évaluent la qualité sans original
- FFmpeg peut calculer des métriques de qualité comme PSNR, SSIM et VMAF après l’encodage, dans une ligne de commande séparée utilisant deux encodages existants, mais le live streaming exige un calcul en temps réel
- En insérant un décodeur vidéo derrière l’encodeur vidéo de chaque lane de sortie, il est possible d’obtenir le bitmap des frames après compression et de le comparer aux frames avant compression, ce qui permet de produire en temps réel les métriques de qualité de chaque lane d’encodage dans une seule ligne de commande FFmpeg
- À partir de FFmpeg 7.0, grâce aux contributions de FFlabs et des développeurs de VideoLAN, le décodage in-loop a été activé, supprimant totalement la dépendance au fork interne pour cette fonctionnalité
Critères de contribution à l’upstream et correctifs réservés à l’interne
- Des fonctionnalités comme les métriques de qualité en temps réel et le threading efficace ont été contribuées à l’upstream, car elles améliorent l’efficacité de nombreux pipelines basés sur FFmpeg, chez Meta comme ailleurs
- En revanche, les correctifs très spécialisés pour l’infrastructure de Meta et difficiles à généraliser sont conservés en interne
- FFmpeg prend en charge via une API standard le décodage, l’encodage et le filtrage accélérés par le matériel pour NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV, etc.
- L’ASIC de transcodage vidéo maison de Meta, MSVP (Meta Scalable Video Processor), a lui aussi été pris en charge via cette même API standard, permettant d’utiliser des outils communs sur différentes plateformes matérielles
- Comme MSVP n’est utilisé que dans l’infrastructure interne de Meta, les développeurs FFmpeg externes n’ont pas accès au matériel pour le tester et le valider ; le patch reste donc interne
- Lors du rebase vers les versions récentes de FFmpeg, une validation approfondie garantit la robustesse et l’exactitude
Investissement continu dans FFmpeg
- Grâce à l’encodage multi-lane et aux métriques de qualité en temps réel, Meta a complètement abandonné son fork interne dans tous ses pipelines VOD et live streaming
- L’API matérielle standard de FFmpeg permet de prendre en charge à la fois l’ASIC MSVP et les pipelines logiciels avec un minimum de friction
- Meta prévoit de continuer à investir dans FFmpeg, activement développé depuis plus de 25 ans, via des partenariats avec les développeurs open source, au bénéfice de Meta, du secteur et des utilisateurs
Aucun commentaire pour le moment.