FFmpeg est véritablement un multi-outil pour le traitement multimédia. En tant qu'outil standard de l'industrie, il prend en charge une large gamme de codecs audio et vidéo et de formats de conteneurs. Il peut également orchestrer des chaînes de filtres complexes pour l’édition et la manipulation des médias.. Pour les utilisateurs de nos applications, FFmpeg joue un rôle important en permettant de nouvelles expériences vidéo et en améliorant la fiabilité de celles existantes.

Meta est en cours d'exécution ffmpeg (l'application CLI principale) et ffsonde (un utilitaire pour récupérer les propriétés des fichiers multimédias) fichiers binaires des dizaines de milliards de fois par jour, ce qui présente des défis uniques lors de la gestion des fichiers multimédias. FFmpeg peut facilement gérer le transcodage et l'édition de fichiers individuels, mais nos flux de travail imposent des exigences supplémentaires pour répondre à nos besoins. Pendant de nombreuses années, nous avons dû compter sur nos propres moyens, branche développée en interne de FFmpeg pour fournir des fonctionnalités récemment ajoutées à FFmpeg, tel que: B. Encodage multivoie threadé et calcul des mesures de qualité en temps réel.

Au fil du temps, notre fork interne s'écartait considérablement de la version amont de FFmpeg. En même temps, les nouvelles versions de FFmpeg ont apporté la prise en charge de nouveaux codecs et formats de fichiers ainsi que des améliorations de fiabilité, nous permettant de capturer du contenu vidéo plus diversifié des utilisateurs sans interruption. Cela nous a obligé à prendre en charge les deux versions open source actuelles de FFmpeg en plus de notre fork interne.. Non seulement cela a conduit à un ensemble de fonctionnalités progressivement divergentes, mais aussi des défis pour rebaser en toute sécurité nos changements internes pour éviter les régressions.

Alors que notre fork interne devenait de plus en plus obsolète, nous avons travaillé avec les développeurs FFmpeg, FFlabs, et VideoLAN pour développer des fonctionnalités dans FFmpeg qui nous ont permis d'éliminer complètement notre fork interne et de nous appuyer uniquement sur la version amont pour nos cas d'utilisation. Utilisation de correctifs et de refactorisations en amont, nous avons pu combler deux lacunes importantes que nous devions auparavant combler sur notre fork interne: fileté, transcodage multipiste, et des mesures de qualité en temps réel.

Créer un transcodage multipiste plus efficace pour la VOD et le streaming en direct

Lorsqu'un utilisateur télécharge une vidéo via l'une de nos applications, nous générons un ensemble d'encodages pour prendre en charge le streaming adaptatif dynamique sur HTTP (TIRET) lecture. La lecture DASH permet à l'application’s lecteur vidéo pour sélectionner dynamiquement un encodage en fonction de signaux tels que les conditions du réseau. Ces encodages peuvent différer en résolution, codec, fréquence d'images et niveau de qualité visuelle, mais ils sont créés à partir du même encodage source et le joueur peut basculer entre eux de manière transparente en temps réel.

Dans un système très simple, des lignes de commande FFmpeg distinctes peuvent générer les encodages pour chaque piste un par un. Cela pourrait être optimisé en exécutant chaque instruction en parallèle, mais cela devient rapidement inefficace en raison du travail en double effectué par chaque processus.

Pour contourner cela, plusieurs sorties peuvent être générées dans une seule ligne de commande FFmpeg, avec une vidéo’trames s décodées une fois et envoyées à l'instance d'encodeur de chaque sortie. Cela élimine une grande partie de la surcharge de déduplication du décodage vidéo et du temps de démarrage du processus causé par chaque ligne de commande.. Étant donné que nous traitons plus 1 milliards de vidéos mises en ligne quotidiennement, chacun nécessitant plusieurs exécutions FFmpeg, les réductions de l'utilisation du calcul par processus se traduisent par des gains d'efficacité significatifs.

Notre fork FFmpeg interne a fourni une optimisation supplémentaire: codage vidéo parallélisé. Alors que les encodeurs vidéo individuels ont souvent du multithreading en interne, les versions précédentes de FFmpeg exécutaient chaque encodeur en série pour une image donnée lorsque plusieurs encodeurs étaient utilisés. En faisant fonctionner toutes les instances d'encodeur en parallèle, un meilleur parallélisme peut être obtenu globalement.

Merci aux contributions des développeurs FFmpeg, y compris ceux de FFlabs et VideoLAN, un threading plus efficace a été implémenté à partir de FFmpeg 6.0, avec la touche finale atterrissant 8.0. Cela a été directement influencé par la conception de notre fork interne et a été l'une des fonctionnalités clés sur lesquelles nous nous sommes appuyés.. Cette évolution a conduit à ceci Refactoring le plus complexe de FFmpeg depuis des décennies et a permis des encodages plus efficaces pour tous les utilisateurs de FFmpeg.

