FR 3096203 A1 20201120 FR 1904964 A 20190513 Description Titre de l'invention : PROCEDE DE DIFFUSION DE CONTENUS MULTIMEDIA AVEC UNE FAIBLE LATENCE [0001] La présente invention concerne un procédé de transmission d'un flux multimédia en direct comprenant une séquence de segments, chaque segment étant divisé en fragments multimédia. La présente invention peut s'appliquer aux fichiers vidéo conformes à l'un des standards ISO BMFF (ISO Base Media File Format), SVC (Scalable Video Coding), AVC (Advanced Video Coding), 3GPP (Third Generation Partnership Project), et MVC (Multiview Video Coding), ainsi que tout autre format vidéo similaire. [0002] Lc standard DASH (Dynarnic Adaptive Streaming over HTTP - Hypertext Transfer Protocol) décrit l'utilisation de segments pour transmettre des données multimédia, de tels segments se présentant sous la forme de fichiers associés à une adresse URL (Uniform Source Locator). Chacun de ces segments présente unc structure par exemple définie par le standard ISO BMFF. Un fichier conforme au standard ISO BMFF peut comprendre en outre des données multimédia formatées selon le format CMAF (Common Mcdia Application Format). Ce format peut être utilisé à différentes étapes, notamment lors de la préparation d'un contenu multimédia, lors de la fourniture du contenu, ou au moment de la consommation du contenu par un lecteur de fichiers multimédia. [0003] Lc standard CMAF présente un avantage de réduction de latence. En effet, lorsqu'un encodeur reçoit un contenu multimédia pour générer des segments, il ne peut commencer à envoyer un segment en vue d'être diffusé, avant d'avoir encodé le dernier octet du segment. Cette contrainte introduit une latence minimum égale à la durée d'un segment. En outre, le réseau de distribution de contenus recevant les segments d'un contenu, doit attendre de recevoir le dernier octet d'un segment avant de transmettre le premier octet du segment. De même, un lecteur multimédia exécuté par un équipement d'utilisateur doit attendre d'avoir reçu le dernier octet d'un segment avant de pouvoir commencer à décoder le premier octet du segment. Ainsi des latences multiples de la durée d'un segment peuvent être introduites entre la production du flux multimédia et l'exploitation de ce flux. [0004] Le standard CMAF permet de découper les segments en morceaux (chunks) ras- semblant un nombre entier de trames et pouvant être réduit à une seule trame, dans le cas d'un flux vidéo. Un segment d'un flux vidéo comprend un champ d'entête appelé "moof" et un champ de données appelé "mdat". Le champ "mdat" d'un segment commence par un trame IDR (Instantaneous Decoder Refresh). Chacun des morceaux 2 d'un tel segment comprend un champ d'entête "moof" et un champ de données "mdat" comprenant une partie des données "mdat" du segment. [0005] Ce découpage des segments permet à l'encodeur de transmettre chaque morceau dès qu'il est généré. Cependant, la présence d'un champ d'entête "moof" dans chacun des morceaux entraine une augmentation de la taille globale d'un segment, de l'ordre de 100% pour un segment audio et 2% seulement pour un segment vidéo dans le cas le plus défavorable où chaque morceau de segment contient une seule trame vidéo, un segment vidéo pouvant contenir plusieurs secondes de flux vidéo, soit plusieurs dizaines de trames vidéo. [0006] Classiquement, l'encodeur applique le protocole HTTP 1.1 pour transmettre les morceaux CMAF encodés au serveur chargé de la distribution du contenu. A cet effet, l'encodeur exécute une commande HTTP POST pour chaque segment. Côté équipement de l'utilisateur, le lecteur accède à un fichier manifeste ou à une liste de lecture, décrivant le contenu, calcule le moment auquel il peut commencer à restituer le contenu correspondant, puis émet une requête d'un segment contenant une commande HTTP GET spécifiant le segment correspondant au moment calculé. Dans le cas d'une transmission segment par segment, le lecteur ne peut commencer une restitution qu'à partir du début du dernier segment complet reçu, ce qui entraine un retard par rapport aux segments reçus supérieur à la durée d'un segment. Généralement, le lecteur cherche à stocker plusieurs segments en mémoire tampon pour s'affranchir de problèmes de transmission, ce qui lui permet également de mesurer la bande passante disponible à chaque instant. [0007] Dans le cas d'une transmission par morceau CMAF, le lecteur peut commencer à décoder le premier morceau du dernier segment reçu ou attendre le premier morceau du segment suivant, et le décoder dès sa réception. Le retard est alors de la durée de quelques morceaux de segments et donc inférieur à la durée d'un segment. [0008] Par ailleurs, le service de diffusion (broadcast) ou point-à-multipoint (multicast) de contenu multimédia MBMS (Multimedia Broadcast Multicast Service) a été développé pour distribuer un même contenu multimédia dans les réseaux fixes et mobiles à un grand nombre d'utilisateurs. Ce service permet de transmettre en mode diffusion ou point-à-multipoint un contenu multimédia requis par plusieurs utilisateurs, par exemple au format défini par le standard MPEG-DASH. Ce service peut être disponible dans des cellules d'un réseau mobile dans lesquelles plusieurs utilisateurs ont requis un même contenu multimédia. La transmission des contenus est effectuée en utilisant le standard FLUTE (File Delivery over Unidirectional Transport) consistant à former des fichiers à partir des segments DASH à transmettre, et à transmettre les fichiers sous la forme de paquets, chaque fichier étant associé à une table FDT (File Delivery Table) contenant divers attributs relatifs au segment qu'il contient. Ces attributs peuvent 3 comprendre notamment un identifiant TOI (Transmission Object Identifier) permettant d'identifier un fichier FLUTE, une adresse URL d'où provient le fichier, la taille du fichier, et des informations relatives au codage FEC (Forward Error Correction) du fichier pour le traitement d'erreurs de transmission. Le standard FLUTE est basé sur une application particulière des protocoles ALC/LCT (Asynchronous Laycred Coding / Laycred Coding Transport). Les problèmes de latence décrits précédemment se posent également dans le contexte d'une transmission FLUTE des segments multimédia. Cependant, le standard FLUTE necessitc la connaissance complète d'un segment avant de pouvoir l'encoder et le convertir sous forme de paquets. En particulier, la nécessité de générer une table FDT pour chaque segment renforce le caractère unitaire des segments et conduit à former des segments de taille importante. La mise en oeuvre de telles tables FDT constitue donc un obstacle à l'encontre de la division des segments en morceaux. [0009] Il est donc souhaitable de réduire les latences de transmission de segments multimédia en mode point-à-multipoint ou en mode diffusion, tout en limitant la quantité d'informations à transmettre. [0010] Des modes de réalisation concernent un procédé de diffusion de contenus multimédia vers des équipements d'utilisateur, le procédé comprenant des étapes consistant à : émettre, par un équipement d'utilisateur, une requête d'un segment d'un contenu multimédia, le contenu multimédia étant divisé en segments, recevoir des paquets transmis en mode diffusion ou point-à-multipoint à plusieurs équipements d'utilisateur, les paquets reçus comprenant des données de morceau de segment résultant d'un découpage en morceaux de segment du segment requis, les données de morceau de segment étant associées à une donnée d'identification du segment, une donnée de position du morceau de segment dans le segment et un indicateur de dernier morceau de segment dans le segment requis, et former les morceaux de segment au fur et à mesure de la réception des paquets, les morceaux de segment formés étant exploitables séparément dès leur formation, par une application de lecture de contenu multimédia installée sur l'équipement d'utilisateur. [0011] Des modes de réalisation peuvent également concerner un procédé de diffusion de contenus multimédia par un serveur vers des équipements d'utilisateur, le procédé comprenant des étapes consistant à : recevoir, par un serveur de diffusion de contenus multimédia, des morceaux de segment d'un contenu multimédia, le contenu multimédia étant divisé en segments, et transmettre, par le serveur, en mode diffusion ou point-à-multipoint à plusieurs équipements d'utilisateur, les morceaux de segment dans des paquets, les données de morceau de segment étant associées à une donnée d'identification du segment, une donnée de position du morceau de segment dans le segment et un indicateur de dernier morceau de segment dans le segment. [0012] Selon un mode de réalisation, les paquets transmis à l'équipement d'utilisateur com- prennent un ou plusieurs paquets de données de tables, le procédé comprenant des étapes de formation par l'équipement d'utilisateur, d'une table pour chaque morceau du segment à partir des paquets de données de tables, chaque table comprenant une adresse d'accès au segment, un identifiant du morceau de segment, une taille du morceau de segment et la donnée signalant si le morceau de segment se trouve à la fin du segment. [0013] Selon un mode de réalisation, les paquets transmis à l'équipement d'utilisateur pour un segment comprennent un ou plusieurs paquets de données d'entête de segment et des paquets de données d'entête de morceau de segment, distincts des paquets de données d'entête de segment. [0014] Selon un mode de réalisation, les paquets transmis à l'équipement d'utilisateur com- prennent un ou plusieurs paquets de données de table, le procédé comprenant des étapes de formation par l'équipement d'utilisateur, d'une table pour le segment à partir des paquets de données de table, la table comprenant une adresse d'accès au segment, un numéro de premier morceau du segment, un numéro maximum de dernier morceau du segment et une indication que les données de segment sont transmises par morceau de segment, les paquets contenant des données de morceau de segment comprenant une taille de morceau de segment et la donnée indiquant si le morceau de segment se trouve à la fin du segment. [0015] Selon un mode de réalisation, les paquets transmis à l'équipement d'utilisateur com- prennent un ou plusieurs paquets de données de table, le procédé comprenant des étapes de formation par l'équipement d'utilisateur, d'une table pour le segment à partir des paquets de données de table, la table comprenant une adresse d'accès au segment, un identifiant du segment, et une indication que les données de segment sont transmises par morceau de segment, les paquets contenant des données de morceau de segment comprenant un identifiant du segment, une taille de morceau de segment, une position du morceau de segment dans le morceau de segment, et la donnée spécifiant si le morceau de segment se trouve à la fin du segment. [0016] Selon un mode de réalisation, les données d'entête de segment comprenant une adresse d'accès au segment, et une indication que les données de segment sont transmises par morceau de segment, les données d'entête de chaque morceau de segment du segment comprenant une taille du morceau de segment. [0017] Selon un mode de réalisation, les morceaux de segments sont générés les uns à la suite des autres en un flux HTTP avant d'être transmis sous la forme de paquets. [0018] Selon un mode de réalisation, chaque début de morceau de segment coïncide avec un début de paquet. [0019] Selon un mode de réalisation, le segment requis appartient à un contenu vidéo, chaque morceau de segment contenant un même nombre de trame du contenu vidéo. [0020] Selon un mode de réalisation, des morceaux de segments précédemment transmis d'un segment sont transmis en boucle dans un ou plusieurs autres canaux de transmission, pour permettre l'exploitation par un équipement d'utilisateur du segment. [0021] Selon un mode de réalisation, le contenu multimédia est défini conformément au standard DASH ou HLS. [0022] Selon un mode de réalisation, les paquets sont conformes aux protocoles ALC/LCT. [0023] Des modes de réalisation peuvent également concerner un serveur de diffusion de contenus multimédia, configuré pour mettre en oeuvre le procédé de diffusion précédemment défini. [0024] Des modes de réalisation peuvent également concerner un équipement d'utilisateur comprenant un circuit de connexion à un réseau de communication, un processeur configuré pour recevoir des segments de contenus multimédia transmis par le réseau de communication, en mettant en oeuvre le procédé de diffusion précédemment défini, et pour exploiter les segments reçus. [0025] Des modes de réalisation peuvent également concerner un produit programme d'ordinateur directement chargcable dans une mémoire interne d'un ordinateur et comprenant des portions de code qui lorsqu'elles sont exécutées par un ordinateur configurent l'ordinateur pour mettre en oeuvre les étapes de l'un ou l'autre des procédés précédemment définis. [0026] Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : [0027] [fig.1] la figure 1 représente schématiquement un système de transmission de contenu multimédia entre un serveur de contenu et des équipements d'utilisateurs, mettant en oeuvre un service MBMS, [0028] [fig.2] la figure 2 représente schématiquement les fonctions de réception de contenus multimédia d'un équipement d'utilisateur, [0029] [fig.3] la figure 3 est une vue schématique détaillée de la figure 1, [0030] [fig.4] la figure 4 représente schématiquement un système de transmission de contenu multimédia entre un serveur de contenu et des équipements d'utilisateurs, selon un autre mode de réalisation, [0031] [fig.5] la figure 5 illustre un mode de découpage d'un segment d'un contenu multimédia en morceaux de segment, [0032] [fig.6] ;[Fig. 7] ;[Fig. 8] ;[Fig. 9] les figures 6 à 9 illustrent schématiquement des modes de transmission de contenus multimédia, selon divers modes de réalisation. [0033] La figure 1 représente un système mettant en oeuvre un service de diffusion ou de transmission point-à-multipoint de contenu multimédia MBMS (Multimedia Broadcast Multicast Service). Ce service est décrit dans le document 3GPP TS 26.346 VI6.1.0 6 (2019-03). Le système comprend un ou plusieurs serveurs de contenu CNTS, des réseaux IPN tels que le réseau Internet et des réseaux mobiles, un serveur BMS mettant en oeuvre le service MBMS, relié au serveur CNTS par le réseau IPN, et des équipements d'utilisateur UE reliés aux réseaux TPN par l'intermédiaire de passerelles GW. Les réseaux TPN peuvent comprendre des réseaux fixes tel que le réseau Internet, et des réseaux mobiles interconnectés entre eux et aux réseaux fixes. Le serveur CNTS transmet des contenus multimédia par exemple conformes au standard MPEG-DASH, comprenant des segments associés à un descripteur de structure MPD (Media Presentation Description) spécifiant la structure du contenu multimédia. [0034] La figure 2 représente un équipement d'utilisateur UE. L'équipement UE comprend un lecteur multimédia MPL et un serveur mandataire (proxy) PXY connecté à une mémoire tampon BFF. L'équipement UE reçoit des contenus multimédia par exemple du serveur CNTS, sous la forme de segments SGM et d'un descripteur MPD associé. Les segments SGM sont transmis au serveur PXY pour être stockés dans la mémoire BFF et fournis à la demande au lecteur MPL. L'heure de réception du début de chaque segment est également inscrite dans la mémoire BFF en association avec le contenu du segment. Le descripteur MPD est transmis directement au lecteur MPL. [0035] L'équipement UE peut être un téléphone mobile tel qu'un smartphone ou une tablette numérique, un boitier décodeur de téléviseur et un poste de télévision, cet équipement exécutant une ou plusieurs applications implémentant le serveur PXY et le lecteur MPL. [0036] La figure 3 représente un exemple du système de la figure 1. Dans cet exemple, le serveur CNTS produit et/ou stocke des données de contenus CD, telles que des données vidéo, audio, des fichiers et plus généralement des contenus multimédia. Le serveur CNTS peut produire des flux de données qui sont convertis en flux de paquets avant d'être encapsulés dans des fichiers. Chaque flux individuel peut être soumis à un traitement de compression de données selon l'un des standards de compression connus, tels que ITU-T H.261, H.262, H.263, MPEG-I, MPEG-2, H.264/MPEG-4 part 10. HEVC (High Efficiency Video Coding), AV1 (AOMedia Video 1). [0037] Dans l'exemple de la figure 3, le serveur CNTS comprend une unité d'encapsulation ENCM qui reçoit des flux élémentaires de données encodées. L'unité d'encapsulation ENCM fournit des données d'une ou plusieurs représentations de contenus multimédias avec un fichier manifeste MPD à une interface de sortie OINT. L'interface de sortie OINT peut comprendre une interface réseau ou une interface apte à transmettre des données ou reliée à un support de stockage. L'unité d'encapsulation ENCM peut fournir les données de chaque représentation d'un contenu multimédia correspondant à l'interface de sortie OINT, laquelle peut transmettre les données à un serveur BMS, par l'intermédiaire d'un réseau de transmission IPN ou d'un support de stockage de 7 données. [0038] Le serveur BMS peut mettre en oeuvre un ou plusieurs protocoles de diffusion ou de transmission point-à-multipoint pour transmettre des données multimédia. Dans l'exemple de la figure 3, le serveur BMS peut comprendre une unité de stockage mémorisant des contenus multimédia MCNT, une unité d'acquisition de contenus CTAU et un module de transmission FSND. A titre d'exemple, le serveur BMS peut comprendre plusieurs interfaces réseau, incluant le module de transmission FSND. En outre, une ou plusieurs des fonctionnalités du service MBMS peuvent être mises en oeuvre dans d'autres dispositifs d'un réseau de distribution de contenus, tels que des routcurs, des passerelles réseau, des serveurs proxy, des commutateurs réseau. Des dispositifs intermédiaires peuvent réaliser la fonction de mémoire cache pour stocker temporairement les contenus multimédia MCNT. Le module de transmission FSND est configuré pour transmettre et recevoir des données du réseau IPN. [0039] Dans le cas du standard DASH, un contenu multimédia peut être associé à plusieurs représentations. Ces représentations sont définies dans un fichier descripteur MPD contenant un ensemble de données structurées accessible via à un dispositif client de lecture en continu (streaming) de contenu HTTP. Le dispositif client peut requérir et télécharger ce descripteur pour présenter à l'utilisateur un service de diffusion en continu. Les données structurées du descripteur MPD fournissent les caractéristiques de codage et de restitution de chaque représentation. En outre, un serveur peut fournir des données décrivant des caractéristiques d'un service de fourniture de contenu en mode diffusion ou point-à-multipoint, permettant au lecteur client de recevoir et traiter les données transmises Par exemple, ces données peuvent comprendre une adresse que le lecteur client peut utiliser pour accéder au service de fourniture de contenu. [0040] L'unité d'acquisition de contenus CTAU est configurée pour émettre des requêtes de contenu MCNT vers un serveur de contenu CNTS. Par exemple, l'unité d'acquisition CTAU peut mettre en oeuvre le protocole HTTP version 1.1 or 2 (la version 1.1 est décrite dans RFC 2616, la version 2 est décrite dans RFC 7540). Ainsi, l'unité CTAU peut être configurée pour émettre des requêtes HTTP GET ou GET partiel et recevoir en réponse des contenus multimédia MCNT. Les requêtes peuvent spécifier un segment d'une des représentations, par exemple en utilisant une adresse URL du segment. [0041] Le module de transmission FSND est configuré pour convertir des segments DASH des contenus MCNT en paquets FP, par exemple conformément au standard FLUTE. Le module de transmission FSND peut diviser et répartir un segment DASH dans un ou plusieurs paquets. La conversion en paquets FP comprend un encodage FEC (Forward Error Correction) permettant d'associer aux données de segment DASH des données redondantes permettant de corriger des erreurs de transmission. Pour 8 permettre de corréler les paquets FP avec les segments DASH, le module de transmission FSND peut attribuer un identifiant d'objet de transmission TOI (Transmission Ohject Identifier) à chaque segment. Un segment peut être considéré comme un fichier, et le nom du fichier FLUTE identifié par l'identifiant TOI peut être l'adresse URL du segment. Le module de transmission FSND peut générer une instance de table FDT (File Delivery Table) dans laquelle sont décrits dcs attributs des segments DASH. Les attributs des segments DASH peuvent comprendre un nom de fichier (spécifié par exemple par une adresse URL), un type de fichier (par exemple un type de fichier MIME), la taille du fichier, un condensé du fichier (par exemple Message Digest - MD5), dcs informations relatives au traitement FEC, et un format d'encodage du fichier. La table FDT correspondante peut être transmise dans un ou plusieurs paquets FP par le module de transmission FSND, associés à un identifiant TOI égal à O. [0042] L'équipement client UE peut comprendre une unité de réception de fichier FREC, une application de lecture APP, un module HTS assurant les fonctions de serveur HTTP et un module serveur MWM pouvant mettre en oeuvre le standard MBMS ou DVB-IPT (Digital Video Broadcasting - Internet Protocol Infrastructure), ainsi que le protocole ROUTE (Real-fi me Ohject delivery over Unidirectional Transport). L'application APP peut être configurée pour exploiter les contenus reçus du serveur BMS, et ainsi comprendre par exemple des décodeurs et des lecteurs de contenu multimédia, tels que des décodeurs et des lecteurs audio et vidéo. L'unité de réception de fichier FREC peut comprendre un récepteur et un décodeur FEC, mettant en oeuvre un protocole de fourniture de fichier tel que le protocole FLUTE. Ainsi, l'équipement client UE peut être configuré pour récupérer des données d'un contenu multimédia MCNT transmis en mode diffusion ou point-à-multipoint à l'aide du protocole FLUTE. Pour mettre en oeuvre un service de fourniture de fichiers conforme au standard FLUTE, le serveur BMS peut insérer dans la table FDT des attributs indiquant une ou plusieurs adresses URL de diffusion point-à-point (unicast) du contenu multimédia MCNT. L'unité de réception de fichier FREC peut recevoir des données, en mode diffusion, point-à-multipoint ou point-à-point, transmises par le serveur BMS (ou un autre service). En particulier, l'unité de réception de fichier FREC peut recevoir et traiter des paquets et reconstituer à partir des paquets reçus des données de segments SGN appartenant à une ou plusieurs représentations. Le module FREC peut fournir les données de segment SGN au module MWM, qui stocke les données de segment SGN pour les mettre à disposition du module HTS. Le module HTS reçoit et traite des requêtes HTTP émises par l'application APP, soit en fournissant les données de segment requises à partir des données de segment SGN (en mode diffusion ou pointà-multipoint, soit en adressant ces requêtes au serveur CNTS (en mode point-à-point). 9 Le module HTS peut mettre en oeuvre les fonctionnalités définies dans les spécifications 3GPP TS 26.346. [0043] L'application APP peut comprendre une fonction de navigation web et un lecteur de contenus vidéo. Pour lire des contenus vidéo, l'application APP peut être configurée pour récupérer des données de configuration de l'équipement client UE pour déterminer les capacités de décodage et de restitution des décodeurs et lecteurs audio et vidéo installés dans l'équipement client UE. [0044] Le module MWM peut être configure pour requérir et recevoir un contenu en mode diffusion ou point-à-multipoint transmis par le serveur BMS. Initialement, le contenu peut être transmis en mode point-à-point, puis en mode diffusion ou point-à-multipoint si un grand nombre d'équipements d'utilisateur demandent le même contenu. Inversement, la transmission d'un contenu peut passer du mode diffusion ou pointà-multipoint au mode point-à-point si le nombre d'équipements d'utilisateurs est insuffisant pour justifier l'utilisation d'un canal de diffusion ou de transmission en mode point-à-multipoint. [0045] Par exemple, l'application APP peut être configurée pour récupérer initialement les données permettant d'obtenir un fichier descripteur MPD qui peut comprendre des données pour accéder à un groupe de diffusion point-à-multipoint (telles qu'une adresse IP du groupe de diffusion) ou pour recevoir un contenu diffusé (par exemple, des données pour accéder à un domaine de transmission en mode diffusion). [0046] L'utilisateur de l'équipement client UE peut interagir avec l'application APP à l'aide des dispositifs d'interface utilisateur de l'équipement UE, tels qu'un clavier, une souris, un stylet, un écran tactile, pour requérir des contenus multimédia MCNT. En réponse à de telles requêtes d'un utilisateur, l'application APP peut sélectionner l'une des représentations sur la base, par exemple, des capacités de décodage et de restitution disponibles dans l'équipement client UE. Pour obtenir les données relatives à la représentation sélectionnée, le module MWM peut requérir séquentiellement des plages d'octets spécifiques de la représentation sélectionnée en émettant des commandes HTTP GET partiel. De cette manière, plutôt que de recevoir un fichier entier en réponse à une unique requête, le module MWM peut recevoir séquentiellement des parties d'un fichier (segment) en réponse à des requêtes multiples. Ces commandes permettent notamment de recevoir des parties de contenu manquantes, en raison d'une erreur de transmission ou parce qu'au moment où l'application accède au contenu en cours de diffusion, le début du contenu a déjà été transmis. [0047] La figure 4 représente un système mettant en oeuvre un service de diffusion ou de transmission point-à-multipoint de contenu multimédia, selon un autre mode de réalisation. Ce système diffère du système illustré par les figures 1 et 3 par le fait que les passerelles GW sont remplacées par des passerelles BMGW assurant les fonctions de l'unité FREC, du module HTS et du module MWM réalisées par les équipements d'utilisateur UE dans le mode de réalisation de la figure 1. Les équipements d'utilisateurs UE n'assurent donc que les fonctions de l'application APP dans le mode de réalisation de la figure 4. Les passerelles BMGW peuvent être des passerelles résidentielles intégrant un routeur assurant la liaison entre un réseau local privé et Internet. [0048] Selon d'autres modes de réalisation, les fonctions de l'unité FREC, du module HTS et du module MWM peuvent être assurées par le serveur BMS, et les fonctions assurées par le serveur BMS dans le mode de réalisation des figures 1, 3 et 4 peuvent également être réalisées par le serveur CNTS. [0049] Dans ce qui suit, "équipement d'utilisateur" peut désigner un terminal fixe ou mobile UE configuré pour restituer des contenus multimédia ou une passerelle BMGW configuré° pour recevoir des contenus multimédia dans un réseau local et transmetre les contenus reçus vers un ou plusieurs terminaux d'utilisateur connectés au réseau local. [0050] La figure 5 illustre un mode de découpage d'un segment SGi d'un contenu multimédia MCNT, par exemple conformément au standard CMAF, ce découpage pouvant être effectué par le serveur CNTS. Le contenu MCNT peut être au format MPEG DASH ou HLS (HTTP Live Streaming). Chaque segment SGi comprend un champ d'entête SGH et un champ de donnée SGD. Le segment SGi est découpé en n morceaux de segment CK1, CK2, CKn. Le découpage du segment SGi est effectué en répartissant les données du champ de donnée SGD du segment SGi dans des champs de donnée CKD1, CKD2, CKDn des morceaux de segment CK1-CKn. Chaque morceau de segment CKI-CKn comprend un champ de donnée CKD1-CKDn associé à un champ d'entête CKH1-CKHn déterminé en fonction du contenu du champ de donnée CKDI-CKDn du morceau. Ainsi le champ d'entête CKHj de chaque morceau CKj peut comprendre un numéro de séquence spécifiant la position du morceau CKj dans le flux et une information temporelle telle qu'un écart temporel entre le début du flux et le début du morceau CKj. Dans le cas d'un segment d'un contenu vidéo, chaque morceau de segment CKj peut ainsi comprendre une ou plusieurs trames du contenu vidéo. [0051] La figure 6 illustre un mode de transmission d'un contenu multimédia, selon un premier mode de réalisation. Dans ce mode de réalisation, le contenu multimédia MCNT est disponible sous la forme de segments SGi associés à un fichier MDP. Les segments SGi sont découpés en n morceaux CK1, CKj, CKn. Le module de transmission FSND forme des paquets à partir des morceaux de segment CKj, chaque morceau CKj pouvant être transmis dans plusieurs paquets de même taille, en mettant oeuvre les protocoles ALC/LCT. A cet effet, le module de transmission FSND associe à chaque morceau de segment CKj un identifiant TOI (Transport Output Identifier), et 11 construit une table FDT (File Del ivery Table) CKTj conformément au protocole FLUTE. [0052] Selon un mode de réalisation, l'identifiant TOI de chaque morceau de segment SGi peut être défini en attribuant au segment SGi et au premier morceau du segment CK1 le même identifiant TOI fixé à IDi, et aux morceaux CKj l'identifiant TOI fixé à IDi-Fj-1 (avec j=2, ...n). La table CKTj attribuée au morceau de segment CKj contient notamment la désignation de l'emplacement du morceau de segment FCLj sur le serveur de contenu CNTS ou sur le serveur BMS, un indicateur LCKj spécifiant si le morceau est le dernier du segment SGi, l'identifiant TOI CIDj du morceau de segment IDi-Fj-1, la taille CKLj du morceau de segment (ou la position du début du morceau de segment dans le segment), par exemple en nombre d'octets, et des paramètres ECPj de correction d'erreur FEC. L'emplacement FCLj peut comprendre la désignation de l'emplacement du segment SGi (par exemple l'adresse l'URL du segment) associée au numéro j du morceau de segment CKj, par exemple de la forme " lckj>". L'indicateur LCKj peut également être fourni dans l'adresse URL : " # &isLast, " avec LCKj fixé à "Truc" ou "False". [0053] La connaissance de la position du début de chaque morceau de segment dans un segment permet notamment de repérer les parties manquantes d'un segment qui peuvent ensuite être téléchargées par exemple à l'aide de commandes HTTP GET partiel. [0054] Les tables CKTj sont transmises également sous la forme de paquets associés à un identifiant TOI fixé à 0, qui sont transmis entremêlés avec les paquets contenant des parties de morceau de segment CKj. Les paquets sont transmis en mettant en oeuvre les protocoles ALC/LCT, ces protocoles prévoyant notamment d'associer à chaque paquet des données d'entête comprenant notamment l'identifiant TOI CIDj du morceau de segment CKj auquel appartiennent les données du paquet. [0055] Le mode de transmission de la figure 6 permet aux équipements d'utilisateur UE (figure 1) ou les passerelles BMGW (figure 4) d'exploiter chaque morceau de segment CKj dès la fin de la réception de ce dernier. En l'absence de découpage des segments SGi en morceaux CKj, les équipements UE (ou les passerelles BMGW) doivent attendre la réception de la fin du segment avant de pouvoir commencer à traiter le segment. [0056] Cependant, ce mode de transmission présente les inconvénients de multiplier la transmission d'informations identiques comme l'adresse du segment et les paramètres de correction d'erreur ECPj, et en même temps d'être sensible à la perte de paquets contenant les tables CKTj. 12 [0057] La figure 7 illustre un mode de transmission d'un contenu multimédia, selon un second mode de réalisation. Dans ce mode de transmission, les segments SGi du contenu multimédia MCNT sont également découpés en n morceaux de segment CK1-CKn, chaque morceau de segment étant transmis par paquets PK1-PKp conformément aux protocoles ALC/LCT. En revanche, une seule table FDT SGTi est constituée pour chaque segment SGi. Un identifiant TOI est attribué au segment SGi et également à chacun des morceaux de segment CK1-CKn. Comme précédemment, l'identifiant TOI du segment SGi et du premier morceau CK1 du segment peut être fixé à IDi (dans l'exemple des figures 6 et 7), et les identifiants TOI CIDj des morceaux de segment CKj peuvent être fixés à IDi-Ej-1 (avec j=1, 2, ...n). Chaque paquet PKk d'un morceau de segment CKj contient des données d'entête et des données SSk du morceau de segment CKj. Les données d'entête du paquet PKk comprennent notamment un numéro de paquet PNk, l'identifiant TOI CIDj du morceau de segment CKj, la taille CKLj du morceau de segment CKj (ou la position du début du morceau de segment dans le segment), par exemple exprimée en nombre d'octets, ainsi qu'une donnée LCKj spécifiant si le morceau de segment CKj est le dernier du segment SGi. La taille CKLj et la donnée LCKj de chacun des morceaux de segment CKj peuvent être spécifiées dans un champ d'extension ALC de l'entête de chacun des paquets PKk. [0058] La table SGTi contient notamment un indicateur DMi spécifiant si le segment SGi est transmis découpé en morceaux CKj ou en entier, la désignation FCLi de l'emplacement du segment SGi sur le serveur de contenu CNTS ou sur le serveur BMS, l'identifiant TOI CIDI (=IDi) du premier morceau CK1 du segment SGi, et un identifiant TOI MXTi spécifiant la fin d'une plage d'identifiants TOI susceptibles d'être attribués aux morceaux CKj du segment SGi. En effet, au moment de la génération du premier morceau CK1 du segment SGi, le nombre total de morceaux de segment CKj du segment SGi n'est pas connue. La table SGTi est également transmise sous la forme d'un ou plusieurs paquets ALC/LCT associés à un identifiant TOI fixé à 0, et plusieurs instances de la table SGTi peuvent être transmises dans des paquets entremêlés avec les paquets PKk contenant les données du segment SGi, notamment pour s'affranchir d'éventuelles erreurs de transmission des paquets contenant la table. [0059] La figure 8 illustre un mode de transmission d'un contenu multimédia, selon un troisième mode de réalisation. Dans ce mode de transmission, les segments SGi du contenu multimédia MCNT sont également découpés en n morceaux de segment CKI-CKn et transmis par paquets PK1, PKk, PKp en utilisant une extension des protocoles ALC/LCT. Une seule table FDT STIi est constituée pour chaque segment SGi, et un identifiant TOI SIDi (fixé à IDi dans l'exemple de la figure 8) est attribué à chaque segment SGi, mais pas aux morceaux de segments CKj. La table STli contient 13 notamment un indicateur DMi spécifiant si le segment SGi est transmis découpé en morceaux CKj ou en entier, la désignation FCLi de l'emplacement du segment SGi sur le serveur de contenu CNTS ou sur le serveur BMS, l'identifiant TOI SIDi (=IDi) du segment SGi. Chacun des paquets PKk contient des données d'entête et des données SSk d'un ou deux morceaux du segment CKj. Les données d'entête de chaque paquet PKk comprennent notamment un numéro de paquet PNk, l'identifiant TOI SIDi du segment SGi auquel appartient le paquet, et des données relatives aux données de morceau de segment CKj se trouvant dans le paquet, à savoir la position OFCj du début du morceau de segment CKj par rapport au début du segment SGi (ou la taille du morceau de segment), par exemple exprimée en nombre d'octets, et une donnée LCKj spécifiant si le morceau de segment CKj est le dernier du segment SGi. Dans le cas où le paquet PKk contient des données de la fin d'un morceau de segment (par exemple CKj) et du début du morceau de segment suivant (par exemple CKj+1), les données OFCj et LCKj peuvent être celles du morceau de segment suivant CKj+1, et dans le cas du dernier morceau CKn de segment SGi, celles du dernier morceau CKn. [0060] Ici encore, chaque morceau de segment CKj peut être exploité par un équipement d'utilisateur UE (ou une passerelle BMGW) dès la réception par cc dernier de tous les paquets contenant les données du morceau. Cependant, le fait qu'un paquet PKk puisse contenir les données de deux morceaux de segment consécutifs CKj, CKj+1 implique que le morceau CKj ne peut pas être complètement transmis avant que le morceau CKj+1 soit complètement généré et disponible. Pour éviter cet inconvénient, il peut être envisagé de faire coïncider chaque début de morceau CKj avec un début de paquet PKk en complétant si nécessaire le paquet précédent PKk-1 par des données de remplissage, sachant que la taille réelle, variable de chaque morceau de segment est spécifiée dans les données d'entête des paquets grâce à la donnée OFCj. Si la taille des paquets n'est pas trop grande, la quantité de données de remplissage ainsi inutilement transmises pour un morceau de segment peut être négligeable, sachant que cette quantité est majorée par la taille des paquets. Il peut être également prévu que les paquets PKk puissent avoir une taille variable, pour éviter la transmission de données de remplissage. [0061] La figure 9 illustre un mode de transmission d'un contenu multimédia, selon un quatrième mode de réalisation. Dans ce mode de transmission, les segments SGi du contenu multimédia MCNT sont également découpés en n morceaux de segment CK1-CKn qui sont transmis directement dans un flux HTTP fourni en réponse à une requête de segment, par exemple de type HTTP GET, ce flux étant transmis sous la forme de paquets ALC/LCT qui sont formés au fur et à mesure de la formation des morceaux de segment, par exemple conformément au mécanisme de transmission de données en continu prévu dans le protocole HTTP/1.1. Le flux HTTP transmis 14 comprend des données d'entête HTTP HDS suivies des données des morceaux de segment CKj, les données de chaque morceau de segment CKj étant précédées d'une entête de morceau de segment LN1 contenant la taille du morceau de segment, par exemple exprimée en nombre d'octets. Les données d'entête HDS de chaque flux HTTP peuvent comprendre notamment une donnée de définition de type de contenu CTTi relative aux données du segment SGi, une donnée TEi spécifiant si le segment SGi est transmis découpé en morceaux ou en entier, et une donnée CTL1 specifiant une adresse d'accès au segment SGi, par exemple une adresse URL. Les données du dernier morceau CKn du segment SGi sont suivies d'un champ taille de morceau LNn+1 fixé à 0 pour spécifier qu'il s'agit de la fin du segment SGi. Dès qu'un morceau de segment CKj est reçu, il peut être mis dans une mémoire tampon de l'équipement UE (ou de la passerelle BMGW), où il peut être lu et exploité par une application de lecture de contenus multimédia. Ainsi, l'application n'a pas besoin d'attendre la fin de la réception d'un segment pour pouvoir l'exploiter. Contrairement aux modes de transmission précédemment décrits, ce mode de transmission ne nécessite pas de transmettre une table FDT. [0062] Dans certains cas, il peut être nécessaire de mettre en place un mécanisme de correction d'erreur FEC. Dans cc cas, les paquets ALC/LCT doivent avoir la même taille. Il peut donc se produire qu'un paquet puisse contenir les données de deux morceaux de segment consécutifs, ce qui implique que le premier de ces deux morceaux ne peut pas être complètement transmis tant que le second de ces deux morceau n'est pas complètement généré et disponible. Ici encore, il peut être prévu de compléter un paquet contenant la fin d'un morceau de segment avec des données de remplissage, afin d'assurer que chaque début de morceau de segment CKj coïncide avec le début d'un paquet PKk. Ainsi l'équipement d'utilisateur UE (ou la passerelle BMGW) recevant les paquets ALC/LCT peut déterminer lorsqu'il reçoit le dernier paquet d'un morceau de segment CKj à partir de la taille du morceau de segment contenue dans l'entête LNj, et déterminer à partir de cette taille la fin du morceau de segment dans le paquet, afin de localiser et éliminer les données de remplissage lors de la reconstitution des morceaux de segment. Le quatrième mode de transmission, avec alignement des paquets sur les morceaux de segment, peut être indiqué par la donnée d'entête TEL [0063] Le découpage en morceaux des segments d'un contenu multimédia peut également permettre à un équipement d'utilisateur UE (ou à une passerelle BMGW) d'accéder rapidement à un segment en cours de transmission, notamment dans le cas d'un contenu vidéo. En effet, dans ce cas d'un segment vidéo, il est généralement nécessaire, pour pouvoir décoder et afficher une trame vidéo d'un segment, de disposer des trames précédentes depuis le début du segment. A cet effet, chaque morceau CKj d'un segment SGi déjà transmis dans un canal de transmission principal peut être transmis en boucle dans un canal de transmission auxiliaire, par exemple à un débit de transmission plus élevé. De cette manière, si un équipement d'utilisateur UE (ou une passerelle BMGW) accède au canal principal de diffusion d'un contenu multimédia à un instant tO, pendant la transmission d'un morceau de segment CKj-1 (>2), il peut commencer à recevoir et traiter le morceau de segment CKj. En parallèle, il peut accéder au canal auxiliaire pour obtenir les premiers morceaux de segment CK1 à CKj-1 transmis antérieurement à l'instant tO, par exemple à l'aide d'une commande HTTP GET partiel spécifiant les données manquantes, à savoir par exemple la position du début du segment CKj par rapport à la position du début du segment SGi dans le flux. Si la position OFCj du début du morceau de segment CKj par rapport au début du segment SGi est transmise, la commande GET partielle peut utiliser cette information. Les morceaux requis peuvent être transmis en parallèle dans le canal auxilaire en mode point-à-point. [0064] Dès la réception des morceaux de segment CK1 à CKj-1 et CKj, l'équipement d'utilisateur UE (ou la passerelle BMGW) peut générer un flux multimédia exploitable (susceptible d'être lu par une application de lecture) à partir du morceau CKj ou de n'importe lequel des morceaux précédents CK1 à CKj-1. En cas de réception d'un flux (vidéo) en direct, il peut être préférable de n'afficher le flux qu'à partir morceau CKj ou CKj+1 pour être en phase avec le temps réel. Dans ce cas, les morceaux précédents CK1 à CKj-1 ne sont utilisés que pour décoder les morceaux CKj et suivants. [0065] L'encodage de chaque segment peut être conçu pour offrir plusieurs accès directs au flux sans qu'il soit nécessaire de décoder les premiers morceaux de segment du segment. A cet effet, certains morceaux de segment de chaque segment peuvent être encodés de manière indépendante des morceaux précédents du segment. De cette manière, si un équipement d'utilisateur UE (ou une passerelle BMGW) accède au canal principal de diffusion d'un contenu multimédia à un instant pendant la transmission d'un morceau de segment CKj-1 (j>2), il a besoin de requérir les morceaux de segments précédents seulement jusqu'au morceau de segment indépendant précédent. A cet effet, les données associées aux morceaux de segment peuvent comprendre en outre la position (par exemple en nombre d'octets) du début du morceau de segment CKj par rapport au début du morceau de segment indépendant précédent offrant un accès direct au flux. [0066] Par ailleurs, il peut être prévu d'adapter le fichier descripteur MPD, par exemple dans l'élément "representation", pour signaler les morceaux de segment indépendants. Cette signalisation peut être réalisée par une indication de position ou de fréquence des morceaux de segment indépendants dans les segments. Il est à noter que cette disposition est indépendante du mode de transmission, diffusion, point-à-multipoint ou point-à-point et des dispositions décrites précédemment relatives aux modes diffusion 16 et point-à-multipoint, et permet à un équipement d'utilisateur d'accéder rapidement, notamment à un flux transmis en direct. [0067] Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. En particulier, si l'invention a été décrite dans le cadre des protocoles DASH, FLUTE et ALC/LCT, d'autres protocoles de transmission peuvent bien entendu être mis en oeuvre, dès lors qu'ils permettent de diffuser des contenus multimédia sous la forme de séries de segments en mode diffusion ou point-à-multipoint, les données de segment étant transmises sous la forme de paquets. [0068] Par ailleurs, les fonctions précédemment décrites peuvent être implémentées sous forme matérielle, logicielle ou toute combinaison de celles-ci. Si elles sont implémentées dans un logiciel, les fonctions peuvent être stockées ou transmises sous forme d'une ou plusieurs instructions ou codes sur un support lisible par ordinateur et exécutées par une unité de traitement matérielle. Un support lisible par ordinateur peut comprendre un support de stockage tangible, lisible par ordinateur, tel qu'un support de stockage de données, ou un support de communication incluant tout support facilitant le transfert d'un programme d'ordinateur d'un endroit à un autre, par exemple selon un protocole de communication.. De cette manière, un support lisible par ordinateur peut généralement correspondre à un support de stockage tangible lisible par un ordinateur ou à un support de communication tel qu'un signal ou une onde porteuse. Les supports de stockage de données peuvent être tout support disponible auquel un ou plusieurs ordinateurs ou un ou plusieurs processeurs peuvent avoir accès pour récupérer des instructions, du code et/ou des structures de données en vue de la mise en oeuvre des techniques décrites dans la présente description. Un produit programme d'ordinateur peut inclure un support lisible par ordinateur. [0069] A titre d'exemple non limitatif, de tels supports de stockage lisibles par ordinateur peuvent comprendre une mémoire RAM, une mémoire ROM, une mémoire EEPROM, un CD-ROM ou un autre disque optique, un stockage sur disque magnétique ou d'autres dispositifs de stockage magnétiques, une mémoire flash ou tout autre support peut être utilisé pour stocker le code de programme souhaité sous la forme d'instructions ou de structures de données et pouvant être consulté par un ordinateur. En outre, toute connexion est correctement appelée un support lisible par ordinateur. Par exemple, si les instructions sont transmises depuis un site Web, un serveur ou une autre source distante à l'aide d'un câble coaxial, d'un câble à fibre optique, d'une paire torsadée, d'une ligne d'abonné numérique (DSL) ou de technologies sans fil telles que l'infrarouge, la radio et les hyperfréquences, Les câbles coaxiaux, les câbles à fibres optiques, les paires torsadées, les technologies DSL ou sans fil, tels que les technologies infrarouge, radio et micro-ondes, sont inclus dans la définition du support. Il 17 faut cependant comprendre que les supports de stockage lisibles par ordinateur et les supports de stockage de données n'incluent pas les connexions, les ondes porteuses, les signaux ou autres supports transitoires, mais sont plutôt dirigés vers des supports de stockage tangibles non transitoires. Les disques tels qu'utilisés ici, incluent les disques compacts (CD), les disques laser, les disques optiques, les disques numériques polyvalents (DVD), les disquettes et disques Blu-ray, où les disques reproduisent généralement les données par voie magnétique ou optiquement à l'aide de lasers. Des combinaisons de ce qui précède sont également être incluses dans le champ des supports lisibles par ordinateur. 18 [Revendication 1] [Revendication 2] [Revendication 3] REVENDICATIONSProcédé de diffusion de contenus multimédia vers des équipements d'utilisateur, le procédé comprenant des étapes consistant à : émettre, par un équipement d'utilisateur (13E, BMGW), une requête d'un segment (SGi) d'un contenu multimédia (MCNT), le contenu multimédia étant divisé en segments, recevoir des paquets (PKk) transmis en mode diffusion ou pointà-multipoint à plusieurs équipements d'utilisateur, les paquets reçus comprenant des données de morceau de segment (CKj) résultant d'un découpage en morceaux de segment du segment requis, les données de morceau de segment étant associées à une donnée (FCLi) d'identification du segment, une donnée (CIDj, CKLj, OFCj) de position du morceau de segment dans le segment et un indicateur (LCKj) de dernier morceau de segment dans le segment requis, et former les morceaux de segment au fur et à mesure de la réception des paquets, les morceaux de segment formés étant exploitables séparément dès leur formation, par une application (APP) de lecture de contenu multimédia installée sur l'équipement d'utilisateur. Procédé de diffusion de contenus multimédia par un serveur vers des équipements d'utilisateur, le procédé comprenant des étapes consistant à: recevoir, par un serveur (BMS) de diffusion de contenus multimédia, des morceaux de segment (SGi) d'un contenu (MCNT) multimédia, le contenu multimédia étant divisé en segments, et transmettre, par le serveur, en mode diffusion ou point-à-multipoint à plusieurs équipements d'utilisateur (UE, BMGW), les morceaux de segment dans des paquets (PKk), les données de morceau de segment étant associées à une donnée (FCLi, LCKj, LNn+l) d'identification du segment, une donnée de position du morceau de segment dans le segment et un indicateur de dernier morceau de segment dans le segment. Procédé selon la revendication 1 ou 2, dans lequel les paquets (PKk) transmis à l'équipement d'utilisateur (UE, BMGW) comprennent un ou plusieurs paquets de données de tables, le procédé comprenant des étapes de formation par l'équipement d'utilisateur, d'une table (CKTj) pour chaque morceau du segment (CKj) à partir des paquets de données de tables, chaque table comprenant une adresse d'accès au segment 19 [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] (FCLi), un identifiant du morceau de segment (CIDj), une taille (CKLj) du morceau de segment et la donnée (LCKj) signalant si le morceau de segment se trouve à la fin du segment (SGi). Procédé selon la revendication 1 ou 2, dans lequel les paquets transmis à l'équipement d'utilisateur (UE, BMGW) pour un segment (SGi) comprennent un ou plusieurs paquets de données d'entête de segment (SGTi, ST1 i, HDS) et des paquets de données d'entête (CIDj, CKLj LCFj, LNj) de morceau de segment, distincts des paquets de données d'entête de segment. Procédé selon la revendication 4, dans lequel les paquets (PKk) transmis à l'équipement d'utilisateur (UE, BMGW) comprennent un ou plusieurs paquets de données de table, le procédé comprenant des étapes de formation par l'équipement d'utilisateur, d'une table (SGTi) pour le segment (SGi) à partir des paquets de données de table, la table comprenant une adresse d'accès (FCLi) au segment, un numéro de premier morceau du segment (ID1), un numéro maximum (MXTi) de dernier morceau du segment et une indication (DMi) que les données de segment sont transmises par morceau de segment, les paquets (PKk) contenant des données de morceau de segment comprenant une taille (CKLj) de morceau de segment et la donnée (LCKj) indiquant si le morceau de segment se trouve à la fin du segment. Procédé selon la revendication 4, dans lequel les paquets (PKk) transmis à l'équipement d'utilisateur (UE, BMGW) comprennent un ou plusieurs paquets (le données de table, le procédé comprenant des étapes de formation par l'équipement (l'utilisateur, d'une table (ST1i) pour le segment (SGi) à partir des paquets de données de table, la table comprenant une adresse d'accès (FCLi) au segment, un identifiant du segment (SIDi), et une indication (DMOi) que les données de segment sont transmises par morceau de segment, les paquets (PKk) contenant des données de morceau de segment comprenant un identifiant du segment (CIDj), une taille (CKLj) de morceau de segment, une position (OFCj) du morceau de segment dans le morceau de segment (CKj), et la donnée (LCKj) spécifiant si le morceau de segment se trouve à la fin du segment. Procédé selon la revendication 4, dans lequel les données d'entête de segment comprenant une adresse (CTLi) (l'accès au segment, et une indication (TEi) que les données de segment sont transmises par morceau de segment, les données d'entête de chaque morceau de segment (CKj) 20 [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] [Revendication 14] [Revendication 15] [Revendication 16] du segment comprenant une taille (LNj) du morceau de segment. Procédé selon la revendication 7, dans lequel les morceaux de segments (CKj) sont générés les uns à la suite des autres en un flux HTTP avant d'être transmis sous la forme de paquets (PKk). Procédé selon l'une des revendications 1 à 8, dans lequel chaque début de morceau de segment (CKj) coïncide avec un début de paquet (PKk). Procédé selon l'une des revendications 1 à 9, dans lequel le segment requis (SGi) appartient à un contenu vidéo, chaque morceau de segment (CKj) contenant un même nombre de trame du contenu vidéo (MCNT). Procédé selon l'une des revendications 1 à 10, dans lequel des morceaux de segments (CKj) précédemment transmis d'un segment (SGi) sont transmis en boucle dans un ou plusieurs autres canaux de transmission, pour permettre l'exploitation par un équipement d'utilisateur (UE, BMGW) du segment. Procédé selon l'une des revendications 1 à 11, dans lequel le contenu multimédia (MCNT) est défini conformément au standard DASH ou HLS. Procédé selon l'une des revendications 1 à 12, dans lequel les paquets (PKk) sont conformes aux protocoles ALC/LCT. Serveur de diffusion de contenus multimédia, configuré pour mettre en oeuvre le procédé selon l'une des revendications 2 à 13. Equipement d'utilisateur comprenant un circuit de connexion à un réseau de communication (IPN), un processeur configuré pour recevoir des segments (SGi) de contenus multimédia (MCNT) transmis par le réseau de communication, en mettant en oeuvre le procédé selon l'une des revendications 1 et 3 à 13, et pour exploiter les segments reçus. Produit programme d'ordinateur directement chargeable dans une mémoire interne d'un ordinateur et comprenant des portions de code qui lorsqu'elles sont exécutées par un ordinateur configurent l'ordinateur pour mettre en oeuvre les étapes du procédé selon l'une des revendications 1 à 13.