Brevet FR3094167A1 — publié le 20200925

Description Titre de l'invention : Procédé de gestion de contenus multimédia et dispositif pour la mise en oeuvre du procédé Domaine et contexte de l'invention [0001] La présente invention se rapporte au domaine de la distribution de données sur un réseau de télécommunication. En particulier, elle se rapporte à la distribution de contenus multimédia (audio et/ou vidéo, sous-titres, données, etc.), et notamment à la distribution en temps réel. [0002] 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 (FAT)) 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 Ten-estre (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 »). 100031 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. 100041 Les infrastructures de distribution sont ainsi aujourd'hui doublées, une pour le broadcast traditionnel et une (au moins) pour la distribution OTT. 100051 Afin d'adresser les services de distribution de contenus multi-écrans, divers protocoles ont été développés : Apple HLS (HTTP Live Streaming), Microsoft Smooth Streaming (MSS), Adobe HTTP Dynamic Streaming (HDS), MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH). Tous ces protocoles sont basés sur le concept de streaming adaptatif http (en anglais HAS, pour « HTTP Adaptive Streaming »). 2 [0006] 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). [0007] 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. [0008] 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 Del ivcry 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. [0009] 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. [0010] La mise en oeuvre d'une lecture de contenu multimédia « live », c'est-à-dire distribué en mode dynamique , sur la base du manifeste associé présente toutefois des limitations, eu égard à certains nouveaux cas d'usage impliquant un basculement d'un premier contenu live en cours de lecture vers un deuxième contenu. En effet, les mécanismes existants permettant d'effectuer un basculement d'un premier contenu multimédia vers un deuxième contenu multimédia ne permettent pas de gérer de manière satisfaisante ces nouveaux cas d'usage. [0011] L'invention a pour but d'améliorer la situation. [0012] Selon un premier aspect, un procédé de gestion de contenus multimédia est proposé. Le procédé comprend, dans un ou plusieurs modes de réalisation: obtenir un premier 3 ensemble de métadonnées de description de contenus multimédia décrivant un premier contenu multimédia distribué en mode dynamique ; sur lecture dans le premier ensemble de métadonnées d'un indicateur de basculement vers un deuxième ensemble de métadonnées de description de contenus multimédia, lire dans le premier ensemble de métadonnées un indicateur de stockage d'adresse ; et stocker dans une mémoire une adresse du premier ensemble de métadonnées. [0013] Le procédé proposé permet avantageusement d'utiliser un indicateur de basculement inséré dans un ensemble de métadonnées pour gérer les cas d'usage de lecture de contenus multimédia impliquant un premier basculement d'un contenu distribué en live vers un deuxième contenu distribué en live suivi d'un deuxième basculement pour retourner, depuis le deuxième contenu, à la lecture du premier contenu. Ces cas d'usage, parfois dénommés « décrochage », ne peuvent pas être mis en oeuvre selon certaines spécifications, comme par exemple la spécification du standard ISO/IEC 23009-1 (« Information technology - Dynamic adaptative streaming over http (DASH) - Part 1 : Media presentation description and segment formats », 3ème édition). En effet, la spécification DASH prévoit l'insertion dans un premier manifeste correspondant à un premier contenu distribué en live d'un descripteur de chainage de manifeste, qui permet de provoquer un basculement d'un client DASH en lecture du premier manifeste vers un deuxième manifeste, le deuxième manifeste correspondant à un deuxième contenu distribué en live. Mais une fois le basculement effectué, le client DASH ne sait pas revenir vers le premier manifeste, et par conséquent ne sait plus accéder au premier contenu live. Le procédé proposé répond avantageusement à cette limitation, en organisant une sauvegarde en mémoire d'une adresse à laquelle le client DASH pourra accéder au premier manifeste, sur lecture d'un descripteur de chainage de manifeste. [0014] Le procédé proposé convient particulièrement bien, bien que de façon non limitative, pour la lecture, par un équipement terminal de lecture, de contenus multimédia distribués en live selon un schéma de type MPEG DASH, HLS, HDS, MSS. ou HAS. Mais il convient aussi pour la lecture de contenus multimédia distribués en live selon tout schéma dans lequel cette lecture est effectuée en utilisant des ensemble de métadonnées de description de contenus multimédia correspondant à des contenus multimédia distribués en live. [0015] Le procédé proposé pourra avantageusement être mis en oeuvre dans tout dispositif configuré pour la lecture de contenus multimédia, sur la base d'un ensemble de métadonnées de description de contenus multimédia multimédia, par exemple conformément aux standards MPEG DASH, HLS, HDS, MSS, ou HAS, tels que, de façon non limitative, tout ordinateur, smartphone, équipement utilisateur, lecteur vidéo, terminal de lecture vidéo, tablette, etc. [0016] Dans un ou plusieurs modes de réalisation, le deuxième ensemble de métadonnées pourra décrire un deuxième contenu multimédia, éventuellement lui aussi distribué en mode dynamique. [0017] Dans un ou plusieurs modes de réalisation, l'indicateur de basculement du premier ensemble de métadonnées de description de contenus multimédia vers le deuxième ensemble de métadonnées de description de contenus multimédia peut comprendre un indicateur de chainagc d'ensembles de métadonnées. [0018] Dans un ou plusieurs modes de réalisation, l'indicateur de basculement du premier ensemble de métadonnées de description de contenus multimédia vers le deuxième ensemble de métadonnées de description de contenus multimédia peut comprendre une adresse du deuxième ensemble de métadonnées. [0019] Dans un ou plusieurs modes de réalisation, dans lequel l'adresse stockée en mémoire peut correspondre à celle à partir de laquelle le premier ensemble de métadonnées a été téléchargée depuis un serveur. [0020] Dans un ou plusieurs modes de réalisation, le procédé peut comprendre en outre : basculer en lecture du premier ensemble de métadonnées de description de contenus multimédia vers le deuxième ensemble de métadonnées de description de contenus multimédia indiqué par l'indicateur de basculement. [0021] Dans un ou plusieurs modes de réalisation, le procédé peut comprendre en outre : sur lecture dans le deuxième ensemble de métadonnées d'un indicateur de retour, basculer en lecture du deuxième ensemble de métadonnées vers le premier ensemble de métadonnées en utilisant l'adresse du premier ensemble de métadonnées. [0022] Ainsi, le procédé proposé permet avantageusement, dans un ou plusieurs modes de réalisation, de provoquer le basculement retour d'un terminal de lecture depuis un deuxième ensemble de métadonnées correspondant à un deuxième contenu vers un premier ensemble de métadonnées correspondant à un premier contenu live. [0023] Dans un ou plusieurs modes de réalisation, les premier et deuxième ensembles de métadonnées sont des manifestes au format « Dynamic adaptative streaming over http », DASH. [0024] Dans un ou plusieurs modes de réalisation, l'indicateur de basculement et l'indicateur de stockage d'adresse sont au format « Dynamic adaptative streaming over http », DASH. [0025] Dans un ou plusieurs modes de réalisation, l'indicateur de retour est au format « Dynamic adaptative streaming over http », DASH. [0026] Dans un ou plusieurs modes de réalisation, l'indicateur de stockage d'adresse comprend un descripteur Uniform Resource Name, URN, de type : um:mpeg:dash:origin-set ou um:mpeg:dash:origin-set:2019. [0027] Dans un ou plusieurs modes de réalisation, l'indicateur de retour comprend un des- criptcur Uniform Resource Name, URN, de type : urn:mpcg:dash:origin-back ou : urn:mpcg:dash:origin-back:2019. [0028] Selon un deuxième aspect, il est proposé un dispositif de lecture de contenu multimédia, comprenant un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configure pour la mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation. [0029] Selon un autre aspect, il est proposé un premier ensemble de métadonnécs de des- cription de contenus multimédia décrivant un premier contenu multimédia distribué en mode dynamique comprenant un indicateur de stockage d'adresse pour le stockage en mémoire d'une adresse du premier ensemble de métadonnées par un dispositif utilisant le premier ensemble de métadonnécs. [0030] Selon un autre aspect, il est proposé un deuxième ensemble de métadonnécs de des- cription de contenus multimédia décrivant un deuxième contenu multimédia comprenant un indicateur de retour pour le basculement en lecture, par un dispositif utilisant le deuxième ensemble de métadonnécs, vers un premier ensemble de métadonnées de description de contenus multimédia sur la base d'une adresse du premier ensemble de métadonnécs stockée en mémoire par un dispositif utilisant le premier ensemble de métadonnécs. [0031] Selon un autre aspect, il est proposé un procédé de gestion de contenus multimédia qui comprend, dans un ou plusieurs modes de réalisation: obtenir un premier ensemble de métadonnées de description de contenus multimédia décrivant un premier contenu multimédia distribué en mode dynamique ; et sur lecture dans le premier ensemble de métadonnées d'un indicateur de stockage d'adresse, stocker dans une mémoire une achesse du premier ensemble de métadonnées. [0032] Selon un autre aspect, il est proposé un procédé de gestion de contenus multimédia qui comprend, dans un ou plusieurs modes de réalisation: obtenir un deuxième ensemble de métadonnées de description de contenus multimédia décrivant un deuxième contenu multimédia distribué en mode dynamique et sur lecture dans le deuxième ensemble de métadonnées d'un indicateur de retour vers un premier ensemble de métadonnées de description de contenus multimédia, basculer en lecture vers le premier ensemble de métadonnées sur la base d'une adresse du premier ensemble de métadonnées stockée dans une mémoire. [0033] Selon un autre aspect, il est proposé un programme d'ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation lors de l'exécution dudit programme par le processeur, ainsi qu'un ensemble de données représentant, par exemple par voie de compression ou d'encodage, ledit programme d'ordinateur. 6 100341 Un autre aspect concerne un support de stockage non-transitoire d'un programme exécutable par ordinateur, comprenant 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 à gérer un contenu multimédia selon un ou plusieurs modes de réalisation du procédé proposé. Brève description des dessins [0035] D'autres particularités et avantages de la présente invention apparaîtront dans la des- cription ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels : Fig. 1 [0036] [fig.1] illustre un exemple d'infrastructure de distribution selon un ou plusieurs modes de réalisation. Fig. 2a [0037] [fig.2a] illustre un exemple d'ensemble de métadonnées de description de contenus multimédias (ou manifeste). Fig. 2b [0038] [fig.2b] illustre un exemple d'ensemble de métadonnées de description de contenus multimédias (ou manifeste). Fig. 3 [0039] [fig.3] présente le procédé de calcul du segment à télécharger dans le cas d'un contenu multimédia distribué en mode dynamique. Fig. 4 [0040] [fig.4] illustre le procédé proposé selon un ou plusieurs modes de réalisation. Fig. 5 [0041] [fig.5] illustre le procédé proposé selon un ou plusieurs modes de réalisation. Fig. 6a [0042] [fig.6a] illustre un exemple d'ensemble de métadonnées de description de contenus multimédias (ou manifeste) selon un ou plusieurs modes de réalisation. 7 Fig. 6b 100431 Ifig.6b1 illustre un exemple d'ensemble de métadonnées de description de contenus multimédias (ou manifeste) selon un ou plusieurs modes de réalisation. Fig. 6e [0044] [lig.6c1 illustre un exemple de chainaee d'ensembles de métadonnées de description de contenus multimédias (ou manifeste) selon un ou plusieurs modes de réalisation. Fig. 7 [0045] [fig.7] illustre un exemple d'architecture de dispositif pour la mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation. Description détaillée [0046] Dans la description détaillée ci-après de modes de réalisation du procédé, 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. [0047] La présente description fait référence à des fonctions, moteurs, unités, modules, pla- teformes, et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, moteurs, modules, plateformes, unités et diagrammes décrits peut être mis en oeuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué («firmwme»), ou de «middleware»), microcode, ou toute combinaison de ces derniers. Dans le cas d'une mise en oeuvre sous forme logicielle, les fonctions, moteurs, unités, modules et/ou illustrations de diagrammes peuvent, être mis en oeuvre 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 oeuvre de ces fonctions. 100481 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 8 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. [0049] 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, microondcs), 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. [0050] 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. [0051] 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 9 des logiciels applicatifs en support des services et fonctions fournies par le serveur. Un dispositif informatique peut être configure pour envoyer et recevoir des signaux, par réseau(x) de transmission sans-fil et/ou filaire, ou peut être configure 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 niasse, une ou plusieurs al imentation(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. [0052] Par contenu multimédia, on entend dans la présente description tout contenu audio et/ou vidéo, sous-titres, données, audiovisuel, musique, son, image et interface graphique interactive, et toute combinaison de ces types de contenu. [0053] 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 inter-opé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. [0054] Les ternies «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 simplcx 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. [0055] Les termes «application» ou «programme applicatif» (AP) et leurs variantes («app», «webapp», etc.) tels qu'utilisés dans la présente description correspondent à tout outil qui fonctionne et est opéré au moyen d'un ordinateur, pour fournir ou exécuter une ou plusieurs fonction(s) ou tâche(s) pour un utilisateur ou un autre programme applicatif. Pour interagir avec un programme applicatif, et le contrôler, une interface utilisateur peut être fournie sur l'équipement sur lequel le programme applicatif est mis en oeuvre. Par exemple, une interface graphique (en anglais, «graphical user interface» ou GUI) peut être générée et affichée sur un écran de l'équipement utilisateur, ou une interface utilisateur audio peut être restituée à l'utilisateur en utilisant un haut-parleur, un casque ou une sortie audio. [0056] Les termes « contenu multimédia » tel qu'utilisés dans la présente description cor- respondent à tout contenu de type audio et/ou vidéo ou audiovisuel. [0057] 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 uti- 11 lisatcurs par un service de vidéo à la demande (YOD). [0058] Dans la présente description, les ternies « 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. [0059] Dans la présente description, les ternies « 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 oeuvre 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, configure 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 oeuvre 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. [0060] La figure 1 illustre un exemple d'architecture de système de distribution (1) de contenus multimédia, dans lequel le procédé proposé peut être mis en oeuvre. La figure 1 montre une tête de réseau de distribution vidéo (2) comprenant une unité d'encodage vidéo (4) qui reçoit en entrée des contenus à encoder (« contribution ») (3), et délivre à une unité de mise en forme (5) (« packager ») des flux encodés dits « flux élémentaires ». Comme illustré sur la figure 1, 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). 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. [0061] Les flux encodés (flux élémentaires) délivrés par l'unité d'encodage vidéo (4) à l'unité de mise en forme sont découpés en deux séquences de segments successifs, respectivement audio et vidéo, qui sont généralement de durée fixe (typiquement de 12 quelques secondes) par l'unité dc mise en forme (5), 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, ou manifeste (en anglais « manifest »), est aussi généré par l'unité de mise en forme. Il s'agit typiquement d'un fichier, par exemple au format XML, indiquant les caractéristiques de chaque profil et les segments disponibles correspondant au contenu. [0062] Ces manifestes et les segments associés sont fournis par l'unité de mise en forme (5) à un serveur de contenus (6) (« Origin Server » sur la figure 1), puis stockés sur des serveurs de distribution de contenu (8a. Rb), appelés « CDN » (de l'anglais « Content Delivery Network »), fournissant des capacités de cache qui permettent d'améliorer la qualité des services fournis aux utilisateurs, et dc minimiser les temps d'accès et la latence pour la visualisation dc contenus par des terminaux de lecture. [0063] Les contenus stockés dans les serveurs CDN (8a, Rb) sont accessibles en lecture à des terminaux (10a, 10b, 10e) utilisateurs, par le biais d'une plateforme de services (7) pour la distribution des contenus. Les clients installés dans les terminaux (10a, 10b, 10e) peuvent accéder aux contenus stockés sur les serveurs CDN par l'intermédiaire d'un ou plusieurs réseaux dc communication de données, comme par exemple le réseau Internet (9), comme illustré sur la figure. [0064] La figure 2a illustre un exemple de contenu de fichier XML correspondant à un manifeste utilisant le format DASH (ou MPEG-DASH). Un manifeste de ce type présente une arborescence de conteneurs XML imbriqués, comme illustré par la figure 2a. Bien que la présente description fournisse des exemples de modes de réalisation basés sur le format DASH spécifié dans la troisième édition du document ISO/IEC 23009-1 « Information Technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1 : Media presentation description and segment formats », l'homme du métier peut se rendre compte que les procédés proposés ne sont pas limités à un type ou un format particulier de manifeste (ou d'ensemble de métadonnées de description de contenus multimédia(s) multimédia), et qu'ils s'appliquent à tous types de manifeste, tels que des manifestes utilisant d'autres protocoles et formats de distribution OTT, comme par exemple les protocoles et formats HLS, MSS et HDS mentionnés ci-dessus. [0065] Le manifeste DASH illustré sur la figure 2a présente une structure hiérarchique organisée selon l'arborescence suivante: [0066] Un élément racine du document (de l'anglais Media Presentation Description, MPD) contient les attributs applicables à l'ensemble des éléments du document (les autres éléments étant parfois dénommés éléments « enfants »). [0067] La racine « MPD » peut, outre des éléments « enfants », définir des valeurs d'attributs, parmi lesquels les attributs suivants qui sont relatifs à la distribution d'un 13 contenu live : [0068] L'attribut « type » définit le type de distribution du contenu: « static » pour les contenus distribués en mode statique (typiquement les contenus distribués selon un service de Vidéo à la Demande (VOD)) et « dynamic » pour les contenus distribués en mode dynamique. [0069] L'attribut « AvailabilityStartTi me », se rapportant au mode de distribution dynamique, définit la date (par exemple au format temps universel coordonné (en anglais « UTC », pour « Coordinatcd Univcrsal Timc »)) de disponibilité du premier segment généré pour le service courant. Cette information peut être utilisée pour indiquer l'heure de démarrage du service, de manière à être utilisée par un terminal de lecture comme point d'ancrage temporel du début du service. [0070] L'attribut « PublishTime » indique une date de génération du manifeste et de sa pu- blication sur le réseau CDN. Cette information permet d'enregistrer différentes versions d'un même manifeste correspondant à des publications successives, afin de détecter des changements intervenus d'une publication à l'autre. [0071] L'attribut « AvailabilityEndTime » indique une date de génération du segment le plus ancien encore disponible. [0072] L'attribut « MinimumUpdatePeriod » définit la période la plus courte entre des changements potentiels dans le MPD. La valeur de cet attribut peut être utilisée par le terminal de lecture du contenu pour configurer une fréquence à laquelle il télécharge le manifeste, étant informé du fait que le manifeste sera mis à jour par l'unité de mise en forme au moins à la fréquence indiquée par cet attribut. [0073] L'attribut « MinBufferTime », obligatoire dans l'exemple de format illustré par la Figure 2a, définit une durée commune utilisée dans la définition des débits des représentations. [0074] L'attribut « TimeShiftBufferDepth » définit la durée du plus petit butter de décalage temporel pour toutes les représentations du manifeste, garantissant la disponibilité des segments pour les distributions de type dynamique. Sa valeur indique la période dans le passé pour laquelle le contenu associé au manifeste, distribué en mode dynamique, est disponible sur le serveur CDN. Cette valeur peut par exemple être égale à 1 minute, auquel cas le lecteur peut revenir dans le passé (du contenu « live ») pendant une minute, ou récupérer une minute de contenu live dans le cas où l'utilisateur utilise la fonction « pause » pour interrompre la lecture du contenu live. [0075] L'attribut « SuggestedPresentationDelay » définit un décalage fixe dans le temps qui peut être appliqué lors de la présentation de chaque access unit. Ce paramètre permet de se caler le plus près possible de la limite du contenu live, pour s'assurer que tous les terminaux de lecture qui lisent le même contenu live vont le lire au même endroit. Par exemple, on peut configurer la lecture de manière à revenir 4 secondes dans le passé 14 pour se donner une marge de sécurité par rapport au déroulement du contenu live. [0076] L'attribut « UTCTiming » fournit une horloge commune entre l'unité de mise en forme et le terminal de lecture (ou lecteur vidéo). Il permet d'indiquer au terminal un moyen permettant de récupérer une horloge synchronisée avec le serveur de contenus. [0077] Des éléments « enfants », sous forme de conteneurs éventuellement imbriqués les uns dans les autres, peuvent en outre être inclus dans le manifeste pour préciser les fichiers accessibles par l'intermédiaire du manifeste. En référence à la figure 2a, ces éléments « enfants » peuvent être : [0078] Un élément de type « Period », décrivant un intervalle de temps, borné ou non dans le temps. Un ou plusieurs attributs peuvent être fournis pour un élément de type « Period », parmi lesquels un attribut (« id ») d'identification de période (« id= « P0» » sur la figure 2), un attribut (« start ») de temps de démarrage de période (« start, « PTOS » » sur la figure 2), et un attribut (« duration ») de durée de période (non présent pour une période ouverte, c'est-à-dire non encore terminée). La valeur de r attribut de temps de démarrage de période (0 secondes dans l'exemple illustré sur la figure 2a) pourra être combinée avec la valeur de l'élément « availabilityStartTime » décrit ci-dessus) [0079] Chaque élément enfant de type « Period » peut lui-même contenir des éléments enfants. Par exemple, comme illustré sur la figure 2a, un élément de type « Period » peut contenir deux éléments enfants de type « AdaptationSet » correspondant chacun à un type de contenu. [0080] L'élément de type « AdaptationSet » est un conteneur qui permet de décrire des contenus disponibles en fonction de leur type. II permet de regrouper des éléments concernant la même composante d'un contenu multimédia de types audio, vidéo ou sous-titres, mais encodés avec des paramètres (débits, résolutions, taux d'image (en anglais « fi-amerate »), taux (l'échantillonnage (en anglais « sample rate »)) différents. Dans l'exemple de la figure 2, un seul profil d'encodage est disponible, et ce profil est décrit pour sa composante vidéo (contentType="video" id="0" maxErameRate="25" maxHeight="1080" maxWidth="1920" mimeType="video/mp4" minFrameRate="25" minHeight="1080" minWidth="1920" par="16:9" segmentAlignment="true" startWithSAP="1") et pour sa composante audio (contentType="audio" id="1" lang="und" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1"). Un lecteur vidéo peut ainsi, par exemple, obtenir rapidement les paramètres de profil d'encodage vidéo utilisés pour l'encodage du contenu décrit dans le manifest illustré sur la figure 2 : bande passante, paramètres du codeur vidéo, taux d'images, résolution, format des images, etc. (« bandwidth="4000000" codecs="hev1.2.4.L120.90" frameRate="25" height="1080" id="v1" sar="1:1" width="1920"). [0081] Des paramètres d'encodage peuvent être fournis par l'élément « Representation », qui permet de décrire précisément les paramètres d'encodage et d'accès à une composante du média. [0082] La figure 2b illustre un manifeste au format DASH contenant un indicateur de bas- culement vers un autre manifeste correspondant à un autre contenu sous la forme d'un indicateur de chainage, aussi appelé descripteur de chainage. La spécification ISO/IEC 23009-1 «Information Technology - Dynamic adaptivc streaming over HTTP (DASH) - Part 1 : Media presentation description and segment formats » définit l'insertion d'un indicateur de basculement vers un autre manifeste dans un manifeste au format DASH. [0083] On retrouve dans le manifeste de la figure 2b certains des éléments spécifiés par le standard DASH et décrits ci-dessus. En outre, ce manifeste comprend un indicateur de chainage inséré selon la syntaxe DASH dans un conteneur d'informations supplémentaires (SupplementalProperty) : schemeIdUri="urn:mpeg:dash:mpd-chai ni ng:2016". [0084] Ce descripteur de chainage sera pris en compte par un client DASH qui utilise le manifeste pour accéder à au moins un contenu distribué en mode dynamique lorsqu'il aura terminé de consommer (lire) le contenu correspondant au conteneur d'intervalle de temps : . Lorsque la période de temps correspondant à ce contenu se terminera, le packager recevra un ordre de splice out, ce sur quoi il fermera la période courante en mettant à jour le manifeste courant avec une fin de période dans le conteneur d'intervalle de temps correspondant (dans l'exemple illustré la période (l'identifiant « PO »). [0085] Le client DASH téléchargera le manifeste mis à jour, dans lequel la période (« PO ») sera fermée, par exemple dans le cadre du téléchargement périodique du manifeste courant. Sur lecture du manifeste mis à jour, le client déterminera que la période précédemment courante est fermée, et il poursuivra sa lecture linéaire du manifeste, ce qui le conduira à lire dans le manifeste mis à jour le conteneur d'informations supplémentaires contenant l'indicateur de chainage. Dans l'exemple illustré sur la figure 2b, l'indicateur de chainage comprend un descripteur de chainage (urrEmpeg:dash:mpd-chaining:2016) intégré dans le manifeste comme attribut du conteneur d'informations supplémentaires, et une adresse URL du manifeste cible du basculement (http://.../live2/manifest.mpd). [0086] Sur lecture du descripteur de chainage, le client DASH bascule vers le manifeste cible, sur la base de l'adresse de ce manifeste cible fournie avec le descripteur de chainage. Dans le cas où le manifeste cible correspond à un conteneur distribué en mode dynamique, le client DASH lit cette information dans l'élément « type » du 16 manifeste cible, et reprend la période courante pour le contenu live correspondant. [0087] La figure 3 illustre un exemple de procédé de lecture de contenu live par un client de lecture vidéo (ou un lecteur vidéo). Le procédé illustré utilise certaines des informations décrites ci-dessus pour l'exemple de manifeste illustré sur la figure 2a pour déterminer le segment de données à télécharger pour chaque « AdaptationSet » de la période courante, et ainsi permettre au client de s'accrocher au contenu à lire. [0088] La lecture d'un contenu live mis au format MPEG-DASH est principalement linéaire. Lors de sa connexion au serveur de contenus, le client récupère dans un premier temps le manifeste contenant des informations propres au contenu distribué en mode dynamique (« live »), puis commence la lecture à l'endroit du contenu correspondant à l'heure courante (afin de suivre un événement se déroulant en temps réel (ou live)). Pour cc faire, il détermine la période courante en calculant le temps écoulé depuis la valeur « availabilityStartTi me » indiquée dans le manifeste, puis détermine le numéro du segment « live » dans cette période par le même moyen. [0089] En référence à la figure 3, dans un ou plusieurs modes de réalisation, le client obtient (50) un manifeste correspondant au contenu live à lire, puis se synchronise (51) (52) avec un serveur de contenus multimédia par l'intermédiaire de la valeur de l'attribut « UTCtiming » indiquée dans le manifeste. [0090] A partir de l'attribut « availabil ityStartTi me » et de l'heure courante (« CurrentTime »), le client peut ensuite déterminer (53) le temps écoulé fe() depuis le démarrage du contenu multimédia live. Comme discuté ci-dessus, suivant les conditions d'encodage, un délai (« PresentationTimeOffset ») peut être appliqué (54) sur la transmission (lu contenu multimédia afin de laisser du temps à l'encodeur pour encoder les segments, ce qui conduit à la détermination d'un temps fc() défini par fe() - PresentationTimeOffset. Enfin, en fonction de la taille des segments (« segment duration ») définie dans le manifeste, et d'un paramètre d'échelle de temps («TimeScale »), un index (57) fi() ou un horodatage (56) (« TimeStamp ») ft() du segment de l'heure courante pourra être calculé, selon le type de segment (55). A partir de ces informations, le client peut obtenir (58) une adresse de téléchargement (par exemple une URL ((le l'anglais « Unifonn Resource Locator »)), puis télécharger le segment de l'heure courante du contenu multimédia. Un index du segment de l'heure courante pourra par exemple être obtenu en divisant la valeur fc() par la durée d'un segment (en anglais « segment duration ») divisée par la valeur d'échelle de temps (« timescale ») : fi0=fc()/(segment duration/timescale). Un horodatage du segment de l'heure courante pourra par exemple être obtenu en divisant la valeur fc() par la valeur d'échelle de temps (« timescale ») : ft()=fc()/timescale. [0091] Les valeurs décrites ci-dessus sont fournies par le diffuseur au client par l'intermédiaire du manifeste. Le diffuseur de contenus peut en outre influer sur le com- 17 portement du client par d'autres biais que le manifeste que le client téléchargc, notamment en insérant de la signalisation dans un segment de données. Ainsi, l'insertion d'un marqueur (par exemple sous la forme d'une « box ») spécifique identifié par une balise prédéterminée permet de communiquer au client des messages de contrôle. Par exemple, l'insertion d'une box « ernsg » dans un segment de données permet d'indiquer au client qu'il doit recharger immédiatement le manifeste. Ainsi, un client configure pour la lecture d'un fichier MP4 ou MPEG2 TS (de l'anglais « Transport Stream ») va parcourir (en anglais,