Pour migrer entièrement depuis notre fork interne, nous avions besoin d'une autre fonctionnalité pré-implémentée: mesures de qualité en temps réel.

Permet des mesures de qualité en temps réel lors du transcodage des flux en direct

Mesures de qualité visuelle, qui fournissent une représentation numérique de la qualité visuelle perçue des médias, peut être utilisé pour quantifier la perte de qualité causée par la compression. Ces métriques sont classées en métriques de référence ou non-référence, le premier comparant un référence coder vers un autre déformé Codage.

FFmpeg peut calculer diverses mesures de qualité visuelle telles que PSNR, SSIM et VMAF utilisant deux encodages existants sur une ligne de commande distincte une fois l'encodage terminé. C'est parfait pour les cas d'utilisation hors ligne ou VOD, mais pas pour le streaming en direct où nous souhaitons peut-être calculer des mesures de qualité en temps réel.

Pour ce faire, nous devons insérer un décodeur vidéo après chaque encodeur vidéo utilisé par chaque piste de sortie.. Ceux-ci fournissent des bitmaps pour chaque image de la vidéo après La compression a été appliquée afin que nous puissions comparer les images avant Compression. À la fin, nous pouvons créer une métrique de qualité pour chaque piste encodée en temps réel en utilisant une seule ligne de commande FFmpeg.

Grâce au décodage « en boucle » activé par les développeurs FFmpeg, y compris ceux de FFlabs et VideoLAN, en commençant par FFmpeg 7.0, nous n'avons plus besoin de compter sur notre fork FFmpeg interne pour cette fonctionnalité.

Nous en amont quand cela a le plus grand impact sur la communauté

Des éléments tels que des mesures de qualité en temps réel lors du transcodage et un threading plus efficace peuvent apporter des gains d'efficacité à une variété de pipelines basés sur FFmpeg à la fois à l'intérieur et à l'extérieur de Meta., et nous nous engageons à permettre ces développements en amont pour aider la communauté FFmpeg et l'industrie dans son ensemble. Cependant, il y a certains correctifs que nous avons développés en interne qui n'ont aucun sens pour contribuer en amont. Ceux-ci sont très spécifiques à notre infrastructure et ne se généralisent pas bien.

FFmpeg prend en charge le décodage accéléré matériel, encodage et filtrage avec des appareils tels que NVIDIA’NVDEC et NVENC, DMLA’s Décodeur vidéo unifié (UVD), et Intel’s Vidéo à synchronisation rapide (QSV). Chaque appareil est pris en charge par une implémentation d'API standards dans FFmpeg, permettant une intégration plus facile et minimisant le besoin d'indicateurs de ligne de commande spécifiques au périphérique. Nous’J'ai ajouté le support pour Processeur vidéo méta-évolutif (MSVP)notre ASIC personnalisé pour le transcodage vidéo, via les mêmes API et permet l'utilisation d'outils communs sur différentes plates-formes matérielles avec un minimum de particularités spécifiques à la plate-forme.

Puisque MSVP n'est utilisé que dans Meta’sa propre infrastructure, il serait difficile pour les développeurs FFmpeg de le prendre en charge sans accès au matériel pour les tests et la validation. Dans ce cas, il est logique de garder ces correctifs en interne, car ils ne seraient d'aucune utilité à l'extérieur. Nous avons pris la responsabilité de rebaser nos correctifs internes vers des versions plus récentes de FFmpeg au fil du temps., effectuer une validation approfondie pour garantir la robustesse et l'exactitude lors des mises à niveau.

Notre engagement continu envers FFmpeg

Grâce à un encodage multivoie plus efficace et à des mesures de qualité en temps réel, nous avons pu éliminer complètement notre fork interne FFmpeg pour tous les pipelines de VOD et de streaming en direct. Et grâce aux API matérielles standardisées dans FFmpeg, nous avons pu prendre en charge notre ASIC MSVP aux côtés de pipelines logiciels avec un minimum de friction.

FFmpeg a résisté à l'épreuve du temps avec plus de 25 années de développement actif. Développements qui améliorent l’utilisation des ressources, ajouter la prise en charge de nouveaux codecs et fonctionnalités, et une fiabilité accrue permettent une prise en charge robuste pour une gamme plus large de médias. Pour les personnes sur nos plateformes, cela signifie permettre de nouvelles expériences et améliorer la fiabilité de celles existantes. Nous prévoyons de continuer à investir dans FFmpeg en collaboration avec des développeurs open source, apporter des avantages à Meta, toute l'industrie, et les personnes qui utilisent nos produits.

Remerciements

Nous souhaitons reconnaître les contributions de la communauté open source, nos partenaires en FFlabs et VideoLAN, et de nombreux méta-ingénieurs, dont Max Bykov, Jordi Cenzano Furet, Tim Harris, Colleen Henri, Mark Shwartzman, Haixia Shi, Cosmin Stejerean, Hassène Tmar, et Victor Loh.