FR3096203A1 - Procede de diffusion de contenus multimedia avec une faible latence - Google Patents

Procede de diffusion de contenus multimedia avec une faible latence Download PDF

Info

Publication number
FR3096203A1
FR3096203A1 FR1904964A FR1904964A FR3096203A1 FR 3096203 A1 FR3096203 A1 FR 3096203A1 FR 1904964 A FR1904964 A FR 1904964A FR 1904964 A FR1904964 A FR 1904964A FR 3096203 A1 FR3096203 A1 FR 3096203A1
Authority
FR
France
Prior art keywords
segment
piece
data
packets
multimedia content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1904964A
Other languages
English (en)
Other versions
FR3096203B1 (fr
Inventor
Cédric Thienot
Christophe Burdinat
Tuan TRAN THAI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Expway SA
Original Assignee
Expway SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Expway SA filed Critical Expway SA
Priority to FR1904964A priority Critical patent/FR3096203B1/fr
Priority to PCT/IB2020/054315 priority patent/WO2020229955A1/fr
Publication of FR3096203A1 publication Critical patent/FR3096203A1/fr
Application granted granted Critical
Publication of FR3096203B1 publication Critical patent/FR3096203B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

PROCEDE DE DIFFUSION DE CONTENUS MULTIMEDIA AVEC UNE FAIBLE LATENCE L’invention concerne 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 (SGi), recevoir, par l’équipement d’utilisateur, 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, LCKj, LNn+1) 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, par l’équipement d’utilisateur, 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. Figure pour l’abrégé : Fig. 7

Description

PROCEDE DE DIFFUSION DE CONTENUS MULTIMEDIA AVEC UNE FAIBLE LATENCE
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.
Le standard DASH (Dynamic 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 une 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 Media 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.
Le 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.
Le standard CMAF permet de découper les segments en morceaux (chunks) rassemblant 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 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.
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.
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.
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.
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 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 Layered Coding / Layered 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 nécessite 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 œuvre de telles tables FDT constitue donc un obstacle à l’encontre de la division des segments en morceaux.
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.
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.
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.
Selon un mode de réalisation, les paquets transmis à l’équipement d’utilisateur 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 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.
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.
Selon un mode de réalisation, les paquets transmis à l’équipement d’utilisateur 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 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.
Selon un mode de réalisation, les paquets transmis à l’équipement d’utilisateur 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 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.
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.
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.
Selon un mode de réalisation, chaque début de morceau de segment coïncide avec un début de paquet.
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.
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.
Selon un mode de réalisation, le contenu multimédia est défini conformément au standard DASH ou HLS.
Selon un mode de réalisation, les paquets sont conformes aux protocoles ALC/LCT.
Des modes de réalisation peuvent également concerner un serveur de diffusion de contenus multimédia, configuré pour mettre en œuvre le procédé de diffusion précédemment défini.
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 œuvre le procédé de diffusion précédemment défini, et pour exploiter les segments reçus.
Des modes de réalisation peuvent également concerner un 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 œuvre les étapes de l’un ou l’autre des procédés précédemment définis.
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 :
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 œuvre un service MBMS,
la figure 2 représente schématiquement les fonctions de réception de contenus multimédia d’un équipement d’utilisateur,
la figure 3 est une vue schématique détaillée de la figure 1,
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,
la figure 5 illustre un mode de découpage d’un segment d’un contenu multimédia en morceaux de segment,
;[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.
La figure 1 représente un système mettant en œuvre 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 V16.1.0 (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 œuvre le service MBMS, relié au serveur CNTS par le réseau IPN, et des équipements d’utilisateur UE reliés aux réseaux IPN par l’intermédiaire de passerelles GW. Les réseaux IPN 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.
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.
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.
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-1, MPEG-2, H.264/MPEG-4 part 10, HEVC (High Efficiency Video Coding), AV1 (AOMedia Video 1).
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 données.
Le serveur BMS peut mettre en œuvre 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 œuvre dans d’autres dispositifs d’un réseau de distribution de contenus, tels que des routeurs, 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.
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.
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 œuvre 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.
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 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 Object 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 des 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), des 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 à 0.
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 œuvre le standard MBMS ou DVB-IPI (Digital Video Broadcasting - Internet Protocol Infrastructure), ainsi que le protocole ROUTE (Real-time Object 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 œuvre 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 œuvre 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). Le module HTS peut mettre en œuvre les fonctionnalités définies dans les spécifications 3GPP TS 26.346.
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.
Le module MWM peut être configuré 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.
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).
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.
La figure 4 représente un système mettant en œuvre 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.
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.
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ée 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.
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 CK1-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 CKD1-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.
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 œuvre 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 construit une table FDT (File Delivery Table) CKTj conformément au protocole FLUTE.
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+j-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+j-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 "<URL Segment>#<j>". L’indicateur LCKj peut également être fourni dans l’adresse URL :
"<URL Segment>#<j>&isLast=<LCKj>"
avec LCKj fixé à "True" ou "False".
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.
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 œuvre 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.
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.
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.
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+j-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.
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 CID1 (=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.
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 CK1-CKn et transmis par paquets PK1, … PKk, … PKp en utilisant une extension des protocoles ALC/LCT. Une seule table FDT ST1i 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 ST1i 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 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.
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 ce 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.
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 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 CTLi spécifiant 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.
Dans certains cas, il peut être nécessaire de mettre en place un mécanisme de correction d’erreur FEC. Dans ce 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 TEi.
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 t0, pendant la transmission d’un morceau de segment CKj-1 (j>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 t0, 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.
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.
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.
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 et point-à-multipoint, et permet à un équipement d’utilisateur d’accéder rapidement, notamment à un flux transmis en direct.
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 œuvre, 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.
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 œuvre des techniques décrites dans la présente description. Un produit programme d'ordinateur peut inclure un support lisible par ordinateur.
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 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.

Claims (16)

  1. 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 (UE, 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.
  2. 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+1) 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.
  3. 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 (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).
  4. 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, ST1i, 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.
  5. 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.
  6. 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 (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.
  7. Procédé selon la revendication 4, dans lequel les données d’entête de segment comprenant une adresse (CTLi) d’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) du segment comprenant une taille (LNj) du morceau de segment.
  8. 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).
  9. 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).
  10. 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).
  11. 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.
  12. 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.
  13. Procédé selon l'une des revendications 1 à 12, dans lequel les paquets (PKk) sont conformes aux protocoles ALC/LCT.
  14. Serveur de diffusion de contenus multimédia, configuré pour mettre en œuvre le procédé selon l’une des revendications 2 à 13.
  15. 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 œuvre le procédé selon l’une des revendications 1 et 3 à 13, et pour exploiter les segments reçus.
  16. 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 œuvre les étapes du procédé selon l’une des revendications 1 à 13.
