Image of an arrow

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

admin_sflinux

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é.

Savoir-faire Linux relève le défi
L’hiver fut froid et enneigé à Montréal. Nous nous sommes donc réchauffés en passant du temps sur l’antre de FFmpeg. Notre but était de mettre en place un pipeline TR-03/SDI pouvant traiter plusieurs flux HD sur un serveur standard, tout en fabricant des dérivés basse définition du même flux grâce à FFmpeg.
Image result

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 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.

Articles similaires

Image of an arrow

Rennes, le 30 novembre 2017 – Savoir-faire Linux est fière d’annoncer l’installation à Rennes d’un centre d’expertise en ingénierie logicielle libre et systèmes embarqués pour desservir ses clients français et européens. Savoir-faire Linux est une entreprise québécoise experte en technologies libres et open source, leader au Canada et implantée en France depuis 2014. Elle a […]

30 Nov. 2017 Lecture de 4 minutes.

Savoir-faire Linux a envoyé l’un de ses experts en Birmanie pour une formation Linux auprès d’une jeune compagnie spécialisée dans l’équipement industriel. Découvrez le témoignage de Julien Grossholtz à la découverte de ce pays à la fois énigmatique et pittoresque. Je suis allé en Birmanie pour donner une formation dans ma spécialité : Linux Embarqué au […]

18 Mai. 2017 Lecture de 3 minutes.
Thumbnail image

L’équipe Ingénierie de produits de Savoir-faire Linux, ainsi que l’équipe du projet Ring, se sont récemment installés dans les nouveaux locaux sur la rue Clark à Montréal. Mais après le bonheur de l’emménagement, un problème apparut : à l’heure du déjeuner, les livreurs devaient cogner à la porte pour rentrer. Notre équipe a donc imaginé, conçu […]

5 Mai. 2017 Lecture de 6 minutes.
Thumbnail image

C’est lors d’une discussion entre collègues qu’Emeric Vigier m’a mit sur la piste d’un logiciel nommé Sigrok. Cette suite logicielle permet d’extraire les données collectées par divers types d’analyseurs et de les afficher, voire de les traiter, à l’aide de décodeurs de protocole.

20 Nov. 2014 Lecture de 9 minutes.
Thumbnail image

Comment visualiser la fluctuation dans le temps d՚un signal sans oscilloscope à l՚aide d’un analyseur logique Saleae Logic et de Python?

30 Sep. 2014 Lecture de 5 minutes.
Fermer
Fermer