Trois défis technologiques pour adapter FFmpeg aux standards TR-03

L’industrie de la radiodiffusion aujourd’hui

« Aujourd’hui, la magie du cinéma et de la télévision, c’est une histoire de sorcellerie technique » (SMPTE, 2017). Les grands radiodiffuseurs (comme Radio Canada) dépendent en grande partie d’équipements de radiodiffusion professionnels aux standards développés par la Société des Motion Pictures et Television Engineers® (SMPTE®). En plus d’arrimer par des standards universels, les diffuseurs et les fournisseurs d’équipements, la SMPTE contribue à faire progresser l’ingénierie de l’image dans l’industrie mondiale de la radiodiffusion. Présentement, l’industrie se base sur des équipements puissants mais lourds, capables de transmettre des données brutes (c’est-à-dire des signaux vidéo numériques non compressés et non cryptés) vers des équipements (terminaux) de télédiffusion (TV, ordinateur, mobile, etc.). Récemment, notre équipe d’ingénieurs s’est lancée dans l’aventure (soutenue financièrement par Radio Canada) pour tester une hypothèse technologique : Transmettre des données brutes de 3,5 Gbps, à l’aide de la plateforme FFmpeg et d’un serveur standard, le tout, sans passer par un équipement spécialisé.

Logo de FFmpeg

Plusieurs enjeux sont apparus sur notre chemin. Tout d’abord, le format TR-03 ; celui-ci n’était pas supporté dans la version upstream de FFmpeg. Le second fut la quantité de données à traiter : on parle d’un débit d’environ 3Gb/s, ce qui, d’après les développeurs de FFmpeg, n’était probablement pas possible à traiter. Enfin, il nous fallait ajouter du transcodage dans le pipeline, ce qui impliquait une charge encore plus importante sur le CPU.

L’implémentation de TR-03 ne fut pas le plus grand défi car le format vidéo était relativement simple. Nous avons donc rapidement mis en route un émetteur en utilisant GStreamer, qui possédait déjà les capacités nécessaires à l’envoi d’un tel volume de données.

Big Buck Bunny est un court métrage d’animation animé de l’Institut Blender, publié sous la forme d’un film open source sous Creative Commons License Attribution 3.0.

Une fois le flux de données en place, les freins à la performance sont devenus plus évidents. Pour identifier clairement ces freins, nous avons écrit plusieurs scénarios de référence utilisant des tests unitaires et LTTng (le roi des traceurs système sur Linux). Cela nous a permis de mettre le doigt là où nous perdions des paquets, en l’occurrence, ici au niveau de la socket dans le noyau, et au niveau des buffers de l’interface réseau. Étant donné que nous contrôlions étroitement le traitement des données, il fut relativement facile d’ajuster la taille de ces buffers tout en conservant des délais acceptables. Ensuite, nous avons remarqué que le thread de FFmpeg responsable de la collecte et de décodage des données monopolisait à lui seul tout un cœur du CPU, causant occasionnellement une perte de paquets lorsque nous n’étions pas assez rapide à récupérer les données du buffer de la socket. Pour palier à ce problème, nous avons découplé le travail de collecte des données du travail de décodage. La mise en place consciencieuse de ces étapes nous a permis d’obtenir un pipeline complet ne souffrant d’aucune perte de paquets. Nous avons donc pu célébrer notre réussite avec un bon gâteau, quelque verres et un film HD que nous pouvions enfin regarder (je ne m’attendais pas à ce que Big Buck Bunny soit si drôle à regarder).

La dernière mise à jour et les nouveaux défis

Le 5 avril dernier, les contributions développées et affinées par l’équipe ont finalement été intégrées à FFmpeg, ce qui signifie que leur preuve de concept a rencontré les normes énoncées par la communauté FFmpeg et fait désormais partie de la plateforme open source.

Pour notre équipe Ingénierie de Produits, c’est une aventure trépidante et prometteuse. En dépit de tous les risques et défis, notre équipe a empiriquement démontré la possibilité d’exécuter des pipelines de traitement SDI sur un serveur standard utilisant la plateforme FFmpeg. Cette expérience est une réussite, révélant en bout de ligne l’immense potentiel de FFmpeg dans l’industrie de la radiodiffusion. Pour continuer à adpater FFmpeg aux normes de SMPTE 2110 – en constante évolution – notre équipe fait désormais face à un autre défi de taille. FFmpeg ne supportant pas la synchronisation comme décrit dans SMTPE 2110, nos experts évaluent maintenant la possibilité d’apporter les contributions nécessaires pour relever ce nouvel enjeu !

Auteurs :

• Damien Riegel,
• Eloi Bail, et
• Stepan Salenikovitch.