Brevet FR3151728A1 — publié le 20250131

Procédé de distribution d’un contenu multimédia, encapsulateur, système et programme d’ordinateur correspondants. L’invention concerne un procédé de distribution d’un contenu multimédia, mis en œuvre dans un encapsulateur (321, 322) d’un réseau de distribution destiné à mettre en œuvre au moins deux encapsulateurs, mettant en œuvre les étapes suivantes : obtention dudit contenu multimédia, obtention d’au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia et/ou d’au moins un identifiant d’objet représentatif d’au moins un identifiant associé à au moins un fichier représentatif dudit contenu multimédia, génération d’un flux de transport comprenant des paquets de transport construits à partir dudit contenu multimédia, lesdits paquets de transport portant un entête spécifique à un protocole de transport considéré, ledit entête comportant au moins un champ d’identification de session portant ledit au moins un identifiant de session et/ou au moins un champ d’identification d’objet portant ledit au moins un identifiant d’objet. Figure pour l’abrégé : figure 3 Procédé de distribution d’un contenu multimédia, encapsulateur, système et programme d’ordinateur correspondants. 1. Domaine technique Le domaine de l’invention est celui de la distribution de contenus multimédia. Plus précisément, l’invention propose une solution permettant à un utilisateur d’accéder à un contenu multimédia même en cas de défaillance d’un équipement du réseau de distribution. L’invention s’applique notamment, mais non exclusivement, à la distribution de services de type OTT (« Over The Top »). L’invention s’applique notamment au réseau Internet classique, ainsi qu’aux réseaux mobiles (par exemple 3GPP), terrestres (par exemple selon la norme DVB-T, DVB-T2 ou ATSC), satellites (par exemple selon la norme DVB-S ou DVB-S2) ou autres. 2. Art antérieur On présente ci-après, en relation avec la , une chaine classique pour la distribution d’un contenu multimédia, d’une source vers un utilisateur final. Ainsi, on considère un premier bloc 11 délivrant au moins un contenu multimédia. Un tel bloc comprend une source de contenus 111 délivrant au moins un contenu multimédia. Un tel contenu multimédia peut être formé par un ou plusieurs fichiers binaires 112. Le format du ou des fichiers binaires peut suivre différents formats d’encodage, par exemple : ISOBMFF (« ISO Base Media File Format »), DASH (« Dynamic Adaptative Streaming over HTTP »), MPU (« Media Processing Unit »), HLS (« HTTP Live Streaming »), TS (« Transport Stream »), etc. Les contenus multimédias, ou les fichiers binaires 112 correspondants, peuvent notamment être hébergés par une infrastructure CDN (« Content Delivery Network »). Dans ce cas, les clients des utilisateurs peuvent venir s’approvisionner en contenus « à la demande ». En variante, les contenus multimédias, ou les fichiers binaires 112 correspondants, peuvent être poussés directement dans le réseau de distribution. La chaine de distribution peut notamment porter un contenu multimédia de la source 111 vers l’utilisateur final 13 au moyen de liens unicast, multicast ou broadcast. Quand le contenu est fourni à la chaine de distribution au travers d’un lien unicast (i.e. le contenu est destiné à un seul utilisateur), l’encapsulation du contenu, i.e. la décomposition du contenu en paquets de transport, peut être mise en œuvre par le premier bloc 11, par exemple en tête de réseau. Les technologies utilisées pour le transport des paquets de transport sont classiquement de type : IP/TCP/HTTP, IP/UDP/(TS, QUIC, etc). Dès lors que le même contenu multimédia est consommé par plusieurs utilisateurs, notamment au même instant (« consommation concurrentielle » du contenu), l’utilisation de liens unicast mène à une surconsommation de la bande passante du réseau de distribution. Afin d’éviter une telle surconsommation, des liens multicast ou broadcast sont utilisés par le réseau pour distribuer le contenu entre la source 111 et les utilisateurs finaux 131, 132, 133, comme illustré en . Quand le contenu est fourni à la chaine de distribution au travers de liens multicast ou broadcast (i.e. le contenu est destiné à plusieurs utilisateurs), la chaine de distribution peut inclure une entité dédiée à l’encapsulation du contenu, appelée « encapsulateur IP » 12. Un tel encapsulateur 12 peut notamment décomposer le contenu sous forme de paquets de transport IP. Les technologies utilisées pour le transport des paquets de transport sont classiquement de type IP/UDP(RTP), sur lesquelles différents protocoles de livraison de contenu multimédia existent : FLUTE, ROUTE, MMT, QUIC multicast, HLS, etc. La illustre également un exemple des différents protocoles pouvant être utilisés pour la distribution de contenus dans un réseau de distribution. On note qu’un ou plusieurs protocoles peuvent être supportés, suivant la nature des chaines de transmission (câble, terrestre, mobile, satellite …) et les normes associées (3GPP, ATSC, DVB, …). De même, les chaines de transmission peuvent être hybrides mélangeant les liens unicast, multicast et broadcast aussi bien que les protocoles entre une source de contenus 111 et le client consommateur final 13. A l’autre extrémité de la chaine de distribution se trouve le bloc consommateur/client final 13, qui permet de restituer le contenu multimédia à l’utilisateur. Le contenu à restituer peut notamment être reconstruit à partir des paquets de transport reçus. Comme indiqué précédemment, quand le contenu est fourni à la chaine de distribution au travers d’un lien unicast, le transport des paquets de transport peut mettre en œuvre un protocole de type IP/TCP/HTTP. Dans ce cas, en cas de défaillance au niveau de l’encapsulation, la retransmission de paquets de transport est prévue par le protocole TCP. A contrario, la retransmission de paquets de transport en cas de défaillance au niveau de l’encapsulation n’est pas prévue par le protocole UDP. Il n’existe donc pas de mécanisme permettant à l’utilisateur 13 de reconstruire le contenu en cas de défaillance de l’encapsulateur quand le contenu est fourni à la chaine de distribution au travers de liens multicast et broadcast. Une première solution serait d’utiliser des codes correcteurs d’erreur (FEC). Toutefois, une telle solution ne permet pas de se prémunir de telles défaillances (panne, indisponibilité de l’encapsulateur) étant donné la durée temporelle de l’interruption. Une deuxième solution serait d’utiliser une boucle de retour réparatrice. Toutefois, une telle solution est difficile à implémenter. En effet, dans plusieurs scénarios de déploiement (par exemple de type DVB-NIP – DVB Native IP Broadcasting), une telle boucle n’existe pas. De plus, il n’est pas souhaitable que les utilisateurs basculent massivement sur le lien unicast, ce qui générerait un pic de débit dans le réseau et une surconsommation de la bande passante. De ce fait, les schémas de redondance classique (« active-standby » ou « active-active ») hérités de l’Internet ne correspondent pas au besoin, puisque ces derniers impliquent une interruption, même brève, dans le flux de transport du contenu fourni au consommateur final. Il existe donc un besoin pour une nouvelle solution permettant de fournir un contenu multimédia à un utilisateur même en cas de défaillance d’un encapsulateur, sans perturbation pour l’utilisateur final. 3. Exposé de l’invention L’invention propose une solution sous la forme d’un procédé de distribution d’un contenu multimédia, mis en œuvre dans un encapsulateur d’un réseau de distribution destiné à mettre en œuvre au moins deux encapsulateurs, mettant en œuvre les étapes suivantes : obtention dudit contenu multimédia, obtention d’au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia et/ou d’au moins un identifiant d’objet représentatif d’au moins un identifiant associé à au moins un fichier représentatif dudit contenu multimédia, génération d’un flux de transport comprenant des paquets de transport construits à partir dudit contenu multimédia, lesdits paquets de transport portant un entête spécifique à un protocole de transport considéré, ledit entête comportant au moins un champ d’identification de session portant ledit au moins un identifiant de session et/ou au moins un champ d’identification d’objet portant ledit au moins un identifiant d’objet. Un encapsulateur selon l’invention peut ainsi générer un flux de transport comprenant des paquets de transport portant un entête particulier, i.e. dont les valeurs portées par certains champs sont construites à partir du contenu multimédia à distribuer. Les valeurs portées par ces champs de l’entête des paquets de transport sont donc déterministes. De cette façon, lorsque plusieurs encapsulateurs sont prévus dans le réseau de distribution, chaque encapsulateur génère un flux de transport dont les valeurs portées par certains champs de l’entête des paquets de transport sont construites à partir du même contenu multimédia à distribuer. Les différents flux de transport ainsi générés sont donc identiques, ou sensiblement identiques, pour l’utilisateur final. Il est ainsi possible de commuter d’un flux de transport à un autre en cas de défaillance d’un encapsulateur, sans perturbation pour l’utilisateur. Dans un mode de réalisation particulier, ledit au moins un identifiant associé audit contenu multimédia, également appelé « empreinte de session », appartient au groupe comprenant : un type dudit contenu multimédia, au moins une partie d’un nom d’au moins un fichier représentatif dudit contenu multimédia, des métadonnées associées audit au moins un fichier, une combinaison d’au moins deux informations parmi ledit type, ladite au moins une partie d’un nom, et lesdites métadonnées. Selon un premier exemple, ledit type dudit contenu multimédia est obtenu à partir d’un message HTTP reçu d’un serveur de contenus distribuant ledit contenu. Selon un deuxième exemple, ledit type dudit contenu multimédia est obtenu à partir d’une analyse dudit au moins un fichier représentatif dudit contenu multimédia. Selon un troisième exemple, ledit type dudit contenu multimédia est obtenu à partir de la réception d’une donnée de signalisation. L’empreinte de session peut être construite par l’encapsulateur. En variante, l’empreinte de session peut être construite par une autre entité, par exemple le serveur de contenu distribuant ledit contenu multimédia, et reçue par l’encapsulateur. Une telle empreinte de session permet d’identifier de façon unique le contenu multimédia considéré. Dans un mode de réalisation particulier, ledit identifiant de session appartient au groupe comprenant : ledit au moins un identifiant associé audit contenu multimédia. Dans ce cas, l’identifiant de session correspond à l’empreinte de session ; une fonction dudit au moins un identifiant associé audit contenu multimédia. Dans ce cas, l’identifiant de session est obtenu en appliquant une fonction à l’empreinte de session, par exemple une fonction de hachage. En d’autres termes, il existe une correspondance calculatoire entre l’identifiant de session et l’identifiant associé audit contenu multimédia ; une valeur. Dans ce cas, l’identifiant de session correspond par exemple à un indice (1, 2, 3, ou M, N, etc). En d’autres termes, il existe une correspondance statique entre l’identifiant de session et l’identifiant associé audit contenu multimédia. L’identifiant de session peut être construit par l’encapsulateur. En variante, l’identifiant de session peut être construit par une autre entité, par exemple le serveur de contenu distribuant ledit contenu multimédia, et reçu par l’encapsulateur. Dans un mode de réalisation particulier, ledit au moins un identifiant associé audit au moins un fichier, également appelé « empreinte d’objet » appartient au groupe comprenant : au moins une partie d’un nom dudit au moins un fichier, au moins une partie d’un contenu binaire dudit au moins un fichier, des métadonnées associées audit au moins un fichier, une combinaison d’au moins deux informations parmi ladite au moins une partie d’un nom, ladite au moins une partie d’un contenu binaire et desdites métadonnées. L’empreinte d’objet peut être construite par l’encapsulateur. En variante, l’empreinte d’objet peut être construite par une autre entité, par exemple le serveur de contenu distribuant ledit contenu multimédia, et reçue par l’encapsulateur. Dans un mode de réalisation particulier, ledit identifiant d’objet appartient au groupe comprenant : ledit au moins un identifiant associé audit au moins un fichier. Dans ce cas, l’identifiant d’objet correspond à l’empreinte d’objet ; une fonction dudit au moins un identifiant associé audit au moins un fichier. Dans ce cas, l’identifiant d’objet est obtenu en appliquant une fonction à l’empreinte d’objet, par exemple une fonction de hachage. En d’autres termes, il existe une correspondance calculatoire entre l’identifiant d’objet et l’identifiant associé audit au moins un fichier ; une valeur. Dans ce cas, l’identifiant d’objet correspond par exemple à un indice (1, 2, 3, ou M, N, etc). En d’autres termes, il existe une correspondance statique entre l’identifiant d’objet et l’identifiant associé audit au moins un fichier. L’identifiant d’objet peut être construit par l’encapsulateur. En variante, l’identifiant d’objet peut être construit par une autre entité, par exemple le serveur de contenu distribuant ledit contenu multimédia, et reçu par l’encapsulateur. En particulier, lesdites métadonnées peuvent être transportées à l’intérieur (« inband ») ou en dehors (« outband ») dudit fichier représentatif dudit contenu multimédia. Par exemple, de telles métadonnées sont générées par le serveur de contenu et peuvent être utilisées par le client final pour la restitution du contenu multimédia. Dans un mode de réalisation particulier, ledit protocole de transport appartient au groupe comprenant : le protocole FLUTE, le protocole ROUTE, le protocole MMT, le protocole QUIC multicast, le protocole NORM, le protocole HLS. En particulier, le format dudit au moins un fichier appartient au groupe comprenant : ISOBMFF DASH MPU HLS Dans un autre mode de réalisation, l’invention concerne un encapsulateur correspondant. Un tel encapsulateur est notamment adapté à mettre en œuvre le procédé de distribution d’un contenu multimédia décrit précédemment. Un tel encapsulateur pourra bien sûr présenter les différentes caractéristiques relatives au procédé selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cet encapsulateur sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement. Dans un autre mode de réalisation, l’invention concerne un système de distribution mettant en œuvre au moins deux encapsulateurs correspondants, délivrant chacun un flux de transport, tel que les entêtes des paquets de transport des différents flux de transport sont identiques. En particulier, de tels encapsulateurs peuvent être localisés à des emplacements distincts, L’invention concerne encore au moins un programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé de distribution d’un contenu multimédia décrit ci-dessus, lorsque ce ou ces programmes sont exécutés par un processeur, ainsi qu’au moins un support d’informations lisible par un ordinateur comportant des instructions d’au moins un programme d’ordinateur tel que mentionné ci-dessus. Le procédé selon l’invention peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. 4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la illustre un exemple de chaine de distribution selon l’art antérieur, la illustre un exemple des différents protocoles pouvant être utilisés dans une chaine de distribution selon la , la illustre un exemple de chaine de distribution selon un mode de réalisation particulier de l’invention, la illustre un exemple d’encapsulation du contenu multimédia dans des paquets de transport, la illustre les principales étapes mises en œuvre par un encapsulateur selon un mode de réalisation l’invention, la , la , et la illustrent des exemples d’empreintes de session et d’identifiants de session correspondants, la et la illustrent des exemples d’empreintes d’objet et d’identifiants d’objet correspondants, la illustre un exemple d’obtention d’une empreinte de session à partir de l’entête HTTP, la illustre un exemple d’extension d’une empreinte de session en y ajoutant d’autres informations, la illustre un exemple de détermination d’empreinte de session étendue à partir d’un manifest DASH, la illustre un exemple de structure « emboitée » d’un fichier ISOBMFF, la illustre un exemple d’extraction de métadonnées dans un fichier ISOBMFF pour la détermination d’une empreinte de session, la illustre un exemple d’extraction de métadonnées dans un fichier ISOBMFF pour la détermination d’une empreinte d’objet, la illustre la structure simplifiée d’un encapsulateur selon un mode de réalisation de l’invention. 5. Description de modes de réalisation de l’invention 5.1 Contexte de l’invention L’invention se place dans le contexte de la distribution de contenus au travers de liens multicast ou broadcast (i.e. le contenu est destiné à plusieurs utilisateurs), selon laquelle le contenu multimédia est encapsulé dans des paquets de transport pour distribution aux différents utilisateurs. L’ajout d’un tel encapsulateur dans une chaine de distribution peut introduire un point de défaillance qui pourrait impacter l’utilisateur final. Afin de limiter ce risque, une redondance de l’encapsulateur est prévue dans la chaine de distribution. Il est ainsi possible de basculer d’un premier encapsulateur générant un premier flux de transport, vers un deuxième encapsulateur générant un deuxième flux de transport, en cas de défaillance du premier encapsulateur. En particulier, on cherche selon l’invention à éviter que la commutation d’un flux de transport vers un autre flux de transport soit visible pour l’utilisateur. En d’autres termes, on cherche une solution pour une commutation sans perturbation pour l’utilisateur (« seamless switch »). La illustre un exemple de chaine de distribution selon un mode de réalisation de l’invention, mettant en œuvre deux encapsulateurs 321 et 322. Une telle chaine de distribution comprend plusieurs blocs communiquant entre eux, via des liens IP par exemple. On note que l’utilisation de liens IP ne restreint pas l’invention au réseau Internet classique, mais couvre aussi les réseaux mobiles (par exemple 3GPP), terrestres (par exemple selon la norme DVB-T ou ATSC), satellites (par exemple selon la norme DVB-S) ou autres. Chaque encapsulateur 321, 322 peut recevoir le contenu multimédia délivré par la source 311, par exemple sous la forme d’au moins un fichier 312, notamment un fichier binaire, et délivrer un flux de transport. Le contenu multimédia peut être temps réel (« live ») ou non temps réel (par exemple à la demande – VOD « Video On Demand »). Le format du ou des fichiers 312 peut suivre différents formats d’encodage, par exemple ISOBMFF, DASH, MPU, HLS, etc. Par exemple, un encapsulateur 321, 322 peut se connecter à une entité d’une infrastructure CDN pour récupérer un contenu hébergé par cette entité, puis décomposer le contenu ainsi obtenu en paquets de transport pour l’acheminer vers au moins un utilisateur 34. En variante, un encapsulateur 321, 322 peut recevoir le contenu, puis décomposer le contenu ainsi obtenu en paquets de transport pour l’acheminer vers l’utilisateur 34. Selon un mode de réalisation de l’invention, un commutateur 33 est prévu pour basculer d’un flux de transport à un autre en cas de défaillance d’un des encaspulateurs 321, 322. Le commutateur 33 peut notamment acheminer le flux de transport qu’il reçoit vers l’utilisateur 34. Dans un autre mode de réalisation, le commutateur 33 peut être intégré à l’équipement de l’utilisateur 34. Dans ce cas, les flux de transport générés par les différents encapsulateurs peuvent parvenir jusqu’à l’utilisateur 34. Afin de permettre une telle commutation, les encapsulateurs 321, 322 du réseau de distribution peuvent agir de façon identique. Les flux de transport générés par les différents encapsulateurs peuvent alors être identiques, ou à tout le moins similaires, au niveau du protocole de transport, du point de vue de l’utilisateur. Pour atteindre cet objectif, les processus de mise en forme des paquets de transport, mis en œuvre dans chaque encapsulateur 321, 322 peuvent être synchronisés. Puisque les différents encapsulateurs partagent la même source de contenu, i.e reçoivent le même contenu multimédia, les inventeurs ont eu l’idée d’utiliser le contenu multimédia comme référence de synchronisation, comme décrit ci-après. On note que d’autres sources externes de synchronisation pourraient être utilisées pour synchroniser les différents flux de transport. Toutefois, l’ingestion du contenu en entrée peut souffrir de délai variable en fonction des encapsulateurs. Il est donc plus efficace de synchroniser sur le contenu multimédia, couplé si besoin à une référence temporelle externe pour synchroniser l’ingestion du contenu. On note par ailleurs qu’un ou plusieurs protocoles de transport peuvent être supportés par la chaine de distribution, suivant par exemple la nature de la transmission (câble, terrestre, mobile, satellite …) et les normes associées (3GPP, ATSC, DVB, …). De même, les chaines de distribution peuvent être hybrides mélangeant les liens unicast, multicast et broadcast aussi bien que les protocoles entre une source de contenu et le client consommateur final. Pour rendre similaires les flux de transport en sortie des différents encapsulateurs de la chaine de distribution, au niveau du protocole de transport (au-dessus des couches IP/UDP), un mode de réalisation de l’invention propose de rendre déterministe et synchrone l’encapsulation. L’invention propose ainsi une solution permettant que certains champs des entêtes du protocole de transport soient alignés, i.e. identiques pour un même objet transporté. Comme illustré en , l’encapsulation consiste à décomposer le contenu (par exemple transmis sous la forme d’au moins un fichier binaire 312) en un ensemble de paquets de transport et à y ajouter un entête spécifique au protocole de transport considéré. L’encapsulation est assez contrainte notamment par la taille du paquet IP (MTU, « Maximum Transmission Unit »). Si la taille d’un paquet de transport est identique entre deux encapsulateurs, la décomposition est identique, ainsi que la plupart des champs de l’entête. Il s’agit donc de contraindre les champs restants afin d’avoir des entêtes identiques ou similaires. Parmi les différents protocoles de transport considérés ( FLUTE, ROUTE, MMT, QUIC multicast, NORM, HLS, etc), les inventeurs ont identifié deux champs d’entête qu’il est possible de contraindre : un champ d’identification de session et un champ d’identification d’objet. Classiquement, un identifiant de session peut être utilisé pour distinguer la signalisation, les composantes audio, vidéo, sous-titres, etc, dans un contenu multimédia. Un identifiant d’objet est quant à lui utilisé au sein d’une session donnée afin d’identifier un fichier spécifique. En effet, le contenu peut être transmis de façon non monolithique par une succession de petits fichiers de contenu chacun représentant un fragment du contenu. En variante, le contenu peut être transmis sous la forme d’un flux de données. Par exemple, les encapsulateurs d’un couple mettent en œuvre un même protocole de transport (où un couple comprend un premier encapsulateur – par exemple l’encapsulateur 321 – et un deuxième encaspulateur redondant le premier encapsulateur – par exemple l’encapsulateur 322). Dans ce cas, les entêtes des paquets de transport sont identiques car couvrant le même protocole. En variante, les encapsulateurs d’un couple mettent en œuvre des protocoles de transport différents. Dans ce cas, les entêtes des paquets de transport ne sont pas strictement identiques au niveau bits puisque couvrant deux protocoles différents. Ils sont toutefois similaires car les valeurs d’identifiant de session, portée par le champ d’identification de session, et d’identifiant d’objet, portée par le champ d’identification d’objet, sont identiques. Si l’on se place dans le contexte d’un réseau hybride, plusieurs couples d’encapsulateurs peuvent s’enchainer séquentiellement dans le réseau de distribution. Par exemple, les deux encapsulateurs d’un premier couple mettent en œuvre un même protocole de transport, comme ROUTE, et peuvent être suivis dans le réseau de distribution par un deuxième couple d’encapsulateurs mettant en œuvre un même protocole de transport, comme FLUTE. En variante, les encaspulateurs d’un même couple mettent en œuvre des protocoles de transport différent. 5.2 Description d’un mode de réalisation particulier 5.2.1 Principe général La illustre les principales étapes mises en œuvre par un encapsulateur selon un mode de réalisation l’invention, par exemple l’encpasulateur 321 de la . Au cours d’une première étape 51, l’encpasulateur obtient le contenu multimédia à distribuer, par exemple sous la forme d’au moins un fichier binaire ou d’un flux de données. Comme indiqué ci-dessus, le contenu peut éventuellement être transmis d’un bloc, ou sous la forme d’une pluralité de fichiers représentant chacun un fragment du contenu. Par exemple, l’encapsulateur peut se connecter à une entité d’une infrastructure CDN pour récupérer le contenu hébergé par cette entité. En variante, l’encapsulateur 321 peut recevoir le contenu d’un serveur de contenu. Au cours d’une deuxième étape 52, l’encpasulateur 321 obtient au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia (« empreinte de session ») et/ou au moins un identifiant d’objet représentatif d’au moins un identifiant associé audit au moins un fichier (« empreinte d’objet »). Au cours d’une troisième étape 53, l’encpasulateur 321 génère un flux de transport comprenant des paquets de transport construits à partir du contenu multimédia, tel que les paquets de transport portent un entête spécifique à un protocole de transport considéré, avec ledit au moins un identifiant de session dans le champ d’identification de session et ledit au moins un identifiant d’objet dans le champ d’identification d’objet de l’entête. Comme expliqué ci-dessus, de telles étapes permettent de construire un flux de transport de façon déterministe. Les étapes de la peuvent notamment être mises en œuvre par au moins un autre encapsulateur de la chaine de distribution, par exemple l’encapsulateur 322 de la , qui dispose du même contenu multimédia en entrée. De cette façon, au moins deux flux de transport sensiblement identiques sont générés, et le commutateur 33 peut basculer de l’un à l’autre en cas de défaillance d’un des encapsulateurs. On note que le protocole de transport considéré n’est pas nécessairement identique entre les différents encapsulateurs d’un même couple, ou de couples successifs. On décrit ci-après quelques exemples pour la détermination d’un identifiant de session, en se basant sur le contenu multimédia. Comme déjà indiqué, un tel identifiant peut être déterminé par l’encapsulateur, ou par une autre entité (appartenant au réseau de distribution ou non) et transmis à l’encapsulateur. Notamment, un tel identifiant de session est représentatif d’au moins un identifiant associé au contenu multimédia, également appelé empreinte de session. Une première option est d’utiliser le type de contenu (« MIME type »), par exemple audio, vidéo, sous-titre, etc., comme empreinte de session. Selon un exemple, un tel type peut être récupéré lors de l’ingestion entre la source de contenu et l’encapsulateur, par exemple dans les échanges HTTP. Alternativement, une analyse du contenu multimédia (par exemple d’au moins un fichier binaire) après réception sur l’encapsulateur, la réception d’une donnée de signalisation, ou autre technique, peuvent également permettre d’extraire le type de contenu. Comme illustré en , l’empreinte de session est par exemple « video/mp4 » pour une composante vidéo, et/ou « audio/mp4 » pour une composante audio. L’identifiant de session représentatif de l’empreinte de session « video/mp4 » est par exemple une valeur M, et l’identifiant de session représentatif de l’empreinte de session « audio/mp4 » est par exemple une valeur N. A chaque type de contenu, on attribue ainsi une unique empreinte de session, et par suite un unique identifiant de session partagé par les différents encapsulateurs de la chaine de distribution. En d’autres termes, selon ce mode de réalisation, tous les encapsulateurs de la chaine de distribution attribueront le même identifiant de session (par exemple la valeur M) à un type de contenu particulier (par exemple au contenu vidéo associé à l’empreinte de session « video/mp4 »). Cette première option basée sur l’utilisation d’un type de contenu uniquement peut fonctionner lorsque le contenu multimédia ne comporte que des composantes de type distinct (audio, vidéo, …). Néanmoins, cette première option peut se montrer insuffisante pour garantir l’unicité de l’identifiant de session dès lors que le contenu comporte plusieurs composantes de même type (par exemple plusieurs composantes audios avec des langues différentes, ou des composantes vidéos utilisant des codecs différents ou des résolutions différentes). En complément ou alternativement à la première option, il est possible d’utiliser d’autres informations relatives au contenu multimédia pour construire l’empreinte de session. Par exemple, il est possible d’utiliser le nom d’au moins un fichier binaire représentatif du contenu, ou une partie de celui-ci (obtenue via des motifs ou « patterns »). D’autres métadonnées intrinsèques au type de fichier, comme la langue utilisée (pour l’audio et les sous-titres), le codec, et/ou la résolution peuvent être utilisées. Par exemple, comme illustré en , une première empreinte de session est associée au type « video/mp4 », avec le nom « video-720p-1.mp4 » et la résolution « 720p », et une deuxième empreinte de session est associée au type « video/mp4 », avec le nom « video-1080p-1.mp4 » et la résolution « 1080p ». L’identifiant de session représentatif de la première empreinte de session est par exemple une valeur M, et l’identifiant de session représentatif de la deuxième empreinte de session est par exemple une valeur N. Ceci permet de construire, pour chaque contenu multimédia, une empreinte unique pour la session, à laquelle on peut associer un identifiant de session unique. L’obtention de l’identifiant de session à partir de l’empreinte de session peut se faire de diverses manières. Selon un premier exemple, cette correspondance peut se faire de façon statique, par exemple en attribuant une valeur ou un indice à chaque empreinte de session. En particulier, chaque norme de diffusion définie un jeu de langues, codecs, résolutions, etc., supportés, ce qui aboutit à un nombre d’empreintes de session dénombrable. Si la taille de l’identifiant de session permet de lister toutes les empreintes de session possibles, alors on peut garantir un identifiant de session déterministe et unique. Selon un mode de réalisation particulier, on peut décomposer la plage de valeurs de l’identifiant de session en sous-plages pour faciliter la classification des empreintes. Par exemple, les empreintes de session correspondant à des composantes vidéo sont affectées à telle plage de valeurs, celles correspondant à des composantes audio à telle autre plage de valeurs, etc… Selon un deuxième exemple, la correspondance peut également se faire de façon calculatoire, par exemple en appliquant une fonction à l’empreinte de session. Une telle fonction est par exemple une fonction de hachage, ou tout autre fonction permettant de lier l’empreinte de session à l’identifiant de session. En particulier, la fonction peut notamment être choisie de sorte à valider l’adéquation entre la taille de l’identifiant de session et la résistance à la collision de la fonction (de hachage). La figure 6C illustre ces deux premiers exemples. Selon un troisième exemple, l’identifiant de session est directement l’empreinte de session. Il est important de noter que le contenu multimédia peut avoir un comportement dynamique caractérisé par des périodes, notamment pour les contenus de type temps réel (live). Il est alors souhaitable de bien sélectionner les informations utilisées pour construire l’empreinte de session (nom de fichier, codecs, langue, résolution …) afin de ne pas changer l’identifiant de session inutilement. Par exemple, si le codec est amené à changer au cours de la distribution, il est préférable de ne pas ajouter le codec dans l’empreinte de session. On décrit désormais quelques exemples pour la détermination d’un identifiant d’objet, en se basant cette fois sur au moins un fichier (i.e sur un fragment du contenu plutôt que sur l’ensemble du contenu). Comme déjà indiqué, un tel identifiant d’objet peut être déterminé par l’encapsulateur, ou par une autre entité (appartenant au réseau de distribution ou non) et transmis à l’encapsulateur. Notamment, un tel identifiant d’objet est représentatif d’au moins un identifiant associé à au moins un fichier, également appelé empreinte d’objet. Une première option est d’utiliser le nom d’au moins un fichier binaire représentatif du contenu, ou une partie de celui-ci (par exemple obtenue via des patterns) pour déterminer l’empreinte d’objet. En complément ou alternativement à la première option, il est possible d’utiliser au moins une partie du contenu binaire du fichier pour déterminer l’empreinte d’objet et/ou des métadonnées. L’obtention de l’identifiant d’objet à partir de l’empreinte d’objet peut se faire de diverses manières, par exemple en appliquant une fonction à l’empreinte d’objet ou une extraction en respectant un pattern (regex). Dans l’exemple illustré en , l’empreinte d’objet correspond au nom du fichier (« video-720p-1.mp4 », « video-720p-2.mp4 », « video-720p-3.mp4 »). Un motif commun est identifié : « video-720p-$.mp4 ». L’identifiant d’objet peut être construit à partir des différences par rapport à ce motif commun. Ainsi, l’identifiant d’objet associé à l’empreinte d’objet « video-720p-1.mp4 » est par exemple M+1, l’identifiant d’objet associé à l’empreinte d’objet « video-720p-2.mp4 » est par exemple M+2, et l’identifiant d’objet associé à l’empreinte d’objet « video-720p-3.mp4 » est par exemple M+3. L’avantage d’une solution basée sur le nom (ou partie du nom) du fichier est qu’elle est agnostique par rapport au type du contenu obtenu en entrée de l’encapsulateur. De plus, elle offre la possibilité d’utiliser un incrément régulier pour les identifiants d’objet (par exemple +1), notamment si les fichiers correspondant à des fragments temporels du contenu sont numérotés successivement. Il y a néanmoins une contrainte sur la source de contenu afin de différencier le nom du fichier associé à chaque objet / fragment du contenu multimédia, pour garantir l’unicité des identifiants d’objet. En variante, une fonction peut être appliquée à l’empreinte d’objet pour déterminer l’identifiant d’objet. Une telle fonction est par exemple une fonction de hachage, ou tout autre fonction permettant de lier l’empreinte d’objet à l’identifiant d’objet. Une telle fonction peut être appliquée sur au moins une partie du nom du fichier, ou sur au moins une partie du contenu du fichier lui-même. Là encore, la solution reste agnostique vis-à-vis du type de contenu. La solution basée sur le contenu du fichier peut nécessiter de recevoir l’intégralité du fichier avant d’appliquer la fonction de hachage, ce qui peut induire une latence de traitement plus importante. Selon encore une variante, illustré en , l’empreinte d’objet peut être construite à partir de métadonnées associées à au moins un fichier représentatif du contenu multimédia. Il est ainsi possible de contraindre l’identifiant d’objet sur les métadonnées associées à un fragment du contenu multimédia, par exemple en liant l’identifiant d’objet à des identifiants du format du fichier représentatif du contenu (ISOBMFF, DASH, MPU…). La technique est alors dépendante du format d’entrée du fichier sur l’encapsulateur. La détermination de l’identifiant d’objet peut nécessiter, selon un mode de réalisation, la réception préalable des métadonnées, ce qui peut entraîner une latence de traitement. Néanmoins, en sélectionnant certaine(s) métadonnée(s) dans le format originel format du fichier représentatif du contenu, on peut à la fois garantir l’unicité et d’éventuelle contrainte d’incrément régulier pour les identifiants d’objet. La correspondance entre les identifiants de session/objet et les empreintes de session/objet associées à chaque protocole de transport est détaillée ci-après pour le protocole ROUTE. De façon similaire, des correspondances pourraient être établies pour d’autres protocoles de transport, comme les protocoles FLUTE, MMT, QUIC Multicast, NORM, HLS, etc. 5.2.2 Mise en œuvre pour le protocole ROUTE On présente ci-après un exemple de mise en œuvre de l’invention lorsque le protocole de transport utilisé est le protocole ROUTE. Rappels Le protocole de transport ROUTE est décrit dans le document ATSC A/331 et dans le document RFC 9223. Il est notamment utilisé dans les standards de diffusions suivants : ATSC 3.0, DVB-MABR, DVB-NIP. Il permet notamment de transporter tout type de fichier, temps réel ou non, comme des segments multimédias DASH, HLS, des fichiers de guide de programme OMA-BCAST, etc. Au niveau couche protocolaire, le protocole ROUTE opère sur les couches IP/UDP (et potentiellement RTP). Le protocole ROUTE dérive des protocoles LCT (RFC 5651), ALC (RFC 5775) et de FLUTE (RFC 6726). L’entête d’encapsulation reprend ainsi un entête LCT suivi d’un entête d’utilisation de codes correcteurs d’erreur (FEC). Il s’en suit la charge utile du paquet, reprenant une partie du fichier binaire à encapsuler. La structure de l’entête d’un paquet ROUTE est rappelée dans le tableau ci-après : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Entête UDP (« UDP header ») Entête LCT (« LCT header ») Entête d’utilisation de FEC (« FEC Payload ID ») Charge utile (« Payload data ») … Le détail de l’entête LCT est rappelé dans le tableau ci-après : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 V C PSI S O H Res A B HDR_LEN Codepoint (CP) Information de contrôle de congestion (CCI, longueur = 32*(C+1) bits) … Identifiant de session de transport (TSI, longueur = 32*S+16*H bits) … Identifiant d’objet de transport (TOI, longueur = 32*O+16*H bits) … Extensions de l’en-tête (si applicable) … Le protocole ROUTE repose sur l’utilisation des champs TSI (« Transport Session Identifier ») et TOI (« Transport Object Identifier ») – champs ‘S’ = ‘1’ et ‘O’ = ‘01’ – et fixe leur taille sur 32 bits – champ ‘H’ = ‘0’. Exemples de mise en œuvre de l’invention Selon un mode de réalisation de l’invention, on propose d’utiliser respectivement le champ TSI pour porter l’identifiant de session et le champ TOI pour porter l’identifiant d’objet, tels que définis précédemment. Ces champs étant actuellement sur 32 bits, ils peuvent porter environ 4,295 milliards de valeurs d’identifiants distinctes. La valeur « 0 » étant souvent utilisée de façon spécifique dans les standards ATSC et DVB, on peut donc choisir de ne pas utiliser cette valeur. B.1 Identifiant de session Concernant l’identifiant de session, et donc la valeur portée par le champ TSI, toutes les techniques décrites précédemment peuvent être mises en œuvre pour déterminer une empreinte de session associée au contenu multimédia. Certaines techniques basées sur le type du contenu multimédia ou le nom du ou des fichiers représentatifs du contenu multimédia pour la détermination d’une empreinte de session sont dites « agnostiques ». Par exemple, si l’empreinte de session est obtenue à partir du type du contenu ou d’un nom d’au moins un fichier représentatif du contenu, l’empreinte de session peut être déterminée directement lors de l’échange entre la source de contenu (311) et l’encapsulateur IP (321) par l’entête HTTP comme illustré en . Si une telle empreinte de session est insuffisante pour garantir l’unicité de l’identifiant de session, il est possible « d’étendre » l’empreinte de session en y ajoutant d’autres informations. Cela peut se faire de façon agnostique vis-à-vis du format de fichier (format DASH, HLS, etc.), par exemple en utilisant des règles de nommage permettant d’identifier de façon unique les sessions dès la source. Par exemple, les fichiers associés à une composante d’un même type sont nommés en respectant un même pattern. Ainsi, dans l’exemple illustré en , un fichier correspondant à une première composante audio est nommé « TS-49410_1_audio_1-118631644 » et un fichier correspondant à une deuxième composante audio est nommé « TS-49410_1_audio_2-118631644 ». Le pattern associé est donc « TS-49410_1_audio_$-118631644 ». I l est ainsi possible d’utiliser un incrément régulier pour les identifiants de session (par exemple +1), notamment si les fichiers correspondant à des composantes de même type sont numérotés successivement. Dans ce cas, comme précédemment, l’empreinte de session, et donc l’identifiant de session, peuvent être déterminés à partir des entêtes HTTP. D’autres techniques pour la détermination d’une empreinte de session sont dites « non agnostiques ». Par exemple, de telles techniques sont basées sur l’utilisation, dans l’empreinte de session, de métadonnées (codecs, langues, résolutions, etc) propres au format du ou des fichiers représentatifs du contenu multimédia. Ces métadonnées peuvent être transportées à l’intérieur (« inband ») ou en dehors (« outband ») du ou des fichiers représentatifs du contenu multimédia, de la source 311 vers l’encapsulateur 321, 322. Les métadonnées « outband » sont par exemple des « manifests » pour le format DASH ou bien des « playlists » pour le format HLS. Elles sont fournies en parallèle au client final, soit par la même technique de distribution que le contenu multimédia (une session dédiée du protocole de transport, ici ROUTE), soit par une autre technique (par exemple mis à disposition par un lien unicast). Comme illustré en , si l’on considère le format DASH, le « manifest » porte des métadonnées dans ses différentes parties. Ces métadonnées sont par exemple : dans la partie « AdaptationSet » du manifest DASH : « contentType », « id », « mimeType », « lang », « maxHeight », « minHeight », « maxWidth », « minWidth », dans la partie « Role » : « value », dans la partie « Representation » : « codecs », « id », « width », « height ». Il suffit alors d’extraire au moins l’une des métadonnées mentionnées pour déterminer l’empreinte de session, éventuellement en combinant cette information à une autre information comme un type de composante ou un nom de fichier. On note que comme ces métadonnées sont fournies en parallèle des fichiers représentatifs du contenu multimédia, il est possible de déterminer a priori les empreintes de session, et identifiants de session correspondants, avant même que l’encapsulateur n’ait reçu ces fichiers. Dans ce cas, l’empreinte de session peut notamment être déterminée par la source de contenus. Les métadonnées « inband » sont quant à elle insérées à l’intérieur même du ou des fichiers représentatifs du contenu multimédia. Il est donc nécessaire de recevoir le fichier, ou à tout le moins la partie incluant ces métadonnées, avant de pouvoir déterminer l’empreinte de session, et par suite l’identifiant de session. En considérant à nouveau le format DASH, on note que le contenu multimédia peut être divisé en fichiers dits « d’initialisation » et de « segment ». Les métadonnées utilisées pour déterminer l’empreinte de session peuvent reposer dans ce cas uniquement sur le fichier d’initialisation, tout en garantissant une unicité d’identifiant de session. Par ailleurs, on note que différents formats de fichiers représentatifs du contenu multimédia (par exemple DASH, MPU, etc.) sont alignés sur le format ISOBMFF, qui décrit l’organisation du ou des fichiers binaires représentatifs du contenu multimédia. La structure d’un fichier au format ISOBMFF, tel que décrit dans la norme ISO IEC 14496-12, est organisée en un empilement de boite ou « box ». La structure « emboitée » d’un fichier (au format ISOBMFF, DASH, MPU, etc.) est par exemple illustrée en . On y trouve des « boxes » obligatoires et d’autres optionnelles, suivant les formats. En analysant ces boxes, on peut extraire des métadonnées qui peuvent être utilisées pour déterminer une empreinte de session. Par exemple, ces métadonnées sont : ftyp > compatible_brands track > mdia > mdhd > languageString track > mdia > hdlr > handler track > mdia > minf > stbl > stsd (sous-boite spécifique à chaque type de contenu). Il suffit alors d’extraire au moins l’une des métadonnées mentionnées pour déterminer l’empreinte de session, éventuellement en combinant cette information à une autre information comme un type de composante ou un nom de fichier. La illustre notamment l’extraction de la métadonnée « handler ». Une fois l’empreinte de session obtenue, on peut déterminer l’identifiant de session correspondant, à renseigner dans le champ TSI. Par exemple, une fonction de hachage est appliquée à l’empreinte de session obtenue, délivrant l’identifiant de session. Si l’on considère le protocole ROUTE, la valeur de l’identifiant de session doit tenir sur au plus 32 bits. En variante, les empreintes de session possibles sont dénombrées, et chaque empreinte de session est affectée à une valeur, destinée à être insérée dans le champ TSI. Une liste statique peut ainsi être définie, par l’encapsulateur ou par une entité tierce, appartenant ou non à la chaine de distribution. Par exemple, pour limiter le nombre d’empreintes de session, il est possible de lister les valeurs des métadonnées supportées par le standard de diffusion cible. Par exemple, pour l’ATSC 3.0, la liste des codecs actuellement supportés sont : vidéo : « hev1 », « hev2 », « hvc1 », « hvc2 », « lhv1 » ou « lhe1 », audio : « ac-4 », « mhm1 » ou « mhm2 ». B.2 Identifiant d’objet Concernant l’identifiant d’objet, et donc la valeur portée par le champ TOI, toutes les techniques décrites précédemment peuvent être mises en œuvre pour déterminer une empreinte d’objet associée à un fichier représentatif du contenu multimédia. Certaines techniques basées sur le nom ou le contenu binaire du ou des fichiers représentatifs du contenu multimédia pour la détermination d’une empreinte d’objet sont dites « agnostiques ». Notamment, la détermination d’un identifiant d’objet par application d’un pattern sur une empreinte d’objet correspondant au nom (ou une partie du nom) d’un fichier représentatif du contenu multimédia est similaire à celle décrite dans la partie « identifiant de session » pour le protocole ROUTE. De même, la détermination d’un identifiant d’objet par application d’une fonction (par exemple une fonction de hachage) sur une empreinte d’objet correspondant à un contenu binaire d’un fichier est similaire à celle décrite dans la partie « identifiant de session » pour le protocole ROUTE. On note par ailleurs que le protocole ROUTE défini plusieurs modes de livraison du contenu : « file », « entity », « unsigned package », « signed package ». Ce mode de livraison peut avoir un impact sur la valeur du champ TOI. Comme pour l’empreinte de session, d’autres techniques pour la détermination d’une empreinte d’objet sont dites « non agnostiques ». Par exemple, de telles techniques sont basées sur l’utilisation, pour construire l’empreinte d’objet, de métadonnées (codecs, langues, résolutions, etc) propres au format du ou des fichiers représentatifs du contenu multimédia. Ces métadonnées peuvent être transportées à l’intérieur (« inband ») ou en dehors (« outband ») du fichier binaire, de la source 311 vers l’encapsulateur 321, 322. Dans le cas « outband », il est souhaitable de générer en parallèle les métadonnées pour chaque objet. Cela peut toutefois se révéler coûteux en termes de capacité réseau. Dans le cas « inband », on peut extraire ces métadonnées de façon similaire à celle décrite dans la partie « identifiant de session » pour les formats reposant sur le standard ISOBMFF. Il est à noter dans le cas du format DASH, les métadonnées utilisées pour déterminer l’empreinte d’objet peuvent reposer uniquement sur les fichiers de segments. Par exemple, ces métadonnées pour l’empreinte d’objet sont : moof > mfhd > sequence_number sidx > referenced_size sidx > subsegment_duration Il suffit alors d’extraire au moins l’une des métadonnées mentionnées pour déterminer l’empreinte d’objet, éventuellement en combinant cette information à une autre information comme un nom de fichier. La illustre notamment l’extraction de la métadonnée « sequence_number ». Une fois l’empreinte d’objet obtenue, on peut déterminer l’identifiant d’objet correspondant, à renseigner dans le champ TOI. Par exemple, une fonction de hachage est appliquée à l’empreinte d’objet obtenue, délivrant l’identifiant d’objet. Si l’on considère le protocole ROUTE, la valeur de l’identifiant d’objet doit tenir sur au plus 32 bits. En variante, les empreintes d’objet possibles sont dénombrées, et chaque empreinte d’objet est affectée à une valeur, destinée à être insérée dans le champ TOI. 5.2.3 Mise en œuvre pour le protocole FLUTE On présente ci-après un exemple de mise en œuvre de l’invention lorsque le protocole de transport utilisé est le protocole FLUTE. Comme le protocole ROUTE, le protocole FLUTE permet de transporter tout type de fichier, temps réel ou non, et opère au niveau protocolaire sur les couches IP/UDP (et potentiellement RTP). Bien que plus ancien, il est toujours utilisé dans plusieurs normes de diffusion : 3GPP, DVB-MABR. Il existe deux versions du protocole FLUTE reposant sur des documents standardisés RFC : RFC 3926 pour la version 1 et RFC 6726 pour la version 2. Les normes de diffusion citées ci-dessus utilisent la version 1. La version 1 de FLUTE dérive des protocoles LCT (RFC 3451) et ALC (RFC 3450) ; tandis que la version 2 dérive des protocoles LCT (RFC 5651), ALC (RFC 5775). Quel qu’en soit la version, l’entête d’encapsulation reprend ainsi un entête LCT suivi d’un entête d’utilisation de codes correcteurs d’erreur (FEC). Il s’en suit la charge utile du paquet, reprenant une partie du fichier binaire à encapsuler. La structure de l’entête d’un paquet FLUTE est rappelée dans le tableau ci-après : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Entête UDP (« UDP header ») Entête LCT par défaut (« Default LCT header ») avec TOI = 0 Extension de l’entête LCT (« LCT Header Extensions (EXT_FDT, EXT_FTI, etc.) Entête d’utilisation de FEC (« FEC Payload ID ») Charge utile FLUTE (« FLUTE Payload : Encoding symbols ») … Le détail de l’entête LCT pour la version 1 est représenté ci-après : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 V C r S O H T R A B HDR_LEN Codepoint (CP) Information de contrôle de congestion (CCI, longueur = 32*(C+1) bits) … Identifiant de session de transport (TSI, longueur = 32*S+16*H bits) … Identifiant d’objet de transport (TOI, longueur = 32*O+16*H bits) … Instant courant de l’émetteur (« Sender current time », SCT si T=1) Instant résiduel attendu (« Expected Residual Time »,ERT si R=1) Extensions de l’en-tête (si applicable) … Le détail de l’entête LCT pour la version 2 est représenté ci-après : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 V C PSI S O H Res A B HDR_LEN Codepoint (CP) Information de contrôle de congestion (CCI, longueur = 32*(C+1) bits) … Identifiant de session de transport (TSI, longueur = 32*S+16*H bits) … Identifiant d’objet de transport (TOI, longueur = 32*O+16*H bits) … Extensions de l’en-tête (si applicable) … Comme le protocole ROUTE, le protocole FLUTE repose sur l’utilisation des champs TSI (« Transport Session Identifier ») et TOI (« Transport Object Identifier ») – champs ‘S’ = ‘1’ et ‘O’ != ‘00’ mais ne fixe pas leur taille, qui peut donc être supérieure ou égale à 32 bits. De façon similaire au protocole ROUTE, le champ TSI peut être utilisé pour transporter un identifiant de session et le champ TOI peut être utilisé pour transporter un identifiant d’objet. L‘identifiant de session et/ou l’identifiant d’objets peuvent être déterminés comme décrit précédemment. On a décrit ci-dessus des exemples de mise en œuvre pour les protocoles ROUTE et FLUTE. Comme indiqué, une technique similaire peut être adoptée pour d’autres protocoles, comme les protocoles MMT, QUIC Multicast, NORM, HLS, etc. 5.3 Structure simplifiée d’un encapsulateur On présente finalement, en relation avec la , la structure simplifiée d’un encapsulateur selon au moins un mode de réalisation décrit ci-dessus. Un tel encaspulateur comprend au moins une mémoire 141 comprenant une mémoire tampon, au moins une unité de traitement 142, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 143, mettant en œuvre des étapes du procédé de distribution d’un contenu multimédia selon au moins un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 143 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 142. Le processeur de l’unité de traitement 142 met en œuvre des étapes du procédé de distribution d’un contenu multimédia décrit précédemment, selon les instructions du programme d’ordinateur 143, pour : obtenir ledit contenu multimédia, obtenir au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia et/ou d’au moins un identifiant d’objet représentatif d’au moins un identifiant associé à au moins un fichier représentatif dudit contenu multimédia, générer un flux de transport comprenant des paquets de transport construits à partir dudit contenu multimédia, lesdits paquets de transport portant un entête spécifique à un protocole de transport considéré, ledit entête comportant au moins un champ d’identification de session portant ledit au moins un identifiant de session et/ou au moins un champ d’identification d’objet portant ledit au moins un identifiant d’objet. Procédé de distribution d’un contenu multimédia, mis en œuvre dans un encapsulateur (321, 322) d’un réseau de distribution destiné à mettre en œuvre au moins deux encapsulateurs, caractérisé en ce qu’il met en œuvre les étapes suivantes : obtention (51) dudit contenu multimédia, obtention (52) d’au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia et/ou d’au moins un identifiant d’objet représentatif d’au moins un identifiant associé à au moins un fichier représentatif dudit contenu multimédia, génération (53) d’un flux de transport comprenant des paquets de transport construits à partir dudit contenu multimédia, lesdits paquets de transport portant un entête spécifique à un protocole de transport considéré, ledit entête comportant au moins un champ d’identification de session portant ledit au moins un identifiant de session et/ou au moins un champ d’identification d’objet portant ledit au moins un identifiant d’objet. Procédé selon la revendication 1, caractérisé en ce que ledit au moins un identifiant associé audit contenu multimédia appartient au groupe comprenant : un type dudit contenu multimédia, au moins une partie d’un nom dudit au moins un fichier représentatif dudit contenu multimédia, des métadonnées associées audit au moins un fichier représentatif dudit contenu multimédia, une combinaison d’au moins deux informations parmi ledit type, ladite au moins une partie d’un nom, et lesdites métadonnées. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ledit identifiant de session appartient au groupe comprenant : ledit au moins un identifiant associé audit contenu multimédia, une fonction dudit au moins un identifiant associé audit contenu multimédia, une valeur. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ledit au moins un identifiant associé audit au moins un fichier appartient au groupe comprenant : au moins une partie d’un nom dudit au moins un fichier, au moins une partie d’un contenu binaire dudit au moins un fichier, des métadonnées associées audit au moins un fichier, une combinaison d’au moins deux informations parmi ladite au moins une partie d’un nom, ladite au moins une partie d’un contenu binaire et desdites métadonnées. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ledit identifiant d’objet appartient au groupe comprenant : ledit au moins un identifiant associé audit au moins un fichier, une fonction dudit au moins un identifiant associé audit au moins un fichier, une valeur. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit protocole de transport appartient au groupe comprenant : le protocole FLUTE, le protocole ROUTE, le protocole MMT, le protocole QUIC multicast, le protocole NORM, le protocole HLS. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit protocole de transport considéré est le protocole FLUTE ou le protocole ROUTE, et en ce que ledit champ d’identification de session est le champ « Transport Session Identifier » de l’entête LCT, et ledit champ d’identification d’objet est le champ « Transport Object Identifier » de l’entête LCT. Encapsulateur d’un réseau de distribution destiné à mettre en œuvre au moins deux encapsulateurs pour la distribution d’un contenu multimédia, comprenant au moins un processeur configuré pour : obtenir ledit contenu multimédia, obtenir au moins un identifiant de session représentatif d’au moins un identifiant associé audit contenu multimédia et/ou d’au moins un identifiant d’objet représentatif d’au moins un identifiant associé à au moins un fichier représentatif dudit contenu multimédia, générer un flux de transport comprenant des paquets de transport construits à partir dudit contenu multimédia, lesdits paquets de transport portant un entête spécifique à un protocole de transport considéré, ledit entête comportant au moins un champ d’identification de session portant ledit au moins un identifiant de session et/ou au moins un champ d’identification d’objet portant ledit au moins un identifiant d’objet. Système de distribution mettant en œuvre au moins deux encapsulateurs selon la revendication 8, délivrant chacun un flux de transport, tel que ledit au moins un champ d’identification de session et/ou ledit au moins un champ d’identification d’objet des différents flux de transport sont alignés. Système selon la revendication 9, caractérisé en ce que lesdits encapsulateurs mettent en œuvre des protocoles de transport différents. Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur.