FR 3149455 A1 20241206 FR 2305553 A 20230602 Un procédé de traitement d’un flux multimédia comprenant une séquence d’images est proposé, qui comprend, à une unité de gestion de flux multimédia : générer des métadonnées de traçabilité d’une image de la séquence d’images ; insérer les métadonnées de traçabilité de l’image dans un flux de données supplémentaires obtenu par l’unité de gestion de flux multimédia ; et multiplexer le flux multimédia et le flux de données supplémentaires. Figure de l’abrégé : Figure 2 PROCEDE DE TRAITEMENT DE FLUX VIDEO ET EQUIPEMENT POUR LA MISE EN ŒUVRE DU PROCEDE La présente divulgation se rapporte à un procédé de traitement de flux vidéo et un dispositif pour la mise en œuvre de ce procédé. Elle s’applique notamment à la mesure de latence dans une chaine de distribution d’un flux vidéo. Les données vidéo font en général l’objet d’un codage source visant à les compresser afin de limiter les ressources nécessaires à leur transmission et/ou à leur stockage. Il existe de nombreux standards de codage, tels que H.264/AVC, H.265/HEVC et MPEG-2, qui peuvent être utilisés à cette fin. On considère un flux vidéo comprenant un ensemble d’images. Dans les schémas de codage classique, les images du flux vidéo à encoder sont typiquement considérées selon une séquence d’encodage, et chacune est divisée en ensembles de pixels eux aussi traités séquentiellement. La distribution de contenus multimédia, tels que des flux vidéo, utilise typiquement une tête de réseau de distribution vidéo comprenant une unité d’encodage vidéo qui reçoit en entrée des contenus à encoder et délivre à une unité de mise en forme (parfois dénommée en anglais « packager ») des flux encodés dits « flux élémentaires ». Un contenu reçu en entrée est encodé selon une pluralité de profils d’encodage (un profil étant par exemple défini avec des paramètres de codec, de résolution et de débit). Les données produites par le packager sur la base des flux élémentaires sont typiquement fournies par le packager à un serveur de contenus, puis stockées sur des réseaux de distribution de contenus, appelés « CDN » (de l’anglais « Content Delivery Network »), fournissant des capacités de cache qui permettent d'améliorer la qualité des services, et de minimiser les temps d'accès et la latence pour la visualisation de contenus par un ou plusieurs terminaux de lecture (aussi couramment appelés « lecteurs vidéo »). Pour mesurer la latence dans une chaîne de diffusion audiovisuelle dans laquelle un flux vidéo est distribué, une possibilité consiste à inscrire (le terme anglais « burn » est parfois utilisé pour désigner cette inscription ou ce marquage) la date courante dans un indicateur du flux vidéo avant encodage, puis de comparer cet indicateur temporel avec la date au moment de l’affichage par un lecteur vidéo. L’indicateur de date peut prendre la forme d’un code à lecture rapide (en anglais, « QR code »), afin d’automatiser la mesure de latence au moment de l’affichage. Cependant, ce procédé requiert de modifier les images du flux vidéo en incrustant un élément supplémentaire (par exemple en incrustant une information de date pour effectuer une mesure de latence), de sorte que certaines au moins des images du flux vidéo sur lequel la mesure est effectuée sont modifiées irrémédiablement. Ce procédé consistant à inscrire des informations utiles pour la mesure souhaitée dans le flux vidéo présente plusieurs inconvénients : d’une part, le flux vidéo est dégradé, ce qui empêche d’effectuer toute mesure dans un contexte de mise en production et limite les autres mesures qui seraient autrement possibles sur le flux, comme par exemple une mesure de comparaison de qualité entre le flux vidéo source et le flux vidéo en sortie de la chaîne de diffusion. D’autre part, il est uniquement possible de marquer une image non compressée, ce qui exclut toute mesure dans un élément de la chaine de distribution ne traitant pas le flux décodé, tel que par exemple le packager, et réduit ainsi le nombre d’éléments de la chaine à partir desquels une mesure de latence peut être effectuée. En effet, la mesure de latence étant réalisée sur des images décodées, il est nécessaire d’utiliser un lecteur vidéo placé en chaque point de mesure. Cependant, le temps de décodage de ce lecteur n’est pas maitrisé, et introduit un biais dans la mesure de latence. Il existe ainsi un besoin pour un procédé de traitement de flux vidéo, et pour un équipement pour la mise en œuvre du procédé, permettant d’éviter ou d’atténuer les inconvénients précités. Il existe aussi un besoin pour un procédé de traitement de flux vidéo permettant de mesurer la latence au cours de la distribution du flux dans une chaine de distribution (ou de distribution de flux vidéo), et pour un équipement pour la mise en œuvre du procédé, permettant d’éviter ou d’atténuer les inconvénients précités. Résumé La présente divulgation vient améliorer la situation. Selon un premier aspect, il est proposé un procédé de traitement d’un flux multimédia comprenant une séquence d’images, le procédé pouvant être mis en œuvre par une unité de gestion de flux multimédia, par exemple d’un système de distribution multimédia, et comprenant : générer des données de traçabilité de message de signalisation; modifier un message de signalisation comprenant un marqueur d’une image de la séquence d’images, le message de signalisation étant obtenu par l’unité de gestion de flux multimédia, le message de signalisation étant modifié en insérant les données de traçabilité du message de signalisation dans le message de signalisation; et insérer le message de signalisation modifié dans le flux multimédia. Selon une variante du premier aspect, il est proposé un procédé de traitement d’un flux multimédia comprenant une séquence d’images, le procédé pouvant être mis en œuvre par une unité de gestion de flux multimédia, par exemple d’un système de distribution multimédia, et comprenant : générer des données de traçabilité de message de signalisation; modifier un message de signalisation d’un évènement associé à une image de la séquence d’images, le message de signalisation étant obtenu par l’unité de gestion de flux multimédia, le message de signalisation étant modifié en insérant les données de traçabilité du message de signalisation dans le message de signalisation; et insérer le message de signalisation modifié dans le flux multimédia. Le procédé proposé selon le premier aspect pourra avantageusement être mis en œuvre au sein de tout dispositif, comme par exemple une unité de gestion de flux multimédia (telle que, par exemple, une unité de gestion de flux vidéo), configurée pour être mise en œuvre au sein d’une chaîne de diffusion audiovisuelle, par exemple selon un schéma de transport de flux vidéo de type MPEG2-TS (de l’anglais « Moving Picture Expert Group 2 - Transport Stream »), « HLS » (de l’anglais « HTTP Live Streaming », l’acronyme « HTTP » désignant le protocole « HyperText Transfer Protocol »), « MSS » (de l’anglais « Microsoft Smooth Streaming »), « HDS » (de l’anglais « HTTP Dynamic Streaming »), « MPEG-DASH » (de l’anglais « MPEG Dynamic Adaptive Streaming over HTTP »), CMAF-ingest (de l’anglais « Common Media Application Format »), CMAF ou « HAS » (de l’anglais « HTTP Adaptive Streaming »), ou en utilisant une technologie de diffusion télévisuelle de contenus multimédia sur un réseau de diffusion de télévision, par exemple selon un schéma de type « DVB » (de l’anglais « Digital Video Broadcast »), ou de type « ATSC » (de l’anglais « Advanced Television Systems Committee »), tel que, de manière non limitative, un encodeur vidéo, par exemple conforme à la spécification AV1 actuelle ou à ses évolutions, une unité de type mise en forme (« packager »), tout ordinateur, serveur, équipement de tête de réseau de diffusion audiovisuelle, équipement de réseau de diffusion audiovisuelle, etc. Dans un ou plusieurs modes de réalisation, les données de traçabilité de message sont insérées dans un champ du message de signalisation. Dans un ou plusieurs modes de réalisation, le message de signalisation est compris dans le flux multimédia, et le procédé proposé comprend en outre : extraire du flux multimédia le message de signalisation. Selon un deuxième aspect, il est proposé un procédé de traitement d’un flux multimédia distribué par une chaîne de distribution multimédia dans un système de distribution multimédia, le flux multimédia comprenant une séquence d’images, le procédé étant mis en œuvre par une unité de traitement du système de distribution multimédia et comprenant : sur détection, dans le flux multimédia, à un premier point de la chaine de distribution multimédia, d’un message de signalisation comprenant un marqueur d’une image de la séquence d’images, extraire du message de signalisation des données de traçabilité de message de signalisation (par exemple traçabilité lors du transport de ce message dans la chaine de distribution multimédia), sur extraction du message de signalisation des données de traçabilité de message de signalisation, générer des premières données d’horodatage de détection du message de signalisation au premier point de la chaine de distribution multimédia ; sur détection, dans le flux multimédia, du message de signalisation à un deuxième point de la chaine de distribution multimédia, sur détermination que le message de signalisation comprend les données de traçabilité de message de signalisation, générer des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point de la chaine de distribution multimédia ; et déterminer une mesure de latence associée à l’image sur la base des premières et deuxièmes données d’horodatage. Le procédé proposé permet avantageusement de déterminer une mesure de latence sans dégrader le flux vidéo utilisé pour sa mise en œuvre. En effet, le procédé proposé permet d’effectuer une mesure une latence sur un flux multimédia distribué par les dispositifs d’une chaine de distribution multimédia en traçant en plusieurs points de la chaine de distribution un message de signalisation du flux (par exemple intégré au flux multimédia en amont de la chaine de distribution) qui référence une image du flux multimédia. Des horodatages de détection du message de signalisation peuvent être relevés respectivement à plusieurs points de mesure de latence sur la chaine de distribution, de manière à déterminer un écart temporel entre deux horodatages. La mesure de latence peut ensuite être déterminée pour l’image sur la base de l’écart temporel déterminé entre les horodatages de passage du message de signalisation, et les écarts temporels déterminés entre le message de signalisation et l’image aux différents points de mesure. Par exemple, l’écart temporel déterminé entre les horodatages de passage du message de signalisation peut être combiné avec les écarts temporels déterminés entre le message de signalisation et l’image aux différents points de mesure, pour obtenir une mesure de latence pour l’image. L’utilisation d’un message de signalisation présente l’avantage de permettre de tracer temporellement le passage d’une image auquel il fait référence en différents points de mesure de la chaine de distribution. Des standards de signalisation tels que le standard SCTE-35 peuvent avantageusement être utilisés pour la mise en œuvre du procédé proposé au sein d’une chaîne de distribution, par exemple de type OTT, étant donné que les messages de ce standard sont couramment utilisés, notamment pour signaler des ruptures de flux pour insérer des publicités, et qu’ils ne sont dès lors pas filtrés par les nœuds de la chaîne de distribution. En outre, le procédé proposé permet la mise en œuvre d’une mesure de latence automatisée, par exemple en utilisant une unité de gestion de flux configurée pour mettre en œuvre un mode de réalisation du procédé proposé de mesure de latence en plusieurs points de mesure d’une chaîne de distribution. De plus, le procédé proposé peut être mis en œuvre dans tout élément d’une chaine de distribution, y compris un élément de la chaîne traitant des flux compressés, de sorte qu’il offre une flexibilité accrue en permettant des mesures de latence à différents niveaux de la chaine de distribution. En outre, au contraire des procédés qui utilisent une modification d’une image du flux multimédia en y incrustant une information d’horodatage ou qui utilisent un système de données de sous-titrage, le procédé proposé permet avantageusement d’obtenir une mesure de latence d’une image d’un flux multimédia distribué vers des dispositifs de lecture vidéo par une chaine de distribution multimédia, sans nécessairement avoir recours à un dispositif de lecture vidéo (par exemple pour accéder à une information d’horodatage incrustée sur une image du flux ou insérée dans des données de sous-titrage), tout en permettant une mesure de latence à partir de différents points d’une chaine de distribution de flux vidéo. Le procédé proposé, selon ses différents aspects, utilise avantageusement un message de signalisation du flux multimédia qui comprend un marqueur de l’image dont on souhaite mesurer la latence dans le transport au sein de la chaine de distribution. Le procédé proposé utilise des données de traçabilité du message de signalisation afin de pouvoir détecter le passage du message de signalisation en au moins deux points distincts de la chaine de distribution du flux multimédia. En fonction de différents modes de réalisation, le message de signalisation utilisé pour déterminer une mesure de latence dans la chaine de distribution peut être déjà présent dans le flux multimédia, par exemple dans des cas de figures où il a été inséré dans ce flux en amont de l’unité de gestion de flux multimédia proposée, ou être généré par l’unité de gestion de flux multimédia proposée. Le procédé proposé convient particulièrement bien, bien que de façon non exclusive, pour la mesure de latence et/ou pour la détection et la mesure de dérive de latence dans une chaîne de diffusion audiovisuelle, entre une unité de gestion de flux multimédia de la chaîne et tout dispositif de traitement et/ou de distribution de la chaîne de distribution placé en aval de l’unité de gestion de flux multimédia. Le procédé proposé n’est pas limité à des mises en œuvre au sein d’une unité de gestion de flux multimédia, et peut être mis en œuvre dans toute unité de traitement de flux multimédia configurée pour la mise en œuvre d’un procédé proposé selon un mode de réalisation de la présente divulgation. L’unité de traitement de flux multimédia pourra être mise en œuvre sous forme logicielle, auquel cas elle prendra la forme d’un programme exécutable par un processeur, sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC, de l’anglais « Application Specific Integrated Circuit »), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme un système informatique comprenant un processeur, auquel cas elle pourra comprendre une interface d’entrée, une mémoire couplées de manière opérationnelle avec au moins un processeur configuré pour la mise en œuvre du procédé proposé, ou comme un composant de réseaux logiques programmables (FPGA, de l’anglais « Field Programmable Gate Arrays »). En fonction du mode de réalisation choisi, l’unité de traitement de flux vidéo pourra être mise en œuvre, en tout ou partie, au sein d’un encodeur vidéo, d’un packager, d’un décodeur vidéo, d’un capteur vidéo et/ou de tout ordinateur ou composant FPGA configuré pour mettre en œuvre l’unité de traitement de flux multimédia. Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres. Dans un ou plusieurs modes de réalisation, le procédé proposé selon le deuxième aspect comprend en outre : déterminer un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point et un temps de mise à disposition de l’image au premier point, et déterminer un deuxième écart temporel entre les deuxièmes données d’horodatage de détection du message de signalisation au deuxième point et un temps de mise à disposition de l’image au deuxième point, et la mesure de latence est déterminée sur la base d’une combinaison des premières données d’horodatage, des deuxièmes données d’horodatage et des premier et deuxième écarts temporels. Dans un ou plusieurs modes de réalisation du procédé proposé selon le deuxième aspect, la chaine de distribution multimédia comprend une unité de mise en forme, le premier point de la chaine de distribution multimédia est en amont de l’unité de mise en forme et le deuxième point de la chaine de distribution multimédia est en aval de l’unité de mise en forme, et le procédé proposé comprenant en outre : extraire du flux multimédia au deuxième point de la chaine de distribution multimédia une métadonnée de l’image indiquant un positionnement de l’image au sein d’un ensemble d’images encodées. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, les données de traçabilité de message de signalisation comprennent des données d’identification utilisables pour identifier le message de signalisation. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, le marqueur de l’image comprend une information relative à un évènement associé à l’image. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, le message de signalisation comprend un temps d’occurrence de l’évènement. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, le temps d’occurrence de l’évènement correspond au temps de présentation de l’image. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, le message de signalisation est de type SCTE-35. Par exemple, le message de signalisation peut être une commande de type « time_signal ». Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier et/ou le deuxième aspect, les données de traçabilité sont insérées dans un descripteur du message de type SCTE-35. Dans un ou plusieurs modes de réalisation du procédé proposé selon le premier aspect, le procédé proposé comprend en outre : générer une pluralité de messages de signalisation respectivement associés à des images de la séquence d’images ; et, pour chaque message de signalisation de la pluralité de messages de signalisation : générer des données de traçabilité du message de signalisation; insérer dans le message de signalisation les données de traçabilité du message de signalisation; insérer le message de signalisation dans le flux multimédia, et la fréquence d’insertion des messages de signalisation dans le flux multimédia correspond à la fréquence d’insertion d’images de référence par un encodeur vidéo lors de l’encodage de la séquence d’images. Selon un autre aspect, un dispositif de traitement de flux vidéo est proposé, qui comprend : un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configuré pour la mise en œuvre d’un mode de réalisation d’un procédé proposé dans la présente divulgation. Selon un autre aspect, un programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un ou de plusieurs modes de réalisation d’un procédé proposé lors de l’exécution dudit programme par le processeur, est proposé. Un autre aspect concerne un ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur tel que proposé. Selon un autre aspect, un support de stockage non-transitoire d’un programme exécutable par ordinateur est proposé, qui comprend un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d’interface entrées/sorties, conduire l’ordinateur à mettre en œuvre un ou plusieurs modes de réalisation d’un procédé proposé. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que proposé dans les présentes lorsque ce programme est exécuté par un processeur. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels : Fig. 1 montre un schéma de système de distribution de contenus multimédia pour la mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation. Fig. 2 montre un diagramme illustrant un exemple de mise en œuvre d’un procédé proposé selon un ou plusieurs modes de réalisation. Fig. 3a montre un exemple de flux multimédia selon un ou plusieurs modes de réalisation. Fig. 3b montre un exemple de distribution d’un flux multimédia selon un ou plusieurs modes de réalisation. Fig. 4a montre un exemple non limitatif de mise en œuvre d’un procédé proposé de mesure de latence d’une image d’un flux multimédia selon un ou plusieurs modes de réalisation. Fig. 4b montre un exemple d’architecture de mesure de latence dans une chaîne de distribution de contenus multimédia selon un ou plusieurs modes de réalisation du procédé proposé. Fig. 5a montre un schéma illustrant un exemple d’architecture d’un dispositif pour la mise en œuvre d’un procédé proposé selon un ou plusieurs modes de réalisation. Fig. 5b montre un schéma illustrant un exemple d’architecture d’un dispositif pour la mise en œuvre d’un procédé proposé selon un ou plusieurs modes de réalisation. Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la description. La présente description fait référence à des systèmes, sous-systèmes, fonctions, moteurs, unités, modules, plateformes, et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des systèmes, sous-systèmes, fonctions, moteurs, modules, plateformes, unités et diagrammes décrits peut être mis en œuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué («firmware»), ou de «middleware»), microcode, ou toute combinaison de ces derniers. Dans le cas d’une mise en œuvre sous forme logicielle, les systèmes, sous-systèmes, fonctions, moteurs, unités, modules, plateformes et/ou illustrations de diagrammes peuvent être mis en œuvre par des instructions de programme d’ordinateur ou du code logiciel, qui peut être stocké ou transmis sur un support lisible par ordinateur, incluant un support non transitoire, ou un support chargé en mémoire d’un ordinateur générique, spécifique, ou de tout autre appareil ou dispositif programmable de traitement de données pour produire une machine, de telle sorte que les instructions de programme d’ordinateur ou le code logiciel exécuté(es) sur l’ordinateur ou l’appareil ou dispositif programmable de traitement de données, constituent des moyens de mise en œuvre de ces systèmes, sous-systèmes, fonctions, moteurs, unités, modules, plateformes et/ou illustrations de diagrammes. Les modes de réalisation d’un support lisible par ordinateur incluent, de manière non exhaustive, des supports de stockage informatique et des supports de communication, y compris tout support facilitant le transfert d’un programme d’ordinateur d’un endroit vers un autre. Par «support(s) de stockage informatique», on entend tout support physique pouvant être accédé par ordinateur. Les exemples de support de stockage informatique incluent, de manière non limitative, les disques ou composants de mémoire flash ou tous autres dispositifs à mémoire flash (par exemple des clés USB, des clés de mémoire, des sticks mémoire, des disques-clés), des CD-ROM ou autres dispositifs de stockage optique de données, des DVD, des dispositifs de stockage de données à disque magnétique ou autres dispositifs de stockage magnétique de données, des composants de mémoire de données, des mémoires RAM, ROM, EEPROM, des cartes mémoires («smart cards»), des mémoires de type SSD («Solid State Drive»), et toute autre forme de support utilisable pour transporter ou stocker ou mémoriser des données ou structures de données qui peuvent être lues par un processeur d’ordinateur. En outre, diverses formes de support lisible par ordinateur peuvent transmettre ou porter des instructions vers un ordinateur, telles qu’un routeur, une passerelle, un serveur, ou tout équipement de transmission de données, qu’il s’agisse de transmission filaire (par câble coaxial, fibre optique, fils téléphoniques, câble DSL, ou câble Ethernet), sans-fil (par infrarouge, radio, cellulaire, microondes), ou des équipements de transmission virtualisés (routeur virtuel, passerelle virtuelle, extrémité de tunnel virtuel, pare-feu virtuel). Les instructions peuvent, selon les modes de réalisation, comprendre du code de tout langage de programmation informatique ou élément de programme informatique, tel que, sans limitation, les langages assembleur, C, C++, Visual Basic, HyperText Markup Language (HTML), Extensible Markup Language (XML), HyperText Transfer Protocol (HTTP), Hypertext Preprocessor (PHP), SQL, MySQL, Java, JavaScript, JavaScript Object Notation (JSON), Python, et bash scripting. De plus, les termes «notamment», «par exemple», «exemple», «typiquement» sont utilisés dans la présente description pour désigner des exemples ou illustrations de modes de réalisation non limitatifs, qui ne correspondent pas nécessairement à des modes de réalisation préférés ou avantageux par rapport à d’autres aspects ou modes de réalisation possibles. Par «serveur» ou «plateforme», on entend dans la présente description tout point de service (virtualisé ou non) ou dispositif opérant des traitements de données, une ou plusieurs bases de données, et/ou des fonctions de communication de données. Par exemple, et de manière non limitative, le terme «serveur» ou le terme «plateforme» peut faire référence à un processeur physique couplé de manière opérationnelle avec des fonctions de communication, de base de données et de stockage de données associées, ou faire référence à un réseau, un groupe, un ensemble ou un complexe de processeurs et des équipements de stockage de données et de mise en réseau associés, ainsi qu’un système d’exploitation et un ou plusieurs système(s) de base de données et des logiciels applicatifs en support des services et fonctions fournies par le serveur. Un dispositif informatique peut être configuré pour envoyer et recevoir des signaux, par réseau(x) de transmission sans-fil et/ou filaire, ou peut être configuré pour des traitements et/ou du stockage de données ou de signaux, et peut donc fonctionner en tant que serveur. Ainsi, des équipements configurés pour opérer en tant que serveur peuvent inclure, à titre d’exemples non limitatifs, des serveurs dédiés montés sur rack, des ordinateurs de bureau, des ordinateurs portables, des passerelles de service (parfois appelées «box» ou «passerelle résidentielle»), des décodeurs multimédia (parfois appelés «set-top boxes»), des équipements intégrés combinant diverses fonctionnalités, telles que deux ou plus des fonctionnalités mentionnées ci-dessus. Les serveurs peuvent fortement varier dans leur configuration ou leurs capacités, mais un serveur inclura généralement une ou plusieurs unité(s) centrale(s) de traitement et une mémoire. Un serveur peut aussi inclure un ou plusieurs équipement(s) de mémoire de masse, une ou plusieurs alimentation(s) électrique(s), une ou plusieurs interface(s) réseau sans-fil et/ou filaire(s), une ou plusieurs interface(s) d’entrée/sortie, un ou plusieurs système(s) d’exploitation, tel(s) que Windows Server, Mac OS X, Unix, Linux, FreeBSD, or un équivalent. Par « distribution OTT » (de l’anglais « Over-The-Top »), on entend toute distribution ou diffusion de contenus multimédia à travers un réseau non dédié à la distribution ou de diffusion de contenus multimédia (par exemple à travers un réseau de communication de données tel que le réseau Internet). Dans la présente description, les termes « fragment » et « segment » sont utilisés de manière interchangeable pour désigner un ensemble d’une ou plusieurs images ou, selon le cas, d’un ou plusieurs échantillons audio, qui constitue la brique élémentaire référencée dans les formats OTT (comme par exemple HLS, DASH, ou CMAF). Par « contenu multimédia », on entend dans la présente description tout contenu de type audio et/ou vidéo, audiovisuel, sous-titres, musique, son, image et interface graphique interactive, et toute combinaison de ces types de contenu. Dans la présente description, les termes distribution « en temps-réel », distribution « en mode linéaire », distribution « en mode TV linéaire », distribution « en mode dynamique » et distribution « live » ou « en mode live » sont utilisés de manière interchangeable pour désigner la distribution en mode ou de type dynamique (en anglais mode « live » ou « dynamic ») d’un contenu multimédia dans un système de distribution de contenus vers des terminaux, comprenant notamment la distribution du contenu à mesure que celui-ci est généré, par opposition à la distribution d’un contenu précédemment généré, sur requête d’accès d’un utilisateur (distribution sur requête d’accès ou distribution en mode ou de type « statique » - en anglais, « static »), tel que, par exemple, un contenu enregistré sur un serveur, et rendu disponible à des utilisateurs par un service de vidéo à la demande (VOD). Dans la présente description, les termes « contenu live » font référence à un contenu, par exemple de type multimédia, distribué, par exemple selon un mode de distribution OTT, en mode dynamique (par opposition au mode statique de distribution). Un contenu live sera typiquement généré par une chaîne de télévision, ou par tout type de média télévisuel, et pourra être par ailleurs diffusé sur un réseau de diffusion de contenus multimédia, outre sa mise à disposition sur des serveurs de contenus dans un système de distribution OTT. Dans la présente description, les termes « terminal », « équipement utilisateur », « lecteur », « dispositif de lecture », « terminal de lecture » et « lecteur vidéo » sont utilisés de manière interchangeable pour désigner tout type de dispositif, mis en œuvre par un ou plusieurs logiciels, un ou plusieurs matériels, ou une combinaison d’un ou plusieurs logiciels et d’un ou plusieurs matériels, configuré pour utiliser un contenu multimédia distribué selon un protocole de distribution multi-écrans, notamment en chargement et en lecture du contenu. Les termes « client » et « client de lecture vidéo » sont aussi utilisés de manière interchangeable pour désigner tout type de dispositif, logiciel et/ou matériel, ou toute fonction ou ensemble de fonctions, mise(s) en œuvre par logiciel et/ou matériel au sein d’un dispositif, configurés pour utiliser un contenu multimédia distribué selon un protocole de distribution multi-écrans, notamment en chargement du contenu depuis un serveur et en lecture du contenu. Les termes «réseau» et «réseau de communication» tels qu’utilisés dans la présente description font référence à une ou plusieurs liaisons de données qui peuvent coupler ou connecter des équipements, éventuellement virtualisés, de manière à permettre le transport de données électroniques entre des systèmes informatiques et/ou des modules et/ou d’autres dispositifs ou équipements électroniques, tel qu’entre un serveur et un dispositif client ou d’autres types de dispositifs, y compris entre dispositifs sans fil couplés ou connectés par un réseau sans fil, par exemple. Un réseau peut aussi inclure une mémoire de masse pour stocker des données, tel qu’un NAS (en anglais «network attached storage», un SAN (en anglais «storage area network»), ou toute autre forme de support lisible par un ordinateur ou par une machine, par exemple. Un réseau peut comprendre, en tout ou partie, le réseau Internet, un ou plusieurs réseaux locaux (en anglais «local area networks», ou LANs), un ou plusieurs réseaux de type WAN (en anglais «wide area networks»), des connexions de type filaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. De manière similaire, des sous-réseaux peuvent utiliser différentes architectures ou être conformes ou compatibles avec différents protocoles, et inter-opérer avec des réseaux de plus grande taille. Différents types d’équipements peuvent être utilisés pour rendre interopérables différentes architectures ou différents protocoles. Par exemple, un routeur peut être utilisé pour fournir une liaison de communication ou une liaison de données entre deux LANs qui seraient autrement séparés et indépendants. Les termes «couplé de manière opérationnelle», «couplé», «monté», «connecté» et leurs variantes et formes diverses utilisés dans la présente description font référence à des couplages, connexions, montages, qui peuvent être directs ou indirects, et comprennent notamment des connexions entre équipements électroniques ou entre des portions de tels équipements qui permettent des opérations et fonctionnements tels que décrits dans la présente description. De plus, les termes «connectés» et «couplés» ne sont pas limités à des connections ou des couplages physiques ou mécaniques. Par exemple, un couplage de manière opérationnelle peut inclure une ou plusieurs connexion(s) filaire(s) et/ou une ou plusieurs connexion(s) sans-fil entre deux équipements ou plus qui permettent des liaisons de communication simplex et/ou duplex entre les équipements ou des portions des équipements. Selon un autre exemple, un couplage opérationnel ou une connexion peut inclure un couplage par liaison filaire et/ou sans-fil pour permettre des communications de données entre un serveur du système proposé et un autre équipement du système. Le monde de la distribution ou distribution (en anglais, « broadcast ») de la télévision numérique a connu de véritables mutations au cours de ces dernières années. A la distribution traditionnelle réalisée en mode dynamique via des opérateurs de télévision payante (ex. bouquets numériques et/ou fournisseurs d’accès Internet (FAI)) pour la télévision dite linéaire (ADSL (de l’anglais Asymmetric Digital Subscriber Line), Satellite, Câble, IPTV, Fibre, Télévision Numérique Terrestre (TNT), etc.), se sont ajoutés de nouveaux services audiovisuels tels que la vidéo à la demande (VOD, de l’anglais « Video On Demand »), ou la télévision de rattrapage (en anglais « Catch-Up TV » ou « Replay »). La conception de nouveaux terminaux toujours plus puissants et plus mobiles, la demande croissante de consommation de contenus indépendants de l’emplacement du consommateurs (en anglais «TV everywhere »), ainsi que le développement d’infrastructures réseaux offrant toujours plus de bande passante, ont conduit à l’émergence d’un nouveau marché ne nécessitant pas de posséder le réseau d’accès vers les utilisateurs, et appelé service par contournement (OTT, de l’anglais « Over-The-Top »). Le marché OTT opère sur des réseaux dits non managés (i.e. avec bande passante et qualité de service (en anglais QoS, pour « Quality of Service ») non assurées). Ces services OTT multi-écrans sont fournis par les compagnies de distribution/redistribution que sont les diffuseurs de contenus télévisuels et les opérateurs télécoms. Les infrastructures de distribution sont ainsi aujourd’hui doublées, une pour le broadcast traditionnel et une (au moins) pour la distribution OTT. Afin d’adresser les services de distribution de contenus multi-écrans, divers protocoles ont été développés, tels que Apple HLS (HTTP Live Streaming), Microsoft Smooth Streaming (MSS), Adobe HTTP Dynamic Streaming (HDS), MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH) et MPEG Common Media Application Format (MPEG-CMAF). Tous ces protocoles sont basés sur le concept de distribution au fil de l’eau (en anglais, « streaming ») adaptative utilisant le protocole HTTP (de l’anglais « HyperText Transfer Protocol ») (en anglais HAS, pour « HTTP Adaptive Streaming »). La distribution de contenus multi-écrans utilise typiquement une tête de réseau de distribution vidéo comprenant une unité d’encodage vidéo qui reçoit en entrée des contenus à encoder et délivre à une unité de mise en forme (parfois dénommée en anglais « packager ») des flux encodés dits « flux élémentaires ». Un contenu reçu en entrée est encodé selon une pluralité de profils d’encodage (un profil étant par exemple défini avec des paramètres de codec, de résolution et de débit). Les flux encodés (flux élémentaires) délivrés par l’unité d’encodage vidéo sont découpés au sein de l’unité de mise en forme en au moins deux séquences de segments successifs, respectivement audio et vidéo, les segments étant généralement de durée fixe (typiquement de quelques secondes), dont le format dépend du protocole choisi (par exemple MPEG2-TS, MP4, etc.). Pour chaque contenu, un ensemble de métadonnées relatives à des contenus multimédias, parfois appelé conteneur de présentation de media (de l’anglais « Media Presentation Description », ou MPD) ou « manifeste » (de l’anglais « manifest »), est aussi généré par l’unité de mise en forme, par exemple sous forme d’un fichier, par exemple au format XML, indiquant les caractéristiques de chaque profil et les segments disponibles correspondant au contenu. Ces manifestes et les segments associés sont fournis par l’unité de mise en forme à un serveur de contenus, puis stockés sur des réseaux de distribution de contenus, appelés « CDN » (de l’anglais « Content Delivery Network »), fournissant des capacités de cache qui permettent d'améliorer la qualité des services, et de minimiser les temps d'accès et la latence pour la visualisation de contenus par des terminaux de lecture. Un terminal de lecture vidéo de contenus distribués en mode dynamique (par exemple configuré au sein d’un équipement utilisateur tel qu’un smartphone, une tablette ou un tout autre type d’ordinateur), autrement dit un contenu vidéo de type dynamique, ou « live » (par opposition à un contenu de type statique, comme par exemple un contenu de VOD), sera typiquement configuré pour lire ce contenu en utilisant les informations contenues dans le manifeste associé au contenu. La montre un exemple d’architecture de système de distribution de contenus multimédia comprenant un sous-système de mise en forme (en anglais « packager ») et un encodeur vidéo, ces deux dispositifs fournissant deux exemples non limitatifs de dispositif de traitement de flux multimédia selon un ou plusieurs modes de réalisation. La montre un système (100) comprenant un sous-système (101) de distribution de contenus multimédia (par exemple vidéo) configuré pour distribuer des contenus multimédia vers un ou plusieurs terminaux utilisateur (par exemple des lecteurs vidéo (102) comme illustré sur la figure) situés en bout de chaine de distribution vidéo, par exemple sur requête de ces lecteurs vidéo (102). Dans un ou plusieurs modes de réalisation, le sous-système (101) peut typiquement comprendre un sous-système de transcodage (103) (en anglais « Live Transcoder ») configuré pour recevoir en entrée des flux de données multimédia « Live » (103a) (en anglais « Live Channels ») et pour générer, sur la base des données de ces flux de données multimédia Live (103a) des flux multimédia source (104a) encodés (parfois appelés « flux élémentaires ») présentant des niveaux de qualité respectifs, qui sont fournis en sortie du sous-système de transcodage (103) à un sous-système de mise en forme (en anglais « Packager ») (104). Dans un ou plusieurs modes de réalisation, le sous-système de mise en forme (104) peut être configuré pour recevoir en entrée les flux média source (104a) et générer des contenus OTT (de l’anglais « Over The Top ») sur la base de requêtes reçues en provenance d’un lecteur vidéo (102) par le biais d’un réseau de communication de données (105), par exemple de type réseau de distribution de contenu (en anglais « Content Distribution Network » ou CDN) ou de type réseau de livraison de contenus (de l’anglais « Content Delivery Network », ou CDN). Le réseau (105) peut être utilisé comme réseau intermédiaire de transmission de données entre les lecteurs vidéo (102) et le sous-système de mise en forme (104) configuré pour servir des requêtes de contenus vidéo initiées par les lecteurs vidéo (102). Le sous-système de transcodage (103) pourra être configuré pour l’encodage ou la compression de données reçues sur des flux de données multimédia en mode « Live », qui typiquement ne seront pas compressés ou le seront très faiblement, au fur et à mesure de la réception des données de ces flux de données multimédia, et pour générer en sortie des flux de données multimédia encodés en mode « Live », c’est-à-dire au fur et à mesure de l’encodage des données. Un contenu reçu en entrée sera typiquement encodé selon une pluralité de profils d’encodage (un profil étant par exemple défini avec des paramètres de codec, de résolution et de débit). L’utilisation d’une pluralité de profils d’encodage présente au moins deux avantages : Tout d’abord, une pluralité de profils permet d’adresser des terminaux de lecture aux caractéristiques (codecs supportés, résolution d’écran, puissance de décodage) différentes. En outre, elle offre aux lecteurs vidéo de ces terminaux la possibilité de s’adapter en fonction de la bande passante réseau disponible. En effet, le lecteur d’un client (d’un terminal) pourra être configuré pour chercher à atteindre le profil d’encodage correspondant au plus haut débit, en fonction des mesures de bande passante qu’il effectue en permanence. En fonction du mode de réalisation, le sous-système de transcodage (103) pourra être configuré pour encoder ou compresser des contenus vidéo selon tout standard de compression vidéo, comme par exemple les standards HEVC (de l’anglais « High Efficiency Video Coding », AV1 ou VVC (de l’anglais « Versatile Video Coding ») ou leurs évolutions, et pour encoder ou compresser des contenus audio selon tout standard de compression audio, comme par exemple les standards AAC (de l’anglais « Advanced Audio Coding ») ou ses évolutions (dont AAC+, HE-AAC, eAAC+, HD-AAC), ou AC-4 ou ses évolutions. Le sous-système de transcodage (103) et/ou le sous-système de mise en forme (104) peuvent être avantageusement configurés pour mettre en œuvre le procédé proposé, afin d’effectuer des mesures de latence dans le sous-système (101) entre le sous-système de transcodage (103) et tout sous-système du sous-système (101) de distribution de contenus multimédia situé en aval du sous-système de transcodage (103) ou le lecteur vidéo (102), ou entre le sous-système de mise en forme (104) et tout sous-système (101) de distribution de contenus multimédia situé en aval du sous-système de mise en forme (104), ou le lecteur vidéo, respectivement. Comme illustré sur la , dans un ou plusieurs modes de réalisation, le sous-système de transcodage (103) comprend un ou plusieurs serveurs de transcodage, chaque serveur pouvant comprendre une ou plusieurs unités d’encodage et/ou de transcodage. Les serveurs de transcodage seront typiquement configurés pour l’encodage de contenus (comme par exemple des contenus vidéo et/ou des contenus audio) correspondant à l’un des flux de données multimédia Live reçus par le sous-système de transcodage (103). Dans certains modes de réalisation les serveurs de transcodage pourront être configurés pour l’encodage en temps-réel de différents types de contenu (par exemple différents types de contenus vidéo) à des points de transcodage correspondants le long d’une chaine de transcodage. Dans certains modes de réalisation, le sous-système de mise en forme (104) pourra être configuré pour mettre en forme les flux encodés (flux élémentaires) délivrés par le sous-système de transcodage (103) en découpant ces flux en deux séquences de segments successifs, respectivement audio et vidéo. Dans certains modes de réalisation, les segments peuvent être de durée fixe, et leur format dépendre du protocole de transport de données multimédia choisi (par exemple MPEG2-TS, MP4, etc.). Dans certains modes de réalisation, le sous-système de mise en forme pourra en outre être configuré pour générer un ensemble de métadonnées relatives à des contenus multimédias portés par les flux encodés (flux élémentaires) reçus du sous-système de transcodage (103). Dans les modes de réalisation utilisant le protocole de distribution au fil de l’eau (« streaming ») MPEG-DASH, ces métadonnées seront générées dans un fichier appelé manifeste (en anglais « manifest ») ou fichier MPD (de l’anglais « Media Presentation Description »), par exemple au format XML, indiquant les caractéristiques de chaque profil et les segments disponibles correspondant à chaque contenu multimédia. Dans les modes de réalisation utilisant le protocole de distribution au fil de l’eau (« streaming ») HLS, ces métadonnées seront générées dans un fichier appelé liste de lecteur (en anglais « playlist »), indiquant de même les caractéristiques de chaque profil et les segments disponibles correspondant à chaque contenu multimédia. Le sous-système de mise en forme (104) sera ainsi typiquement configuré pour mettre en forme les flux élémentaires reçus en générant des séquences de segments et des métadonnées destinées à permettre à un lecteur multimédia ayant reçu, par exemple suite à une ou plusieurs requêtes de contenu, un ou plusieurs segments, de reconstituer les flux élémentaires afin de les décoder à partir des segments reçus. Le sous-système de mise en forme (104) pourra ainsi typiquement être configuré pour générer des fichiers dans un format correspondant aux protocoles de transport de contenus multimédia utilisés pour transmettre les contenus au lecteur vidéo de manière à ce que le lecteur vidéo puisse les lire. Dans un système de distribution OTT, les contenus générés par le sous-système de mise en forme (104) pourront être générés dans un format permettant leur distribution à des lecteurs vidéo selon des schémas de distribution OTT, tels que le protocole HLS, le protocole MSS, le protocole HDS et le protocole MPEG DASH. Les communications de données entre le sous-système de transcodage (103) et le sous-système de mise en forme (104) peuvent dans certains modes de réalisation utiliser des schémas de transport de données de flux multimédia, comme par exemple les schémas de transmission de données selon les protocoles MPEG-TS ou DASH-IF Live Media Ingest Protocol. Une description détaillée du protocole DASH-IF Live Media Ingest est accessible à l’URL https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.html. Les communications de données entre le sous-système de sous-système de mise en forme (104) et le réseau (105) peuvent dans certains modes de réalisation utiliser des schémas de communication de données à faible latence, comme par exemple les schémas de communications de données de type CMAF, DASH, ou LL HLS (de l’anglais « Low Latency HTTP Live Streaming »). Ainsi, le réseau (105) pourra dans certains modes de réalisation être configuré pour recevoir des données en sortie du sous-système de mise en forme (104) selon le format spécifié pour le schéma CMAF ou LL HLS. La illustre un exemple non limitatif de mise en œuvre (10) d’un procédé proposé par la présente divulgation selon un ou plusieurs modes de réalisation. Le procédé de la décrit des opérations effectuées par une unité de gestion de flux multimédia pour obtenir un flux multimédia qui comprend un message de signalisation qui peut être utilisé pour déterminer une mesure de latence relative à une image du flux multimédia (appelée « image courante ») lors de sa distribution par une chaine de distribution multimédia. On désigne ainsi dans la présente divulgation par « image courante » une image d’une séquence d’images d’un flux multimédia distribué par une chaine de distribution vers un ou plusieurs dispositifs de lecture, pour laquelle on effectue une mesure de latence selon un mode de réalisation d’un procédé proposé par la présente divulgation. Dans un ou plusieurs modes de réalisation, la mesure de latence pour l’image courante peut être déterminée sur la base de mesures de temps de détection de passage du message de signalisation respectivement en deux points de mesure choisis sur la chaine de distribution. Dans un ou plusieurs modes de réalisation, le message de signalisation utilisé pour effectuer la mesure de latence comprend des données de traçabilité du message qui permettent de déterminer la progression du message de signalisation entre les deux points de mesure en détectant le passage du message à chaque point de mesure. En référence à la , on considère un flux multimédia (par exemple vidéo) comprenant une séquence d’images parmi lesquelles se trouve une image dite « image courante ». Le flux multimédia peut par exemple être un flux en entrée d’un compresseur vidéo, d’un encodeur ou d’un codec vidéo, ou en sortie d’un compresseur vidéo, d’un encodeur ou d’un codec vidéo. Dans un ou plusieurs modes de réalisation, des données de traçabilité de message de signalisation sont générées (11). Ces données de traçabilité sont avantageusement utilisables pour suivre la progression du message de signalisation dans la chaine de distribution, en détectant ce message de signalisation à plusieurs points de la chaine de distribution. En fonction du mode de réalisation, ces données de traçabilité peuvent comprendre des données d’identification du message (comme par exemple un identifiant de message), ou plus généralement toute donnée utilisable pour détecter le message de signalisation en différents points de la chaine de distribution. Dans un ou plusieurs modes de réalisation, lorsque les données de traçabilité de message de signalisation ont été générées, elles sont insérées (12), au sein d’un message de signalisation qui est obtenu par l’unité de gestion de flux multimédia. Dans un ou plusieurs modes de réalisation, l’insertion des données de traçabilité au sein du message de signalisation permet avantageusement la détection du passage du message de signalisation en différents points de la chaine de distribution. Dans un ou plusieurs modes de réalisation, on utilise une correspondance entre le message de signalisation et l’image courante pour effectuer la mesure de latence relative à l’image courante. Cette correspondance permet de suivre la progression de l’image courante le long de la chaine de distribution par le biais du suivi le long de la chaine du message de signalisation grâce aux données de traçabilité de message qui ont été insérées dans le message de signalisation. En fonction du mode de réalisation, cette correspondance peut prendre la forme d’une information de correspondance portée par le message de signalisation, ou être implicitement déterminée à partir du message de signalisation. Dans un ou plusieurs modes de réalisation, le lien de correspondance existant entre le message de signalisation et l’image courante dans le flux multimédia peut évoluer au cours de la distribution du message et de l’image dans la chaine de distribution. Différents modes de réalisation du procédé proposé de mesure de latence utilisent avantageusement le fait que cette correspondance se maintient en différents points de la chaine de distribution quand bien même elle peut prendre différentes formes et être déterminée de différentes manières selon le point de la chaine considéré. Par exemple, dans un ou plusieurs modes de réalisation, lorsqu’il est inséré dans le flux multimédia en cours de traitement à certains points de la chaine de distribution (typiquement les points situés en amont d’une unité de mise en forme), le message de signalisation peut comprendre une information de référence à l’image courante du flux multimédia. La correspondance entre le message de signalisation et l’image courante peut ainsi être déterminée sur la base de l’information de référence. Dans un ou plusieurs modes de réalisation, le message de signalisation peut comprendre des données de référence à l’image courante. Par exemple, en fonction du mode de réalisation, le message de signalisation pourra comprendre l’un au moins parmi des données de pointage sur l’image courante (comme par exemple un pointeur sur l’image ou un marqueur qui référence directement ou indirectement l’image), des données d’identification de l’image courante, et/ou toute donnée portée par le message de signalisation utilisable pour déterminer la correspondance entre le message de signalisation et l’image courante. Dans un ou plusieurs modes de réalisation, des données de pointage sur l’image courante comprennent des données relatives à un évènement associé à l’image courante, comme par exemple une fin de programme et/ou un début de publicité. Dans ces modes de réalisation, le message de signalisation peut comprendre une information d’horodatage correspondant à un temps d’occurrence de l’évènement Par exemple, dans un ou plusieurs modes de réalisation, le message de signalisation peut comprendre une information de position temporelle dans la séquence d’images de l’image courante. En fonction du mode de réalisation, l’information de position temporelle peut être par exemple portée par un ou plusieurs parmi des données d’horodatage de l’image courante, des données de temps de présentation de l’image courante, et des données de position de l’image courante dans la séquence d’images (comme par exemple un numéro de séquence). Le message de signalisation comprenant les données de traçabilité peut ensuite être inséré (13) dans le flux multimédia afin d’obtenir un flux multimédia comprenant un message de signalisation dont on peut suivre la progression dans la chaine de distribution qui distribue le flux multimédia et pour lequel une correspondance avec l’image courante existe, éventuellement de différents types (implicite ou explicite) et sous différentes formes selon le point de la chaine de distribution considéré. Ce message de signalisation peut être avantageusement utilisé pour déterminer une mesure de latence dans la chaine de distribution pour cette image courante selon un mode de réalisation d’un procédé proposé de mesure de latence. Dans un ou plusieurs modes de réalisation, le message de signalisation peut être obtenu par l’unité de gestion de flux multimédia en générant ce message, selon tout format convenant pour l’insertion dans le flux multimédia et le transport du message de signalisation généré dans la chaine de distribution par le biais du flux multimédia comprenant le message de signalisation. Dans un ou plusieurs modes de réalisation, les données de traçabilité peuvent être insérées dans le message de signalisation lors de la génération de ce message. Ainsi, dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia peut être configurée pour générer des données de traçabilité de message de signalisation et générer un message de signalisation dans lequel les données de traçabilité auront été insérées. Dans d’autres modes de réalisation correspondant à des cas de figure dans lesquels l’unité de gestion de flux multimédia opère sur un flux multimédia qui comprend déjà au moins un message de signalisation qui correspond à une image du flux, le message de signalisation peut être obtenu par l’unité de gestion de flux multimédia par extraction du flux multimédia. Dans un ou plusieurs modes de réalisation le message de signalisation peut correspondre à une image du flux en ce qu’il comprend par exemple une information de position temporelle dans la séquence d’images de l’image. Dans un ou plusieurs modes de réalisation, une fois extrait du flux multimédia, le message de signalisation peut être modifié en y insérant les données de traçabilité de message de signalisation. Ainsi, dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia peut être configurée pour générer des données de traçabilité de message de signalisation, extraire un message de signalisation du flux multimédia sur lequel l’unité opère, et insérer les données de traçabilité dans le message de signalisation extrait du flux multimédia. Dans un ou plusieurs modes de réalisation, le message de signalisation est déjà compris dans le flux multimédia traité par l’unité de gestion de flux multimédia, et le procédé proposé peut comprendre en outre : extraire du flux multimédia le message de signalisation. Dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia peut être configurée pour déterminer qu’un message de signalisation compris dans le flux multimédia sur lequel l’unité opère correspond à une image du flux et comprend déjà des données qui peuvent être utilisées pour tracer ce message de signalisation en plusieurs points de la chaine de distribution au cours de son transport dans la chaine de distribution. Dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia peut être configurée pour déterminer qu’un message de signalisation compris dans le flux multimédia sur lequel l’unité opère correspond à une image du flux. Dans certains modes de réalisation, l’unité de gestion de flux peut être configurée pour, sans traitement du message de signalisation extrait pour déterminer s’il comprend ou non des données qui peuvent être utilisées pour tracer ce message de signalisation en plusieurs points de la chaine de distribution au cours de son transport dans la chaine de distribution, insérer dans ce message des données de traçabilité qui auront été obtenues (par exemple générées) au préalable. Dans un ou plusieurs modes de réalisation, les données de traçabilité de message peuvent être insérées dans un champ du message de signalisation, par exemple un champ disponible pour y insérer des informations propriétaires. Dans un ou plusieurs modes de réalisation, les données de traçabilité de message de signalisation comprennent des données d’identification utilisables pour identifier le message de signalisation. Par exemple, les données de traçabilité de message de signalisation comprennent un identifiant du message de signalisation, ou identifiant d’une image du flux multimédia utilisable pour identifier le message de signalisation. Dans un ou plusieurs modes de réalisation, les données de traçabilité de message de signalisation peuvent être insérées ou déjà être comprises dans un message de signalisation de tout type et de tout format convenant pour le transport, au sein des différents éléments de la chaine de distribution, du message de signalisation en lien avec la distribution du flux multimédia dans la chaine de distribution. En fonction du mode de réalisation, le message de signalisation peut ainsi être modifié ou généré en y insérant les données de traçabilité de message afin de pouvoir suivre la progression du message de signalisation dans la chaine de distribution au sein du flux multimédia distribué dans la chaine de distribution. Par exemple, dans un ou plusieurs modes de réalisation, le message de signalisation peut être un message du type SCTE (de l’anglais « Society of Cable Telecommunications Engineers »)-35, c’est-à-dire conforme aux spécifications du standard SCTE-35, décrit dans le document "Digital Program Insertion Cueing Message for Cable", dans une version passée (comme par exemple la version « r1 » datant de 2019), actuelle (version « 2022a » datant de mars 2022), ou à venir. Le standard SCTE 35 définit des mécanismes de signalisation relative à un flux multimédia pour signaler des évènements diffusés, tels que des programmes, des chapitres, des pauses ou des publicités dans des trames. Il définit notamment différents types de message (appelés « commandes »), dont les types de commandes suivants : « splice_null », « splice_schedule », « splice_insert », « time_signal », « bandwidth_reservation », et « private_command ». Les évènements diffusés tels que programmes, chapitres, pauses ou publicités dans les trames sont définis dans les commandes de type « time_signal » à l’aide d’un ou plusieurs « segmentation_descriptor » , . Selon les cas de figure, une fois insérés dans un flux multimédia en amont d’une unité de mise en forme, les messages de signalisation SCTE-35 peuvent être transportées dans le flux multimédia en étant insérés par l’unité de mise en forme dans une liste de lecture selon le format HLS (en anglais, « media playlist HLS ») ou dans un ensemble de données appelé manifeste DASH tels que définis dans les standards HLS et DASH, respectivement. Si les messages de signalisation SCTE-35 ne sont pas différents selon qu’ils sont insérés dans un manifeste DASH ou une liste de lecture HLS, la manière de les insérer diffère selon qu’ils sont insérés dans une liste de lecture HLS ou un manifeste DASH : basé XML pour le DASH, et sous forme de tag pour le HLS. En sortie de l’unité de mise en forme, les données de signalisation (comme par exemple les messages de signalisation SCTE-35) peuvent également (outre leur présence dans une liste de lecture ou dans un manifeste) être présentes dans les segments ou fragments, par exemple en étant transportées dans des messages de signalisation d’évènements appelés « box emsg » pour le format mp4 ou dans le flux de transport MPEG-TS pour le format de flux HLS TS. Les données de signalisation SCTE-35 permettent entre autres l’insertion dynamique de publicités dans un flux multimédia distribué (par exemple en « live »), en utilisant des données (dans des messages qui sont parfois appelées « marqueurs ») qui transportent des métadonnées. Dans la présente description, les termes « message », « marqueur » de signalisation et « marqueur » sont utilisés de manière interchangeable pour désigner tout ensemble de données de signalisation, comme par exemple tout ensemble de données de signalisation de type SCTE-35. Différents modes d’insertion des marqueurs SCTE-35 portant des données de signalisation sont définis selon le schéma de distribution de flux multimédia utilisé. Par exemple, le mode d’insertion d’un marqueur SCTE-35 portant des données de signalisation pourra varier selon que le schéma de distribution de flux multimédia utilisé est un schéma DASH (ou MPEG-DASH) ou un schéma HLS. Par exemple, un marqueur SCTE-35 pourra être inséré dans le flux sous forme de d’étiquettes (en anglais « tags ») spécifiques pour le schéma HLS (par exemple l’étiquette « #EXT-X-DATERANGE »). Autre exemple, un marqueur SCTE-35 pourra être inséré dans le flux en utilisant des étiquettes au format XML et encodé en base64 pour le schéma DASH, comme décrit dans le document DASH-IF IOP-5 V5.0.0 (2021-11) « DASH-IF Interoperability Points ; Part 5 : Ad Insertion in DASH », disponible à l’URL « https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part5-v5.0.0.pdf », et comme illustré en particulier par l’exemple de la Table 3 page 24 de ce document. Autre exemple, un marqueur SCTE-35 pourra être inséré dans le flux sous forme de « box emsg » dans les media segments, comme décrit par exemple dans la spécification DASH, par exemple à la section G.9 de la version DASH – ISO/IEC 230009-1 2022 ed. 5. Ainsi, par exemple, dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia pourra utiliser un marqueur de type SCTE-35 préexistant d’insertion de publicité dans le flux multimédia distribué, et insérer dans ce marqueur des données de traçabilité de marqueur, éventuellement seulement après avoir déterminé que le marqueur d’insertion de publicité ne contient pas déjà des données utilisables pour tracer le marqueur en différents points de la chaine de distribution. Un tel marqueur d’insertion de publicité pourra alors avantageusement être utilisé pour déterminer une mesure de latence relative à une image du flux à laquelle il correspond (par exemple une image située dans le flux après ou avant le début d’insertion de publicité). L’utilisation d’un marqueur de type SCTE-35 est avantageuse en ce que ces marqueurs sont facilement détectables parmi les données relatives à un flux multimédia auquel un ou plusieurs traitements (encodage, mise en forme, stockage, etc.) sont appliqués en vue de sa distribution, selon un ou plusieurs formats, à un ou plusieurs terminaux. En outre, les données portées par un marqueur de type SCTE-35 ne varient pas au cours de leur distribution dans la chaine de distribution en lien avec la distribution du flux multimédia dans la chaine de distribution, contrairement aux données de sous-titrage qui peuvent varier du format Teletext au format TTML par exemple, ou aux données vidéo qui peuvent être transcodées par un élément de la chaine de distribution, pour passer du format H.264 au format H.265 par exemple. Un marqueur de type SCTE-35 peut ainsi être facilement détecté en différents points d’une chaine de distribution lors de sa distribution dans la chaine en lien avec un flux multimédia. Le procédé proposé tire avantage de cette facilité de détection pour tracer une image du flux et suivre cette image au cours de sa distribution, multimédia par l’intermédiaire d’un message de signalisation correspondant à cette image (comme par exemple un marqueur SCTE-35), qui est tracé en utilisant les données de traçabilité qu’il contient, de manière à effectuer une ou plusieurs mesures de latence en utilisant le marqueur (et donc l’image qui lui correspond) en un ou plusieurs points de la chaine de distribution. Dans ce qui suit, des exemples de modes de réalisation de la présente divulgation dans lesquels des marqueurs de type SCTE-35 sont insérés dans un flux multimédia en amont d’une unité de mise en forme d’une chaine de distribution avant d’être inséré par l’unité de mise en forme dans une liste de lecture (par exemple de type spécifié dans le standard HLS) ou dans un fichier manifeste (par exemple de type spécifié dans le standard DASH), sont décrits. L’homme du métier comprendra que l’utilisation de marqueurs de type SCTE-35 n’est qu’un exemple non limitatif, et que d’autres messages de signalisation, type de messages de signalisation, pourraient être utilisés dans d’autres modes de réalisation. De plus, l’utilisation de signalisation de type SCTE-35 insérée dans des listes de lecture ou des manifestes n’est qu’un exemple non limitatif, et d’autres modes de réalisation pourraient utiliser des messages de signalisation de type SCTE-35 insérés dans des unités de données multimédia, comme par exemple des fragments, des segments et/ou des chunks de données multimédia. De même, d’autres architectures de réseau ou de chaine de distribution pourraient être utilisées dans d’autres modes de réalisation de la présente divulgation. Les marqueurs de type SCTE-35 sont un exemple de marqueurs qui peuvent être utilisés pour transporter des informations particulières, telles que des informations relatives à une image d’un flux multimédia (par exemple par le biais d’un évènement d’occurrence en lien avec la position d’une image dans le flux) et des données de traçabilité, de sorte qu’ils peuvent avantageusement fournir un vecteur de transport de ces informations. La mise en œuvre du procédé proposé peut ainsi être avantageusement réalisée sans aucune modification de la spécification SCTE-35, tout en tirant parti des traitements des marqueurs SCTE-35 tels que spécifiés dans cette spécification. Les données de signalisation SCTE-35 peuvent être insérées dans des flux multimédia, comme illustré par la qui montre un exemple de flux multimédia (20) comprenant des données vidéo (images (ou trames vidéo)) (« V ») (21a, 21b, 21c, 21d, 21e, 21f, 21g), des données audio (« A ») (22a, 22b), et des données de signalisation SCTE-35 (« SCTE-35 ») (23). Le flux multimédia (20) comprend une succession de paquets de données, chacun comprenant des données vidéo, des données audio et/ou des données de signalisation (qui peuvent être considérées comme des métadonnées des données vidéo et/ou audio). En fonction du mode de réalisation, l’exemple de flux multimédia (20) à traiter illustré par la peut être par exemple au format MPEG2-TS ou au format MPEG-DASH. Comme indiqué sur la , le flux multimédia peut comprendre des métadonnées comprenant, pour chaque élément vidéo (image « V ») et chaque élément audio (données audio « A »), un paramètre de temps de présentation (par exemple noté PTS, de l’anglais « Presentation Time Stamp ») par rapport à une horloge de référence et une durée d’affichage. Dans certains modes de réalisation, le temps de présentation de l’image (PTS) pourra être déterminé à partir d’une horloge de référence du flux (paramètre PCR) lors du démultiplexage. Par exemple, l’image (21f) est associée au temps de présentation PTS « 250 », tandis que l’image (21g) est associée au temps de présentation PTS « 260 », ce qui indique (par exemple à un lecteur multimédia) que l’image (21g) est à afficher 10 unités de temps après l’image (21f). Le flux multimédia (20) de la comprend en outre des données de signalisation SCTE-35 (marqueur de type SCTE-35 (23)), insérées dans l’exemple illustré entre deux images (21b et 21c). Dans l’exemple illustré, le marqueur de type SCTE-35 (23) est un marqueur de démarrage de publicité qui pointe vers l’image du flux (21f) associée au temps de présentation PTS « 250 » par l’intermédiaire d’un paramètre « ad_pts_time » auquel est associé la valeur de temps de présentation PTS « 252 ». Le paramètre « ad_pts_time » permet d’indiquer une information d’horodatage, sous la forme d’un point temporel exprimé en termes de temps de présentation (PTS), qui correspond à l’image (21f) de PTS correspondant. La signalisation du marqueur de type SCTE-35 (23) est positionnée dans le flux avant l’image (21f) du flux à laquelle elle se rapporte pour indiquer aux éléments de la chaine de distribution que l’image correspondante (21f) est liée à une action ou un évènement signalé par le marqueur de type SCTE-35 (23). Ainsi, il peut être déterminé que le marqueur de type SCTE-35 correspond à l’image (21f) par l’intermédiaire du paramètre « ad_pts_time » qui désigne un temps PTS « 252 » qui correspond à celui de l’image (21f). Cette correspondance permet en outre de déterminer un écart temporel entre le marqueur de type SCTE-35 (23) et l’image correspondante (21f). La montre un exemple de distribution d’un flux multimédia dans un système de distribution de flux multimédia OTT tel que, par exemple, le sous-système 101 de distribution de contenus multimédia (par exemple vidéo) illustré par la . La illustre par un exemple les mécanismes de traitement de données de signalisation de type SCTE-35 lors de la distribution d’un flux multimédia dans un système de distribution de données multimédia. Le système de distribution de données multimédia illustré par la comprend une chaine de distribution de flux multimédia depuis une source (103a) en passant par un encodeur multimédia (103), une unité de mise en forme (104), et un réseau de distribution (105) de contenus multimédias, pour distribuer des données multimédia vers un ou plusieurs terminaux (102). Les équipements (103a), (103), (104), (105) et (102) peuvent par exemple correspondre à ceux de la et décrits en lien avec cette figure. On retrouve aussi sur la le flux multimédia (20) de la et décrit en lien avec cette figure. Le flux multimédia peut par exemple être généré par une source de données multimédia (103a), mise en œuvre par exemple par une unité de tête de réseau (en anglais, « headend »). Ce flux multimédia comprend un marqueur (23), dans l’exemple illustré de type SCTE-35, ainsi que des paquets de données portant des données vidéo et/ou audio, comme décrit en lien avec la . Comme illustré sur la , le flux multimédia (20) peut, dans le cadre de sa mise à disposition pour distribution vers des terminaux (102), être fourni en entrée d’un encodeur multimédia (103) configuré pour générer, à partir de ces données d’entrée, un flux multimédia encodé (20a). Le temps de traitement au sein de l’encodeur multimédia induit une latence qui conduit à modifier le temps de présentation (PTS) pour ajouter, pour chaque élément du flux d’entrée (20) associé à un temps de présentation, au temps de présentation initial du flux d’entrée (20) un temps de traitement, par exemple égal à 20 unités de temps, comme illustré sur la . Le marqueur (23) est aussi modifié pour tenir compte de la modification du temps de présentation de l’image (21f) sur laquelle il pointe (de « PTS 250 » à « PTS 450 ») : le paramètre « ad_pts_time », initialement configuré à la valeur « 252 », est modifié pour avoir la valeur « 452 » dans le flux (20a) en sortie de l’encodeur vidéo (104). Comme illustré sur la , le flux encodé (20a) peut, dans un ou plusieurs modes de réalisation, être fourni en entrée d’une unité de mise en forme (105), telle que celle décrite en lien avec la . Dans un ou plusieurs modes de réalisation, l’unité de mise en forme (105) peut être configurée pour générer, à partir des données du flux encodé (20b), un ou plusieurs segments vidéo (dans l’exemple illustré, le « segment N » et le « segment N+1 »), ainsi que un ou plusieurs fichiers de métadonnées décrivant les contenus des flux reçus (dans l’exemple illustré, le fichier (24a) qui peut par exemple être un fichier manifeste (par exemple au format XML), par exemple de type DASH ou être un fichier liste de lecture, par exemple de type HLS. Dans un ou plusieurs modes de réalisation, l’unité de mise en forme (105) peut être configuré pour détecter le marqueur (23) dans le flux encodé (20b), et insérer les métadonnées du marqueur (23) dans un fichier de métadonnées (24a) généré pour décrire les contenus du flux encodé (20b). L’insertion du marqueur (23) dans un fichier de métadonnées (24a) pourra se conformer aux règles de format du fichier de métadonnées (24a), de sorte que par exemple, cette insertion pourra être différente lorsque le marqueur (23) est inséré dans un manifeste DASH et lorsque le marqueur (23) est inséré dans une liste de lecture HLS. Dans les modes de réalisation dans lesquels le marqueur de type SCTE-35 est intégré par l’unité de mise en forme (104) à une liste de lecture de type HLS, la correspondance entre les données du marqueur inséré dans la liste de lecture et l’image (21f_b) est implicite : dans ce cas, cette image (21_f) est la première image du premier segment qui suit dans la liste de lecture le marqueur (sur la figure, le « segment N+1 »). Une unité de gestion de flux qui opère un traitement de la liste de lecture pour y détecter le marqueur peut ainsi savoir que l’image à laquelle le marqueur se rapporte est la première image du segment listé immédiatement après le marqueur dans la liste de lecture. Il peut être par ailleurs considéré dans ce cas de figure que l’écart temporel entre la détection du marqueur dans la liste et l’image correspondant au marqueur est nul ou quasiment nul. Ces segments vidéo (« segment N » et « segment N+1 ») et un ou plusieurs fichiers de métadonnées (24a) sont ensuite fournis à un nœud de réseau de distribution de contenu (105) (par exemple un serveur de données) configuré pour les stocker afin de les distribuer sur requête à un ou plusieurs terminaux (102). La spécification (et les normes correspondantes) SCTE-35 2022b définit des mécanismes permettant de raccorder des flux multimédia encodés qui utilisent un évènement de raccordement (en anglais « splice event ») pour indiquer une opportunité de raccorder un ou plusieurs flux. Des identifiants d’évènement de raccordement (« splice_event_id ») sont aussi définis afin d’identifier de manière unique un évènement de raccordement. La spécification SCTE-35 2022b définit en outre des messages de signalisation permettant de signaler à chaque équipement traitant le flux multimédia un évènement de signalisation. Par exemple, les messages de commande du type « time_signal » peuvent être utilisés pour signaler un évènement de raccordement. On pourra se référer pour plus de détails à la spécification SCTE-35 2022b, en particulier à la Section 9 de cette spécification. La section 10 de la spécification SCTE-35 2022b définit des paramètres « splice_info_section » des messages de type « time_signal » qui comprennent des descripteurs de raccordement (en anglais, « splice descriptors »), parmi lesquels les descripteurs de raccordement spécifiques « avail_descriptor() », « DTMF_descriptor() », « segmentation_descriptor() », « time_descriptor() », et « audio_descriptor() ». En particulier, la syntaxe définie pour le descripteur de segmentation « segmentation_descriptor() » prévoit entre autres les champs de données suivants : « segmentation_upid_type », « segmentation_upid_length », « segmentation_upid() » et «segmentation_type_id ». On pourra se référer pour plus de détails concernant les descripteurs de raccordement à la spécification SCTE-35 2022b, en particulier à la Section 10 de cette spécification. Dans un ou plusieurs modes de réalisation, les données de traçabilité de message de signalisation peuvent être portées par un marqueur de signalisation, par exemple de type SCTE-35, par exemple de type « time_signal » (tel que spécifié à la section 9.7.4 de la spécification SCTE-35 2022b), comme illustré par les Figs. 3a et 3b, associé à un paramètre « splice_descriptor() », correspondant à une image du flux multimédia (comme par exemple par le biais de données de temps de présentation de l’image portées par le marqueur). Tel que défini par la spécification SCTE-35 2022b, le paramètre « time_signal() » permet d’associer une information de synchronisation (par exemple de type « pts_time ») avec un descripteur de type « splice_info_section ». Le schéma XML du paramètre « splice_signal() » est décrit à la Figure 9 de la spécification SCTE-35 2022b. Le message de signalisation de type SCTE-35 peut être de type spécifié sous l’appellation « splice_info_section », et contenir une commande, qui peut par exemple être de type « time_signal ». La commande de type « time_signal » peut typiquement être utilisée pour porter une information d’horodatage. Ainsi, un message de signalisation SCTE-35 peut être configuré pour signaler un évènement d’occurrence unique dans le temps, et contenir une commande de type « time_signal » pour indiquer entre autres un horodatage de l’évènement. Par exemple, un évènement signalé au moyen d’un message SCTE-35 peut être la fin d’un programme et le début d’une publicité. Un ou plusieurs descripteurs peuvent être portés par la commande « time_signal » pour décrire un horodatage de ce type d’évènement. Par exemple, un ou plusieurs descripteurs peuvent être utilisés pour décrire (respectivement, dans le cas de plusieurs descripteurs) un point temporel de fin du programme courant et/ou un point temporel de début de publicité. Ainsi, dans un ou plusieurs modes de réalisation, une commande de type « time_signal » dans un marqueur de type SCTE-35, associée à un ou plusieurs descripteurs, par exemple de type « segmentation_descriptor », l’un au moins de ces descripteurs étant configuré avec une information d’horodatage d’une image du flux multimédia, peut être utilisée comme message de signalisation. Le type de commande « time_signal » tel que décrit dans la spécification SCTE-35 2022b est particulièrement bien adapté pour une utilisation dans un mode de réalisation d’un procédé proposé dans la présente divulgation. En effet, les commandes du type « time_signal » tels que spécifiées portent une information d’horodatage, qui permet d’identifier une image, que l’on peut choisir comme image courante pour effectuer une mesure de latence. En outre, les commandes du type « time_signal » tels que spécifiées sont associées à une liste de descripteurs génériques de type « splice_descriptor ». Si les descripteurs typiquement utilisés en lien avec une commande de type « time_signal » sont des descripteurs de type « segmentation_descriptor » pour signaler par exemple des chapitres, des programmes (débuts et fins respectives de programmes), de pauses, etc., chaque descripteur de type « segmentation_descriptor » contient un champ appelé « segmentation_upid() » qui peut être utilisé pour transporter des informations supplémentaires, telles que par exemple des informations utiles à une mesure de latence. De plus, les commandes de type « time_signal » sont largement utilisées dans les systèmes déployés pour signaler de la publicité à insérer dans un flux multimédia, de sorte que les éléments des chaines de distribution déployés sont en général configurés pour les faire transiter le long de la chaine. Ainsi, les procédés proposés dans la présente divulgation se prêtent particulièrement bien à des mises en œuvre utilisant des messages de signalisation de type SCTE-35 comprenant des commandes de type « time_signal ». Dans un ou plusieurs modes de réalisation, le message de signalisation est de type SCTE-35. Les messages de signalisation de type SCTE-35 peuvent être dans certains modes de réalisation avantageusement utilisés car, à l’instar des messages de signalisation de type SCTE-35 utilisés pour signaler des insertions de publicités, des messages de signalisation de type SCTE-35 transportant des données utiles à une mesure de latence relative à un flux multimédia distribué par une chaine de distribution, ne seront typiquement pas filtrés par un élément de la chaine de distribution. Dans un ou plusieurs modes de réalisation dans lequel le message de signalisation est de type SCTE-35, un descripteur de segmentation SCTE-35 (de type « segmentation_descriptor ») tel que spécifié peut être utilisé pour insérer dans le message des données utiles à la mesure de latence, comme par exemple des données de traçabilité du message. En variante, un descripteur existant peut être avantageusement réutilisé en y ajoutant des données utiles à la mesure de latence, comme par exemple des données de traçabilité du message, dans le champ de type « segmentation_upid ». Dans un ou plusieurs modes de réalisation, un descripteur de segmentation SCTE-35 (« segmentation_descriptor ») peut être utilisé pour transporter des données utiles à une mesure de latence relative à une image d’un flux multimédia distribué par une chaine de distribution multimédia, comme par exemple des données de traçabilité du message de signalisation SCTE-35. Par exemple, les données du descripteur de segmentation SCTE-35 peuvent comprendre les champs de données suivants : Un champ « segmentation_upid_type » avec une des valeurs sur 8 bits définie à la Table 22 de la spécification SCTE-35 2022b. Dans un ou plusieurs modes de réalisation, la valeur hexadécimale 0x01 pourra être avantageusement être utilisée pour indiquer que le champ « segmentation_upid_type » est utilisé pour porter des données utilisateur. Un champ « segmentation_upid() », dont le type et la taille (en octets) sont spécifiés par le biais du champ « segmentation_upid_type ». Par exemple, pour un champ « segmentation_upid_type » ayant la valeur 0x01, le type est « User Defined », et la taille en octets est variable. Dans un ou plusieurs modes de réalisation, le champ segmentation_upid() peut avantageusement porter des données de traçabilité d’une image du flux multimédia comprenant un identifiant (par exemple sous la forme d’un identifiant unique universel « UUID » (de l’anglais « Universally Unique Identifier ») indiqué par un champ « segmentation_upid_type » de valeur « 0x10 ») et une information d’horodatage (« timecode ») Un champ « segmentation_type_id » avec une des valeurs sur 8 bits définie à la Table 23 de la spécification SCTE-35 2022b. En fonction du mode de réalisation, la valeur hexadécimale 0x01 pourra être avantageusement être utilisée pour indiquer que le descripteur (message) de segmentation décrit un identifiant de contenu « Content Identification », ou la valeur hexadécimale 0x22 pourra être avantageusement être utilisée pour indiquer que le descripteur (message) de segmentation décrit un début de d’interruption (signalant par exemple un début de publicité) « Break Start ». Les données de traçabilité de message de signalisation peuvent ainsi être portées, dans un ou plusieurs modes de réalisation, par un marqueur de type SCTE-35 2022b qui correspond à une image du flux, par exemple de type « segmentation_upid() ». Avantageusement, ces marqueurs peuvent être capturés à différents points d’une chaine de distribution de contenus multimédia, telle que celle illustrée par la ou par la . Dans un ou plusieurs modes de réalisation, une commande SCTE-35 de type « private_command() » ou « splice_insert() » peut être utilisée pour transporter des données utiles à une mesure de latence relative à une image d’un flux multimédia distribué par une chaine de distribution multimédia, comme par exemple des données de traçabilité du message de signalisation SCTE-35. L’utilisation d’une commande de type « splice_insert() » présente l’avantage d’être largement utilisée dans les systèmes de distribution multimédia actuellement déployés. Cependant, à la différence des commandes de type SCTE-35, dans l’état actuel de la spécification SCTE-35, une commande de type « splice_insert() » ne comporte pas de champ dans lequel des données pour un usage spécifique peuvent être insérées. Une commande de type « private_command() » peut dans certains systèmes ne pas être transmise par certains équipements. La illustre un exemple non limitatif de mise en œuvre (1000) d’un procédé proposé de mesure de latence d’une image d’un flux multimédia selon un ou plusieurs modes de réalisation. On considère à nouveau un flux multimédia distribué par une chaîne de distribution multimédia dans un système de distribution multimédia, le flux multimédia comprenant une séquence d’images. Le procédé proposé de mesure de latence peut par exemple être mis en œuvre par une unité de traitement d’un système de distribution multimédia. On définit par ailleurs deux points de la chaine de distribution que l’on souhaite utiliser pour effectuer une mesure de latence relative à une image du flux entre ces deux points. Dans un ou plusieurs modes de réalisation, le passage d’un message de signalisation correspondant à une image de la séquence d’images et comprenant des données de traçabilité dans la chaine de distribution multimédia, à un premier point de la chaine de distribution multimédia, est détecté. Sur détection du message au premier point, des premières données d’horodatage de détection du message de signalisation au premier point de la chaine de distribution multimédia sont générées (1001) et enregistrées. Les premières données d’horodatage permettent de relever un temps de passage en un premier point de la chaine de distribution d’un message de signalisation traçable dans la chaine de distribution et correspondant à une image du flux. Dans un ou plusieurs modes de réalisation, le passage du message de signalisation correspondant à l’image de la séquence d’images et comprenant les données de traçabilité dans la chaine de distribution multimédia, à un deuxième point de la chaine de distribution multimédia, est détecté. Sur détection du message au deuxième point, suite à la détermination que le message de signalisation comprend les données de traçabilité, des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point de la chaine de distribution multimédia sont générées (1002) et enregistrées. Une mesure de latence associée à l’image peut alors être déterminée (1003) sur la base des premières et deuxièmes données d’horodatage, par exemple en déterminant un écart temporel entre les deuxièmes données d’horodatage et les premières données d’horodatage. Dans un ou plusieurs modes de réalisation, la mesure de latence peut en outre être déterminée en tenant compte de l’un au moins parmi un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point et un temps de mise à disposition de l’image au premier point, et un deuxième écart temporel entre les deuxièmes données d’horodatage de détection du message de signalisation au deuxième point et un temps de mise à disposition de l’image au deuxième point. Ainsi, dans un ou plusieurs modes de réalisation, un ou plusieurs parmi un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point et un temps de mise à disposition de l’image au premier point, et un deuxième écart temporel entre les deuxièmes données d’horodatage de détection du message de signalisation au deuxième point et un temps de mise à disposition de l’image au deuxième point, peut être déterminé. Dans un ou plusieurs modes de réalisation, la mesure de latence peut ensuite être déterminée sur la base d’une combinaison des premières données d’horodatage, des deuxièmes données d’horodatage et des premier et deuxième écarts temporels. Dans un ou plusieurs modes de réalisation, un ou plusieurs parmi les premier et deuxième écarts temporels pourront être déterminés sur la base de temps respectifs de mise à disposition de l’image vers laquelle pointe le message de signalisation au point correspondant de mesure le long de la chaîne de distribution, de sorte que dans certains modes de réalisation, la mesure obtenue pourra être considérée comme étant une mesure de latence entre deux temps de mise à disposition d’une image d’un flux multimédia pour distribution vers des terminaux le long d’une chaîne de distribution. La illustre un exemple d’architecture de mesure de latence dans une chaîne de distribution de contenus multimédia selon un ou plusieurs modes de réalisation du procédé proposé. La montre une chaîne de distribution (110) de flux multimédias du type de celle illustrée par les et 3b, et décrite en lien avec ces figures. La chaîne de distribution (110) de flux multimédia peut typiquement comprendre un encodeur multimédia (comprenant par exemple un encodeur vidéo) (103), une unité de mise en forme (104) (en anglais, un "packager"), un ou plusieurs nœuds de réseau CDN (105), pour distribuer des flux multimédias (103a) générés par une source à un ou plusieurs équipements utilisateurs (102). Dans l’exemple d’architecture illustré par la , le procédé de traitement proposé selon le premier aspect est mis en œuvre par une unité de gestion de flux multimédia (106) placée en amont de la chaîne de distribution (101). Dans un ou plusieurs modes de réalisation, l’unité de gestion (106) est configurée pour générer des données de traçabilité de message de signalisation, pour obtenir (par exemple générer) un message de signalisation comprenant un marqueur d’une image de la séquence d’images du flux multimédia et modifier ce message de signalisation en insérant les données de traçabilité du message de signalisation dans le message de signalisation, puis insérer le message de signalisation modifié dans le flux multimédia. Dans les modes de réalisation dans lesquels le message de signalisation comprenant un marqueur d’une image de la séquence d’images est de type SCTE-35, l’unité de gestion (106) peut être configurée pour générer des données de traçabilité de message de signalisation, et modifier le message SCTE-35 en y insérant les données de traçabilité générée, puis en insérant le message SCTE-35 modifié dans le flux multimédia présenté en entrée de la chaine de distribution (110). Dans un ou plusieurs modes de réalisation applicables dans des cas de figure dans lesquels le flux multimédia reçu par l’unité de gestion comprend déjà un message (auquel il peut être fait référence par le terme « marqueur ») de signalisation comprenant un marqueur d’une image de la séquence d’images (par exemple de type SCTE-35), l’unité de gestion (106) peut être configurée pour extraire du flux multimédia ce message de signalisation, et y insérer des données de traçabilité de message de signalisation. Dans un ou plusieurs modes de réalisation applicables dans des cas de figure dans lesquels le flux multimédia reçu par l’unité de gestion ne comprend pas déjà un message de signalisation comprenant un marqueur d’une image de la séquence d’images (par exemple de type SCTE-35) dans lequel des données de traçabilité de message de signalisation avantageusement utilisables pour tracer le message de signalisation au cours de sa progression dans la chaîne de distribution (110) peuvent être insérées, l’unité de gestion (106) peut être configurée pour générer un nouveau message de signalisation comprenant un marqueur d’une image de la séquence d’images (par exemple de type SCTE-35), et y insérer des données de traçabilité de message de signalisation (comme par exemple un identifiant unique de message ou un pointeur sur une image du flux) avantageusement utilisables pour tracer le message de signalisation au cours de sa progression dans la chaîne de distribution (110). Comme illustré sur la , le flux multimédia (103b) parcourant les différents nœuds de la chaîne de distribution (110), étant placé en aval de l’unité de gestion de flux (106), contient un message de signalisation qui porte des données de traçabilité de message de signalisation. Ces données de traçabilité de message de signalisation peuvent être lues en différents points de mesure (M1, M2, M3, M4) le long de la chaine de distribution (110) suite à une détection du message de signalisation qui les porte en utilisant ces données de traçabilité de message de signalisation. Dans l’exemple illustré par la , le message de signalisation est par exemple de type SCTE-35. L’homme du métier comprendra que l’architecture illustrée par la n’est qu’un exemple non limitatif, et qu’en outre l’unité de gestion (106) pourrait dans d’autres architectures être positionnée à d’autres points de la chaine de distribution (110), notamment pour tenir compte de l’architecture de la chaine de distribution, dont les Figs. 1, 3b, et 4b ne fournissent qu’un exemple non limitatif. D’autres nœuds, types de nœuds, et architectures de réseau pourront être envisagés dans le cadre de modes de réalisation de la présente divulgation. Par exemple, l’unité de gestion (106) pourra dans certains modes de réalisation être positionnée en aval de l’encodeur (103) (par exemple entre l’encodeur et l’unité de mise en forme (104)), ou en aval de l’unité de mise en forme (104) (par exemple entre l’unité de mise en forme (104) et le réseau CDN (105)). Dans l’exemple d’architecture illustré par la , le procédé de traitement proposé selon le deuxième aspect est mis en œuvre par une unité de gestion de flux multimédia (107) configurée pour tracer des messages SCTE-35 en s’appuyant sur des données de traçabilité de message de signalisation comprises dans ces messages en différents points de la chaîne de distribution (110). L’unité de gestion (107) peut par exemple être configurée pour, sur détection, à un premier point (M1, M2 ou M3) de la chaine de distribution multimédia (110), d’un message de signalisation SCTE-35 correspondant à une image de la séquence d’images et comprenant des données de traçabilité, générer des premières données d’horodatage de détection du message de signalisation au premier point (M1, M2 ou M3) de la chaine de distribution multimédia (110), et suite à la détection, dans le flux multimédia, du message de signalisation à un deuxième point (M2, M3 ou M4) de la chaine de distribution multimédia (110) par détermination que le message de signalisation comprend les données de traçabilité, générer des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point (M2, M3 ou M4) de la chaine de distribution multimédia, puis déterminer une mesure de latence associée à l’image sur la base des premières et deuxièmes données d’horodatage. Dans un ou plusieurs modes de réalisation, l’unité (107) peut être configurée pour en outre : déterminer un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point (M1, M2 ou M3) et un temps de mise à disposition de l’image au premier point ; et déterminer un deuxième écart temporel entre les deuxièmes données d’horodatage de détection du message de signalisation au deuxième point (M2, M3 ou M4) et un temps de mise à disposition de l’image au deuxième point, la mesure de latence étant alors déterminée sur la base d’une combinaison des premières données d’horodatage, des deuxièmes données d’horodatage et des premier et deuxième écarts temporels. Comme illustré sur la , l’unité de traitement (107) peut être configurée pour détecter un message de signalisation de type SCTE-35 aux points de mesure M1, M2, M3 et/ou M4, et obtenir à partir des données portées par ce message, éventuellement dans sa version ou dans son format modifié après traitement par l’encodeur (103), l’unité de mise en forme (104), et le réseau CDN (105). Dans un ou plusieurs modes de réalisation, le message de signalisation sera détecté sous différentes formes ou formats selon le point de mesure considéré le long de la chaîne de distribution, ce dont il pourra être tenu compte pour calculer les écarts temporels entre les données d’horodatage de détection du message de signalisation en un point et les temps de mise à disposition de l’image au point correspondant. Par exemple, si le point de mesure est situé en amont de l’unité de mise en forme (104) (ce qui est le cas par exemple des points M1 et M2), le message de signalisation (dans l’exemple de la de type SCTE-35) sera intégré au flux multimédia (comme illustré sur les figures 3a et 3b). L’écart temporel entre le temps de détection du message de signalisation et le passage de l’image au point de détection pourra dans ce cas de figure par exemple être déterminé en fonction des positions respectives dans le flux multimédia du message de signalisation et de l’image vers lequel le message pointe, par exemple sur la base de données de temps de présentation portées par le message et par des métadonnées de l’image. Si le point de mesure est situé en aval de l’unité de mise en forme (104) (ce qui est le cas par exemple des points M3 et M4), le message de signalisation (dans l’exemple de la de type SCTE-35) sera intégré dans un ensemble de métadonnées (par exemple, en fonction du protocole de distribution utilisé, de type manifeste DASH ou liste de lecture HLS). L’écart temporel entre le temps de détection du message de signalisation (dans l’ensemble de métadonnées) et le passage de l’image au point de détection pourra dans ce cas de figure être considéré comme négligeable. Ainsi, en un point situé en aval de l’unité de mise en forme (104), il pourra être considéré que le message de signalisation est présenté (c’est-à-dire mis à disposition pour distribution vers un lecteur vidéo (102)) (quasiment) au même moment que l’image à laquelle il se rapporte. Dans certains modes de réalisation, cet écart temporel pourra être considéré comme étant nul. Dans un ou plusieurs modes de réalisation, l’unité de traitement (107) peut être configurée pour détecter, à un premier point de mesure dans la chaine de distribution (110), un message de signalisation (par exemple de type SCTE-35), puis extraire du message des données de traçabilité de message de signalisation, par exemple par lecture des données portées par le message. Comme illustré par les figures 3a et 3b, le marqueur de signalisation peut par exemple pointer sur une image pour en effectuer le marquage (par exemple par le biais d’un temps de présentation de l’image). Sur lecture des données de marquage de l’image, l’unité de traitement (107) peut déterminer un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point et un temps de mise à disposition de l’image au premier point , et stocker en mémoire des premières données d’horodatage de l’image (comprenant les premières données d’horodatage de détection du message de signalisation et ce premier écart temporel) pour enregistrer un premier horodatage de l’image correspondant au premier point de détection du message de signalisation. Ces opérations peuvent être répétées pour un deuxième point de mesure, de manière à déterminer un deuxième écart temporel entre des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point et un temps de mise à disposition de l’image au deuxième point , et stocker en mémoire des deuxièmes données d’horodatage de l’image (comprenant les deuxièmes données d’horodatage de détection du message de signalisation et ce deuxième écart temporel) pour enregistrer un deuxième horodatage de l’image correspondant au deuxième point de détection du message de signalisation, pour ensuite déterminer une mesure de latence correspondant aux premier et deuxième points de mesure en utilisant les premières et deuxièmes données d’horodatage de l’image (par exemple en comparant les premier et deuxième horodatages obtenus pour l’image). Dans un ou plusieurs modes de réalisation, on pourra prévoir une synchronisation temporelle d’un ou plusieurs des éléments de la chaine de distribution (110) en aval desquels on souhaite positionner un point de mesure, avec l’unité de traitement (107). Cette synchronisation temporelle pourra par exemple être effectuée en utilisant tout protocole de synchronisation réseau adapté, comme par exemple le protocole NTP (de l’anglais « Network Time Protocol « ) décrit dans la spécification de l’IETF RFC-1305 pour la version 3 (ou dans l’une des versions précédentes), ou selon le mode de réalisation le protocole PTP (de l’anglais « Precision Time Protocol ») décrit dans la spécification de l’IEEE IEEE-1588 pour la version 3 (ou dans l’une des versions précédentes). L’homme du métier comprendra que l’architecture illustrée par la n’est qu’un exemple non limitatif, et que l’unité de traitement (107) pourrait dans d’autres architectures être mise en œuvre sur un ou plusieurs dispositifs informatiques configurés pour fonctionner avec une base de synchronisation temporelle commune. Dans un ou plusieurs modes de réalisation dans lesquels le flux multimédia contient déjà un message de signalisation comprenant un marqueur d’une image du flux, le procédé proposé peut prévoir de détecter ce message de signalisation, et de déterminer des données de traçabilité, comme par exemple un identifiant, dans ce message. Par exemple, dans le cas d’un message SCTE-35, le procédé proposé peut prévoir de détecter un message SCTE-35 présent dans le flux multimédia et pointant sur une image du flux, et de déterminer dans un descripteur de ce message un identifiant susceptible d’être utilisé pour tracer ce message au cours de son transport dans la chaîne de distribution. Dans un ou plusieurs modes de réalisation dans lesquels le flux multimédia contient déjà un message de signalisation comprenant un marqueur d’une image du flux, le procédé proposé peut prévoir de détecter ce message de signalisation, et de déterminer si des données de traçabilité, comme par exemple un identifiant, sont présentes dans ce message. Par exemple, dans le cas d’un message SCTE-35, le procédé proposé peut prévoir de détecter un message SCTE-35 présent dans le flux multimédia et pointant sur une image du flux, et de déterminer si un identifiant susceptible d’être utilisé pour tracer ce message au cours de son transport dans la chaîne de distribution est présent dans un descripteur de ce message. Dans les cas de figure où il est déterminé que le message de signalisation détecté contient des données de traçabilité susceptibles d’être utilisées pour tracer ce message au cours de son transport dans la chaîne de distribution, le procédé proposé peut prévoir de stocker en mémoire ces données de traçabilité afin de les utiliser pour détecter le passage du message de signalisation en un ou plusieurs points de mesure le long de la chaîne de distribution. Dans les cas de figure où il est déterminé que le message de signalisation détecté ne contient pas de données de traçabilité susceptibles d’être utilisées pour tracer ce message au cours de son transport dans la chaîne de distribution, le procédé proposé peut prévoir de générer des données de traçabilité susceptibles d’être utilisées pour tracer ce message au cours de son transport dans la chaîne de distribution, et de les insérer dans le message de signalisation puis de réinsérer le message modifié dans le flux en ayant stocké en mémoire les données de traçabilité afin de les utiliser pour détecter le passage du message de signalisation en un ou plusieurs points de mesure le long de la chaîne de distribution. Par exemple, dans le cas d’un message de signalisation de type SCTE-35, il peut être prévu d’ajouter un identifiant dans un descripteur du message (par exemple un descripteur pré-existant du message, par exemple en remplissant un champ spécial « segmentation_upid » du descripteur) afin d’utiliser cet identifiant pour tracer les passages du message de signalisation en différents points de la chaîne de distribution. En variante, il peut être prévu d’ajouter un descripteur supplémentaire comprenant un identifiant dans le message de signalisation (par exemple un descripteur de type « content_identifier » qui contient un champ avec un identifiant), afin d’utiliser cet identifiant pour tracer les passages du message de signalisation en différents points de la chaîne de distribution. Ainsi, dans un ou plusieurs modes de réalisation, en fonction du cas de figure rencontré, il peut être prévu de générer un message de signalisation comprenant un marqueur d’une image de la séquence d’images et comprenant des données de traçabilité de message de signalisation, de modifier un message de signalisation comprenant un marqueur d’une image de la séquence d’images en insérant dans un champ existant des données de traçabilité de message de signalisation (par exemple un identifiant), ou de modifier un message de signalisation comprenant un marqueur d’une image de la séquence d’images en y insérant un nouveau champ comprenant des données de traçabilité de message de signalisation (par exemple un identifiant). Par exemple, dans un ou plusieurs modes de réalisation, le flux multimédia reçu par l’unité de gestion peut comprendre déjà un message de signalisation, par exemple un message de signalisation SCTE-35 de type « time_signal() ». Ce cas de figure illustre l’avantage que la présence de chaque message de signalisation préalablement inséré dans le flux multimédia reçu par l’unité de gestion (106) peut fournir l’opportunité d’y insérer des données de traçabilité de message de signalisation, afin par exemple d’effectuer une ou plusieurs mesures de latence. Ce cas de figure présente par ailleurs plusieurs avantages pour la mise en œuvre du procédé proposé : d’une part, l’insertion de données de traçabilité de message de signalisation dans un message de signalisation préexistant dans le flux multimédia n’a pas d’influence sur l’encodage et la mise en forme, car le conditionnement du flux pour y insérer des données de traçabilité est déjà contraint par le message existant dans le flux reçu. D’autre part, la mesure de latence aux points M3 et M4 de la est aisée dans les cas de figure dans lesquels l’image correspondant au point de raccord (« splice point ») est la première du segment média généré par l’unité de mise en forme. Enfin, le procédé proposé peut avantageusement être utilisé en production. Dans un ou plusieurs modes de réalisation, le flux multimédia reçu par l’unité de gestion peut ne pas comprendre de message de signalisation, par exemple de message (ou marqueur) de signalisation SCTE-35 de type « time_signal() ». Dans ce cas de figure, l’unité de gestion (106) peut être configurée pour générer un message de signalisation (par exemple de type SCTE-35) et l’insérer dans le flux multimédia reçu. En fonction du mode de réalisation, différents types de message pourront être utilisés (par exemple, dans le cad SCTE-35, un message de type « content identification » ou un message de type « break start »), en fonction par exemple de contraintes relative au conditionnement du flux effectué par l’encodeur. Dans un ou plusieurs modes de réalisation, l’encodeur peut effectuer un conditionnement de flux encodé, par exemple en insérant dans ce flux une image de référence (IDR) utilisée pour l’encodage de l’image sur laquelle pointe le message de signalisation, afin par exemple dans le cas où le message signale une coupure publicitaire que la coupure publicitaire objet du message démarre sur la première image d’un fragment (ou, selon les modes de réalisation, d’un segment média (le découpage en fragments (ou, selon les modes de réalisation, en segments) média étant effectué en aval du décodeur par une unité de mise en forme), et/ou que le décrochage (par exemple publicitaire, ou lors d’un blackout) puisse être effectué sans artefact par le lecteur ou décodeur vidéo. Dans un ou plusieurs modes de réalisation dans lesquels l’encodeur effectue un conditionnement du flux encodé, le type de message du marqueur de signalisation peut correspondre à un marqueur de publicité (par exemple du type « break start » dans le cas de figure SCTE-35), auquel cas l’encodeur peut être configuré pour placer une image de référence en lien avec l’image référencée par le marqueur de signalisation. L’image référencée par le marqueur de signalisation peut alors avantageusement être une IDR qui sera située au début du segment média généré par une unité de mise en forme située en aval de l’encodeur. Dans ces modes de réalisation, l’unité de gestion peut être configurée pour insérer des marqueurs de signalisation dans le flux multimédia à un rythme correspondant à la fréquence d’insertion des images de référence dans le flux encodé par l’encodeur. Ces modes de réalisation présentent plusieurs avantages pour la mise en œuvre du procédé proposé : d’une part, la mise en œuvre est possible sur n’importe quel flux multimédia d’entrée. D’autre part, la mesure de latence aux points M3 et M4 de la est aisée dans les cas de figure dans lesquels l’image correspondant au point de raccord (« splice point ») est la première du segment média généré par l’unité de mise en forme. Enfin, le procédé proposé permet une maitrise partielle de la fréquence des mesures de latence. Dans un ou plusieurs modes de réalisation dans lesquels l’encodeur effectue un conditionnement du flux encodé, le type de message du marqueur de signalisation peut ne pas correspondre à un marqueur de publicité, et par exemple être du type « content identification » dans le cas de figure SCTE-35, auquel cas l’encodeur peut ne pas placer des images de référence en lien avec l’image référencée par le marqueur de signalisation. Le découpage en segments (ou, selon les modes de réalisation, en fragments) effectué par une unité de mise en forme situé en aval de l’encodeur n’est donc pas modifié par les images de référence insérées dans le flux par l’encodeur. Ces modes de réalisation présentent plusieurs avantages pour la mise en œuvre du procédé proposé : d’une part, le procédé proposé permet une maitrise totale de la fréquence des mesures de latence. D’autre part, la mise en œuvre du procédé proposé n’a pas d’influence sur l’encodage vidéo. Dans un ou plusieurs modes de réalisation, le procédé proposé peut utiliser un message de signalisation d’évènement (par exemple, pour le protocole DASH ou pour le protocole HLS-fmp4 et donc pour le protocole CMAF, un message de type « emsg » (pour « event message »)) qui porte une signalisation d’évènements, tel que spécifié par la spécification ISO-IEC 23000 (et plus particulièrement la spécification ISO/IEC 23009-1:2022(E)). La détection d’une dérive de latence permet avantageusement de mettre en place des mécanismes correctifs afin d’éviter des perturbations dans la lecture du flux vidéo par le lecteur vidéo qui sont particulièrement désagréables pour l’utilisateur. Par exemple, dans les systèmes utilisant le format de transport MPEG-DASH, le lecteur vidéo stoppera la lecture du flux vidéo sur détection d’une dérive entre le temps qui s’écoule et le temps de référence du flux vidéo supérieure à la durée d’un segment MPEG-DASH. Dans de nombreux système, une dérive de latence supérieure à quelques secondes (par exemple supérieure à deux ou trois secondes) engendre une perturbation, voire une interruption de la lecture du flux vidéo. Dans un ou plusieurs modes de réalisation, on pourra calculer une moyenne de plusieurs mesures de latence effectuées selon le procédé proposé sur plusieurs images du flux vidéo, afin d’obtenir une valeur moyenne de latence pour le flux. Différentes mesures de latence pourront alors être comparées à la valeur moyenne de latence afin de déterminer la dérive de latence en utilisant la valeur moyenne. Par exemple, dans un ou plusieurs modes de réalisation, une mesure de latence pourra être effectuée pour toutes les images ou toutes les deux images du flux vidéo pendant un intervalle de mesure prédéterminé (par exemple d’une durée de quelques secondes) d’affichage des images du flux vidéo. Dans un autre mode de réalisation, on pourra effectuer un nombre prédéfini de mesures de latence (par exemple une dizaine ou une vingtaine de mesures) sur des images espacées d’un intervalle prédéfini (par exemple 100ms, afin de faire une dizaine ou une vingtaine de mesures sur des images espacées de 100ms). Une moyenne des mesures de latence effectuées pendant l’intervalle de mesure peut alors être effectuée pour obtenir une valeur moyenne de latence. Dans des modes de réalisation où le système de distribution utilise des unités de transport de données multimédia, par exemple de type « chunk » ou de type « segment », on pourra effectuer des mesures de latence selon le procédé proposé sur plusieurs images, voire sur chaque image de l’unité, et déterminer une valeur moyenne de latence à partir des mesures de latence qui représentera une valeur moyenne de latence pour l’unité (le « chunk » ou le segment). Ce procédé pourra être réitéré, par exemple à intervalles réguliers, afin de calculer plusieurs valeurs moyennes de latence. Par exemple, une première valeur moyenne de latence pourra être obtenue, puis une deuxième valeur moyenne pourra être déterminée après un intervalle de plusieurs minutes (par exemple 10 minutes ou 30 minutes). Une mesure de dérive de latence pourra alors être déterminée sur la base de la pluralité de valeurs moyennes de latence déterminées. Dans un ou plusieurs modes de réalisation, un seuil de détection de dérive pourra être prédéfini, et une ou plusieurs mesures de dérive de latence ou, en fonction du mode de réalisation, une valeur moyenne de dérive de latence, pourront être comparées à ce seuil afin de déterminer si la dérive de latence mesurée dépasse ou non un seuil. Le procédé proposé pourra en outre comprendre la détection de présence d’une dérive de latence, le déclenchement d’une alerte de dérive de latence et/ou la mise en œuvre d’actions correctives sur la base de la comparaison de la dérive de latence mesurée (par exemple une valeur moyenne de dérive de latence) avec le seuil prédéfini. En fonction du mode de réalisation choisi, les données d’horodatage peuvent comprendre des données de date et de temps exprimés avec différents niveaux de précision (par exemple un niveau de précision à la milliseconde) et selon différents formats (par exemple le format UTC, de l’anglais « Coordinated Universal Time »). La illustre un exemple d’architecture d’un dispositif pour la mise en œuvre du procédé proposé de traitement d’un flux multimédia, selon un ou plusieurs modes de réalisation. En référence à la , le dispositif 200a comprend un contrôleur 201a, couplé de manière opérationnelle à une interface d’entrée 202a, une interface de sortie 203a et à une mémoire 204a, qui pilote une unité de gestion de flux multimédia 205a. L’interface d’entrée 202a est configurée pour recevoir des données correspondant à un flux vidéo comprenant une séquence d’images. L’interface de sortie 203a est configurée pour fournir des données générées par l’unité de gestion de flux multimédia 205a sous la forme d’un flux vidéo enrichi issu du multiplexage d’un flux multimédia reçu avec un flux de données supplémentaires selon un ou plusieurs modes de réalisation d’un procédé proposé. Le contrôleur 201a est configuré pour piloter l’unité de gestion de flux multimédia 205a pour la mise en œuvre d’un ou de plusieurs modes de réalisation d’un procédé proposé. Dans un ou plusieurs modes de réalisation, l’unité de gestion de flux multimédia 205a peut être configurée pour démultiplexer le flux vidéo reçu sur l’interface d’entrée 202a pour générer des métadonnées de traçabilité d’une image de la séquence d’images ; insérer les métadonnées de traçabilité de l’image dans un flux de données supplémentaires obtenu par l’unité de gestion de flux multimédia ; et multiplexer le flux multimédia et le flux de données supplémentaires. Le dispositif 200a peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil (comme par exemple un serveur informatique) comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 201a, amènent ce contrôleur 201a à effectuer ou contrôler les parties interface d’entrée 202a, interface de sortie 203a, mémoire 204a, et unité de gestion de flux multimédia 205a pour la mise en œuvre d’un ou plusieurs modes de réalisation d’un procédé proposé. Le contrôleur 201a peut être un composant implémentant un ou plusieurs processeurs ou une unité de calcul pour le traitement de flux vidéo selon le procédé proposé et le contrôle des unités 202a, 203a, 204a et 205a du dispositif 200a. En outre, le dispositif 200a peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gate Array). La illustre un autre exemple d’architecture d’un dispositif pour la mise en œuvre du procédé proposé pour effectuer une mesure de latence, selon un ou plusieurs modes de réalisation. En référence à la , le dispositif 200b comprend un contrôleur 201b, couplé de manière opérationnelle à une interface d’entrée 202b et à une mémoire 203b, qui pilote une unité de traitement vidéo 204b. L’interface d’entrée 202b est configurée pour recevoir des données capturées par le dispositif 200b. Le contrôleur 201b est configuré pour piloter l’unité de traitement vidéo 204b pour la mise en œuvre d’un ou de plusieurs modes de réalisation d’un procédé proposé. Dans un ou plusieurs modes de réalisation, l’unité de traitement vidéo 204b peut être configurée pour effectuer les opérations suivantes : sur détection, à un premier point de la chaine de distribution multimédia, d’un message de signalisation correspondant à une image de la séquence d’images et comprenant des données de traçabilité (notamment dans la chaine de distribution multimédia), générer des premières données d’horodatage de détection du message de signalisation au premier point de la chaine de distribution multimédia ; sur détection, dans le flux multimédia, du message de signalisation à un deuxième point de la chaine de distribution multimédia, sur détermination que le message de signalisation comprend les données de traçabilité, générer des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point de la chaine de distribution multimédia ; et déterminer une mesure de latence associée à l’image sur la base des premières et deuxièmes données d’horodatage. Le dispositif 200b peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil (comme par exemple un serveur informatique) comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 201b, amènent ce contrôleur 201b à effectuer ou contrôler les parties interface d’entrée 202b, mémoire 203b et unité de traitement vidéo 204b pour la mise en œuvre d’un ou plusieurs modes de réalisation d’un procédé proposé. Le contrôleur 201b peut être un composant implémentant un ou plusieurs processeurs ou une unité de calcul pour le traitement de flux vidéo selon le procédé proposé et le contrôle des unités 202b, 203b et 204b du dispositif 200b. En outre, le dispositif 200b peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gate Array). En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement. Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé de pilotage proposé et le dispositif pour la mise en œuvre d’un mode de réalisation du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de la présente divulgation. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous-combinaisons des aspects et caractéristiques font partie de la portée de la présente divulgation. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés. Procédé de traitement d’un flux multimédia comprenant une séquence d’images, le procédé étant mis en œuvre par une unité de gestion de flux multimédia d’un système de distribution multimédia, et comprenant : générer des données de traçabilité de message de signalisation; modifier un message de signalisation comprenant un marqueur d’une image de la séquence d’images, le message de signalisation étant obtenu par l’unité de gestion de flux multimédia, le message de signalisation étant modifié en insérant les données de traçabilité du message de signalisation dans le message de signalisation; et insérer le message de signalisation modifié dans le flux multimédia. Procédé selon la revendication 1, dans lequel les données de traçabilité de message sont insérées dans un champ du message de signalisation. Procédé selon l’une quelconque des revendications précédentes, dans lequel le message de signalisation est compris dans le flux multimédia, le procédé comprenant en outre : extraire du flux multimédia le message de signalisation. Procédé de traitement d’un flux multimédia distribué par une chaîne de distribution multimédia dans un système de distribution multimédia, le flux multimédia comprenant une séquence d’images, le procédé étant mis en œuvre par une unité de traitement du système de distribution multimédia et comprenant : sur détection, à un premier point de la chaine de distribution multimédia, d’un message de signalisation correspondant à une image de la séquence d’images et comprenant des données de traçabilité, générer des premières données d’horodatage de détection du message de signalisation au premier point de la chaine de distribution multimédia ; sur détection, dans le flux multimédia, du message de signalisation à un deuxième point de la chaine de distribution multimédia, sur détermination que le message de signalisation comprend les données de traçabilité, générer des deuxièmes données d’horodatage de détection du message de signalisation au deuxième point de la chaine de distribution multimédia ; déterminer une mesure de latence associée à l’image sur la base des premières et deuxièmes données d’horodatage. Procédé selon la revendication 4, comprenant en outre : déterminer un premier écart temporel entre les premières données d’horodatage de détection du message de signalisation au premier point et un temps de mise à disposition de l’image au premier point ; et déterminer un deuxième écart temporel entre les deuxièmes données d’horodatage de détection du message de signalisation au deuxième point et un temps de mise à disposition de l’image au deuxième point ; dans lequel la mesure de latence est déterminée sur la base d’une combinaison des premières données d’horodatage, des deuxièmes données d’horodatage et des premier et deuxième écarts temporels. Procédé selon l’une quelconque des revendications précédentes, dans lequel les données de traçabilité de message de signalisation comprennent des données d’identification utilisables pour identifier le message de signalisation. Procédé selon l’une quelconque des revendications 1 à 3, dans lequel le marqueur de l’image comprend une information relative à un évènement associé à l’image. Procédé selon l’une quelconque des revendications précédentes, dans lequel le message de signalisation est de type SCTE-35. Dispositif de traitement de flux multimédia, comprenant un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 8. Programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre des étapes d’un procédé selon l’une quelconque des revendications 1 à 8 lors de l’exécution dudit programme par le processeur.