FR1904964A 2019-05-13 2019-05-13 Procede de diffusion de contenus multimedia avec une faible latence Active FR3096203B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1904964A FR3096203B1 (fr) 2019-05-13 2019-05-13 Procede de diffusion de contenus multimedia avec une faible latence
PCT/IB2020/054315 WO2020229955A1 (fr) 2019-05-13 2020-05-07 Procede de diffusion de contenus multimedia avec une faible latence

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1904964 2019-05-13
FR1904964A FR3096203B1 (fr) 2019-05-13 2019-05-13 Procede de diffusion de contenus multimedia avec une faible latence

Publications (2)

Publication Number Publication Date
FR3096203A1 true FR3096203A1 (fr) 2020-11-20
FR3096203B1 FR3096203B1 (fr) 2024-08-30

Family

ID=67957035

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1904964A Active FR3096203B1 (fr) 2019-05-13 2019-05-13 Procede de diffusion de contenus multimedia avec une faible latence

Country Status (2)

Country Link
FR (1) FR3096203B1 (fr)
WO (1) WO2020229955A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110231519A1 (en) * 2006-06-09 2011-09-22 Qualcomm Incorporated Enhanced block-request streaming using url templates and construction rules
US20170272691A1 (en) * 2014-12-22 2017-09-21 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015150736A1 (fr) * 2014-03-31 2015-10-08 British Telecommunications Public Limited Company Diffusion en continu en multidiffusion

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110231519A1 (en) * 2006-06-09 2011-09-22 Qualcomm Incorporated Enhanced block-request streaming using url templates and construction rules
US20170272691A1 (en) * 2014-12-22 2017-09-21 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method

Also Published As

Publication number Publication date
FR3096203B1 (fr) 2024-08-30
WO2020229955A1 (fr) 2020-11-19

Similar Documents

Publication Publication Date Title
JP6845223B2 (ja) コーディングされたオーディオデータのトランスポート
US10560726B2 (en) System and method for delivery and caching of personalized media streaming content
US9854375B2 (en) Selection of coded next generation audio data for transport
US9038116B1 (en) Method and system for recording streams
US20180332094A1 (en) Systems, Methods, and Media for Streaming Media Content
CA2923168C (fr) Evitement de saut d&#39;annonces publicitaires dans des systemes a debit binaire adaptatif
US10902474B2 (en) Targeted advertisement insertion for streaming media data
JP4619353B2 (ja) マルチメディアコンテンツを配信するためのシステム
CN103392344B (zh) 使用用于流化的http网络的格式未知的流化体系结构
US20140019587A1 (en) Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format
TW201711431A (zh) 超級本文傳輸協定上動態自適應串流客戶經驗品質度量之中間軟體傳遞
BR112015022239B1 (pt) Método para desviar uma solicitação de arquivo de manifesto em um sistema de taxa de bits adaptativa, reprodutor de taxa de bits adaptativa para realizar a transmissão do conteúdo de transmissão de taxa de bits adaptativa através de uma rede a um cliente e meio de armazenamento legível por computador
US10560866B2 (en) Method of handling packet losses in transmissions based on DASH standard and FLUTE protocol
TW201021573A (en) Proxy functionality
RU2656093C2 (ru) Устройство поставки контента, способ поставки контента, программа, оконечное устройство и система поставки контента
WO2021078279A1 (fr) Procédé et système d&#39;enregistrement de flux multimédia en direct et support de stockage lisible par ordinateur
US20210203709A1 (en) Embedding MQTT messages in media streams
CN105656742A (zh) 一种基于most的多环网流媒体多播系统和方法
EP3092780B1 (fr) Signalisation et gestion de marquage scientifique pour une diffusion en continu adaptative
WO2020229955A1 (fr) Procede de diffusion de contenus multimedia avec une faible latence
CN114173145A (zh) 一种基于hls协议动态码率低延迟直播方法
RU2658672C2 (ru) Устройство предоставления контента, программа, оконечное устройство и система предоставления контента
EP4381718A1 (fr) Synchronisation de supports indépendants et de flux de données à l&#39;aide de points de synchronisation de flux multimédia
BR112017027511B1 (pt) Distribuição de middleware de métricas de qoe de cliente dash
KR20110119490A (ko) 라이브 컨텐츠의 효과적인 재생방법

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20201120

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6