FR3031862A1 - Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct. - Google Patents

Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct. Download PDF

Info

Publication number
FR3031862A1
FR3031862A1 FR1550342A FR1550342A FR3031862A1 FR 3031862 A1 FR3031862 A1 FR 3031862A1 FR 1550342 A FR1550342 A FR 1550342A FR 1550342 A FR1550342 A FR 1550342A FR 3031862 A1 FR3031862 A1 FR 3031862A1
Authority
FR
France
Prior art keywords
client
data stream
server
stream
segments
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
FR1550342A
Other languages
English (en)
Other versions
FR3031862B1 (fr
Inventor
Frederic Sodi
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.)
Sagemcom Broadband SAS
Original Assignee
Sagemcom Broadband SAS
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 Sagemcom Broadband SAS filed Critical Sagemcom Broadband SAS
Priority to FR1550342A priority Critical patent/FR3031862B1/fr
Priority to US15/541,133 priority patent/US20180198834A1/en
Priority to EP16700626.1A priority patent/EP3245794A1/fr
Priority to CN201680005854.6A priority patent/CN107211166A/zh
Priority to PCT/EP2016/050697 priority patent/WO2016113364A1/fr
Priority to BR112017014537A priority patent/BR112017014537A2/pt
Publication of FR3031862A1 publication Critical patent/FR3031862A1/fr
Application granted granted Critical
Publication of FR3031862B1 publication Critical patent/FR3031862B1/fr
Expired - Fee Related 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • H04N21/2358—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages for generating different versions, e.g. for different recipient devices
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25825—Management of client data involving client display capabilities, e.g. screen resolution of a mobile phone
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25833—Management of client data involving client hardware characteristics, e.g. manufacturer, processing or storage capabilities
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25858—Management of client data involving client software characteristics, e.g. OS identifier
    • 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

Abstract

Procédé de transmission d'un flux de données entre un serveur et un client utilisant le protocole de diffusion en direct basé sur HTTP comprenant les étapes suivantes, mises en œuvre par le serveur, suite à une réception d'au moins une information représentative d'une capacité dudit client : adapter (402) un flux de données initial à chaque capacité reçue afin d'obtenir un flux de données adapté ; décomposer (403) en segments le flux de données adapté ; transmettre (404, 405) au client une information descriptive permettant d'obtenir, pour chaque segment, une adresse de chargement dudit segment, ladite information descriptive permettant au client de demander au serveur une transmission des segments afin d'obtenir le flux de données adapté.

Description

La présente invention concerne un procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct, comme par exemple le protocole de diffusion en direct basé sur HTTP (« HTTP Live Streaming (HLS) » en terminologie anglo-saxonne, Informational Internet Draft, R. Pantos, Apple Inc., October 14, 2014, draft-pantos-http-live-streaming-14). L'invention concerne de plus un dispositif serveur, un dispositif client et un système mettant en oeuvre ledit procédé. Il est connu des protocoles de diffusion en direct (« streaming » en terminologie anglo-saxonne) de flux de données entre un serveur et un client dans lesquels la diffusion d'un flux de données est à l'initiative du client. C'est le cas par exemple du protocole de diffusion en direct basé sur HTTP, appelé par la suite protocole HLS. Le protocole HLS permet de diffuser en direct des flux audio, des flux vidéo, des flux de métadonnées ou des flux combinant plusieurs types de flux de données. Une diffusion d'un flux de données utilisant le protocole HLS débute par une réception par le serveur d'une requête HTTP en provenance d'un client. Cette requête demande une diffusion d'un des flux de données disponibles sur le serveur. Nous appelons par la suite ce flux de données, flux de données initial. Le serveur lance alors une décomposition du flux de données initial en segments. Chaque segment représente une durée d'affichage inférieure ou égale à une constante fixée par le protocole HLS. Chaque segment est associé à une adresse telle qu'une URI (identifiant uniforme de ressource, « Uniform Ressource Identifier » en terminologie anglo-saxonne) permettant à un client d'obtenir le segment. Par ailleurs, chaque segment est associé à un numéro de séquence et à une durée, ce qui permet de réordonner les segments. Suite au lancement de la décomposition, le serveur crée un fichier texte appelé fichier liste de lecture («playlist file » en terminologie anglo-saxonne) selon un format spécifié par le protocole FILS. L'adresse URI, le numéro de séquence et la durée de chaque segment que le serveur souhaite rendre disponibles pour un client apparaissent dans le fichier liste de lecture. Une adresse URI est ensuite créée pour le fichier liste de lecture, de manière à permettre à un client d'obtenir le fichier liste de lecture. Le fichier liste de lecture peut être mis à jour par le serveur en fonction d'une disponibilité des segments constituant le flux de données. La fin d'un flux de données est indiqué dans le fichier liste de lecture par un segment particulier appelé segment final. Le protocole FILS permet de diffuser des flux de données temps réel, i.e. des flux de données créés au fur et à mesure de la diffusion, ou des flux de données préexistant intégralement avant le début de la diffusion. Dans le cas de flux de données temps réel, le fichier liste de lecture est alimenté en cours de diffusion par des informations (adresse URI, numéro de séquence, durée) relatives à de nouveaux segments, les informations relatives aux segments les plus anciens pouvant être retirées dudit fichier liste de lecture. Dans le cas d'un flux de données préexistant, le fichier liste de lecture peut comprendre des informations relatives à chaque segment constituant le flux de données. Afin de répondre à de multiples clients ayant des capacités différentes, le protocole FILS permet à un serveur de créer plusieurs versions différentes d'un même flux de données initial. Chaque flux de données ainsi créé, appelé par la suite premier flux de données, est décomposé en segments. Un fichier liste de lecture est alors créé pour chaque premier flux de données. Dans ce cas, le serveur crée un fichier liste de lecture maître (« master playlist file » en terminologie anglo-saxonne), contenant les URI de chacun des fichiers liste de lecture et pour chaque fichier liste de lecture, le serveur insère une description du premier flux de données correspondant. La description d'un premier flux de données comprend par exemple, un débit du premier flux de données. Le serveur associe le fichier liste de lecture maître à un URI, permettant ainsi à un client d'obtenir le fichier liste de lecture maître. De son côté, un client d'une session de diffusion d'un flux de données selon le protocole HLS obtient, par exemple, lors d'une ouverture d'une connexion HTTP avec un serveur, une description de chaque flux de données disponible sur le serveur. Cette description permet au client de sélectionner un des flux de données disponibles sur le serveur. Lorsqu'il a sélectionné un des flux de données, le client transmet une information représentative du flux de données sélectionné au serveur et reçoit en retour une adresse URI d'un fichier liste de lecture (ou d'un fichier liste de lecture maître) correspondant audit flux de données sélectionné. Le flux de données sélectionné correspond alors au flux de données initial du point de vue du serveur. Le client transmet alors au serveur une requête HTTP contenant l'adresse URI du fichier liste de lecture (respectivement du fichier liste de lecture maître) afin de recevoir ledit fichier liste de lecture (respectivement ledit fichier liste de lecture maître). Lorsque le client reçoit un fichier liste de lecture maître, le client sélectionne un premier flux de données compatible avec des capacités dudit client en utilisant la description associée à chaque premier flux de données contenu dans le fichier liste de lecture maître. Le client transmet ensuite une requête HTTP au serveur contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné. Dès qu'il obtient un fichier liste de lecture, le client peut transmettre des requêtes HTTP au serveur contenant chacune une adresse URI d'un segment qu'il souhaite recevoir. Chaque segment est demandé dans un ordre dépendant de son numéro de séquence.
Lorsqu'un client ayant reçu un fichier liste de lecture maître possède des capacités variables, par exemple des capacités de débit variable, il peut alterner entre plusieurs premiers flux de données en fonction de ses capacités à un instant donné. Dans le protocole FILS, le serveur se charge de définir des paramètres d'adaptation à appliquer au flux de données initial pour obtenir chaque premier flux de données. La définition des paramètres d'adaptation se fait sans concertation avec un client en prenant en compte des capacités de types de clients appartenant à un ensemble de type de clients prédéfini. Le protocole HLS a été défini initialement pour un contexte dans lequel un serveur devait diffuser en direct un flux de données à un grand nombre de clients. Laisser le serveur définir les paramètres d'adaptation sur la base d'un ensemble de types de clients prédéfini est particulièrement cohérent dans ce contexte puisque, pour une question de coût calculatoire, il est impossible pour un serveur de générer autant de premiers flux de données qu'il y a de clients différents. Un inconvénient du protocole HLS est donc qu'un client qui aurait des capacités différentes des types de clients appartenant à l'ensemble de types de clients prédéfini, ne peut pas recevoir un flux de données optimisé pour ses capacités. Il n'a d'autre choix que de se rabattre sur un premier flux de données correspondant à un type de clients de l'ensemble de types de clients prédéfini. Au fil des années, le protocole FILS a été utilisé dans d'autres contextes que le contexte initial pour lequel il a été défini. Ainsi, alors que le protocole FILS était généralement utilisé pour diffuser des flux de données à des clients correspondant effectivement à un type de clients appartenant à l'ensemble de types de clients prédéfini, il est maintenant utilisé pour d'autres clients ayant des capacités différentes de celles des types de clients de l'ensemble de types de clients prédéfini. Par ailleurs, le protocole FILS est maintenant utilisé pour diffuser en direct des flux de données dans des réseaux comportant un faible nombre de clients. Il est souhaitable de pallier ces inconvénients de l'état de la technique. Il est notamment souhaitable de fournir un protocole de diffusion en direct de flux de données permettant une adaptation fine d'un flux de données à un client ne correspondant pas à un type de clients de l'ensemble de types de clients prédéfini. Il est particulièrement souhaitable que ce protocole de diffusion en direct de flux de données soit compatible avec le protocole HLS. Il est de plus souhaitable de fournir une solution qui soit simple à mettre en oeuvre et à faible coût.
Selon un premier aspect de la présente invention, la présente invention concerne un procédé de transmission d'un flux de données entre un serveur et un client utilisant un protocole de diffusion en direct, le procédé comprenant les étapes suivantes mises en oeuvre par le serveur : obtenir un flux de données initial ; recevoir une demande d'informations descriptives pour le flux de données initial de la part dudit client ; vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue en provenance dudit client ; si aucune information représentative d'une capacité dudit client n'a été reçue : adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de clients appartenant à un ensemble de types de clients prédéfinis ; décomposer en segments, dits premier segments, chaque premier flux de données ; et, transmettre audit client une première information descriptive permettant au client de demander une transmission de premiers segments d'au moins un premier flux de données; et si au moins une information représentative d'une capacité dudit client a été reçue : adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; décomposer en segments, dits seconds segments, le second flux de données ; et, transmettre au client une seconde information descriptive permettant au client de demander une transmission de seconds segments du second flux de données. De cette manière, le second client reçoit un second flux de données adapté finement à ses capacités. Dans un mode de réalisation, le protocole de diffusion en direct est le protocole de diffusion en direct basé sur HTTP. Le procédé selon l'invention peut donc être mis en oeuvre par des serveurs et des clients aptes à mettre en oeuvre le protocole de diffusion en direct basé sur HTTP.
Dans un mode de réalisation, la seconde information descriptive est mise sous forme d'un fichier liste de lecture compatible avec le protocole de diffusion en direct. Un client qui saurait lire un fichier liste de lecture compatible avec le protocole de diffusion en direct saurait donc lire le fichier liste de lecture contenant la seconde information descriptive.
Dans un mode de réalisation, la transmission de la seconde information descriptive comprend une transmission au client d'une adresse de chargement du fichier liste de lecture compatible avec le protocole de diffusion en direct. Dans un mode de réalisation, le serveur transmet le fichier liste de lecture compatible avec le protocole de diffusion en direct au client, suite à une réception, en provenance du client, d'une requête HTTP contenant ladite adresse de chargement. Dans un mode de réalisation, le serveur transmet un second segment suite à une réception, en provenance du client, d'une requête HTTP contenant une adresse de chargement correspondant audit second segment, ladite adresse de chargement ayant été obtenue à partir du fichier liste de lecture compatible avec le protocole de diffusion en direct. Dans un mode de réalisation, les capacités du client comprennent un format de compression vidéo supporté et/ou un format de compression audio supporté et/ou un format de compression d'image supporté et/ou un format de sous-titres supporté et/ou un type de réseau utilisé et/ou un débit de réception et/ou une résolution maximum d'image supportée et/ou un nombre de canaux audio supporté. Dans un mode de réalisation, lorsque ledit flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux vidéo et/ou une résolution d'images dudit flux vidéo et/ou une fréquence d'image dudit flux vidéo et/ou une transformation dudit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo, et lorsque ledit flux de données initial comprend un flux audio encodé dans un premier format de compression audio, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux audio et/ou un nombre de canaux audio et/ou une transformation dudit flux audio afin d'assurer une compatibilité avec un second format de compression audio. Selon un deuxième aspect de la présente invention, l'invention concerne un dispositif de type serveur apte à transmettre un flux de données en utilisant un protocole de diffusion en direct, comprenant les moyens suivants : des moyens d'obtention pour obtenir un flux de données initial ; des moyens de réception pour recevoir une demande d'information descriptive pour le flux de données initial de la part d'un client ; des moyens de vérification pour vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue ; des moyens mis en oeuvre lorsqu'aucune information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation pour adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de clients appartenant à un ensemble de type de clients prédéfinis ; des moyens de décomposition pour décomposer en segments, dits premiers segments, chaque premier flux de données ; et, des moyens de transmission pour transmettre à un client une première information descriptive permettant au client de demander une transmission des premiers segments d'au moins un premier flux de données; des moyens mis en oeuvre lorsqu'au moins une information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation pour adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; des moyens de décomposition pour décomposer en segments, dits seconds segments, le second flux de données ; et, des moyens de transmission pour transmettre au client une seconde information descriptive permettant au client de demander une transmission de seconds segments du second flux de données. Selon un troisième aspect de la présente invention, l'invention concerne un dispositif de type client apte à recevoir un flux de données en utilisant le protocole de diffusion en direct basé sur HTTP, comprenant les moyens suivants : des moyens de transmission pour transmettre au moins une information représentative d'une capacité dudit dispositif de type client à un serveur ; des moyens pour recevoir un fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP, le fichier texte correspondant à un fichier de données initial et permettant d'obtenir des adresses de chargement de segments correspondant à un flux de données, dit second flux de données, résultant d'une adaptation par le serveur du flux de données initial à chaque capacité dudit dispositif de type client ; des moyens de transmission pour transmettre une requête contenant une adresse de chargement d'un segment du second flux de données, l'adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP ; des moyens de réception pour recevoir le segment correspondant à la requête transmise. Selon un quatrième aspect de la présente invention, l'invention concerne un système de transmission d'un flux de données comprenant un serveur selon le deuxième aspect et au moins un client selon le troisième aspect.
Selon un cinquième aspect de la présente invention, l'invention concerne un programme d'ordinateur, comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur du dispositif Selon un sixième aspect de la présente invention, l'invention concerne des moyens de stockage, stockant un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur dudit dispositif Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 illustre schématiquement un exemple de système dans lequel est mis en oeuvre un procédé de transmission de données utilisant un protocole de diffusion en direct ; - la Fig. 2A illustre schématiquement un exemple d'architecture matérielle d'un dispositif client mettant en oeuvre l'invention ; - la Fig. 2B illustre schématiquement un exemple d'architecture matérielle d'un dispositif serveur mettant en oeuvre l'invention ; - La Fig. 3A illustre schématiquement un exemple de mise en oeuvre d'un procédé selon l'invention ; - les Figs. 3B et 3C illustrent schématiquement un exemple de mise en oeuvre du procédé de type protocole HLS par un serveur ; - la Fig. 3D illustre schématiquement un exemple de mise en oeuvre d'un procédé de type protocole HLS par un client ; - les Figs. 4A et 4B illustrent schématiquement un exemple d'une mise en oeuvre par un serveur d'un procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données à des capacités d'un client; et, - la Fig. 4C illustre schématiquement un exemple d'une mise en oeuvre par un client du procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités du client. Par la suite l'invention est décrite dans le cadre du protocole HLS. L'invention est toutefois adaptée à d'autres protocoles ou procédés de diffusion en direct de flux de données entre un serveur et au moins un client possédant un fonctionnement similaire au protocole FILS. Par ailleurs, l'invention est décrite dans le cadre d'un réseau local (« Local Area Network » en terminologie anglo-saxonne) dans lequel un serveur multimédia (« set top box » en terminologie anglo-saxonne) obtient un flux de données à partir d'un réseau, tel que le réseau internet, à travers une passerelle réseau (« gateway » en terminologie anglo-saxonne) et diffuse des flux de données vers des clients du réseau local. L'invention est toutefois adaptée à d'autres contextes dans lesquels un serveur diffuse à travers un réseau un flux de données vers au moins un client. La Fig. 1 illustre schématiquement un exemple de système dans lequel est mis en oeuvre un procédé de transmission de données utilisant un protocole de diffusion en direct. Le système comprend une passerelle réseau 12 reliée par un lien réseau 11, tel qu'un lien Ethernet, à un réseau 10, tel que le réseau Internet. La passerelle réseau 12 est un point d'entrée vers un réseau local. Ce réseau local comprend un serveur 14, tel qu'un serveur multimédia ou un décodeur TV, connecté à la passerelle réseau 12 par un lien réseau 13 tel qu'un lien Ethernet, un lien sans fils ou un lien CPL (Courant Porteur en Ligne). Le serveur 14 est relié à un client 16 par un lien réseau 15, tel qu'un lien Ethernet, un lien sans fils ou un lien CPL. Le client 16 peut être par exemple un téléviseur, un ordinateur, une tablette ou un téléphone intelligent (« smart phone » en terminologie anglo-saxonne).
La passerelle réseau 12 reçoit des flux de données encapsulés dans des paquets TCP (protocole de contrôle de transmission, « Transmission Control Protocol », RFC 793), RTP (protocole de transmission temps réel, « Real-time Transmission Protocol », RFC 1889) ou UDP (protocole de datagramme utilisateur, « User Datagram Protocol » en terminologie anglo-saxonne). Chaque flux de données est ensuite extrait des paquets par la passerelle réseau 12 et fourni au serveur 14 sous forme de flux de transport MPEG TS (« Moving Picture Expert Group Transport Stream part 1», ISO/IEC 13818-1). Chaque flux de transport MPEG TS peut contenir au moins un flux vidéo et/ou au moins un flux audio et/ou au moins un flux de métadonnées tel qu'un flux de sous titres. Lorsque le client 16 choisit un flux de données initial disponible sur le serveur 14, le serveur 14 génère une pluralité de premiers flux de données selon un procédé que nous décrivons en relation avec la Fig. 3B. Après une sélection par le client 16 d'un des premier flux de données, une diffusion du premier flux de données sélectionné, selon un procédé décrit en relation avec les Figs. 3C et 3D, est mise en oeuvre.
Les Figs. 4A, 4B et 4C décrivent une variante des procédés décrits en relation avec les Figs. 3A, 3B et 3C, cette variante permettant une adaptation fine d'un flux de données initial à un client ne correspondant pas à un type de clients de l'ensemble de types de clients prédéfini.
La Fig. 3A illustre schématiquement un exemple de mise en oeuvre d'un procédé selon 1 ' invention. Dans une étape 30, le serveur 14 obtient un ensemble de flux de données. Cet ensemble de flux de données peut, par exemple, être obtenu à partir d'une mémoire du serveur 14 ou fourni par la passerelle réseau 12. Une information représentant les flux de données disponibles sur le serveur 14 est alors diffusée au client 16. Le client 16 sélectionne l'un des flux de données disponible, et transmet une information représentant le flux de données sélectionné au serveur 14. Le flux de données sélectionné par le client 16 devient alors le flux de données initial. Lors d'une étape 31, le serveur 14 reçoit l'information représentant le flux de données sélectionné transmise par le client 16. La réception de l'information représentant le flux de données sélectionné fait office de réception d'une demande d'informations descriptives pour le flux de données initial. Dans une étape 32, le serveur 14 vérifie qu'il a reçu une information représentative des capacités du client 16. L'information représentative des capacités du client 16 a pu avoir été reçue préalablement à la réception de l'information représentant le flux de données sélectionné ou le serveur peut, à la suite de la réception de l'information représentant le flux de données sélectionné, se mettre en attente de réception d'au moins une information représentative des capacités du client 16 pendant un temps prédéfini.
Si après une durée égale au temps prédéfini le serveur 14 n'a reçu aucune information représentative des capacités du client 16, il met en oeuvre le protocole HLS lors d'une étape 33. Un exemple de mise en oeuvre du protocole HLS par le serveur 14 est décrit en relation avec les Figs. 3B et 3C. Si, lors de l'étape 32, le serveur 14 constate qu'il a reçu au moins une information représentative des capacités du client 16, il met en oeuvre, lors d'une étape 34, un procédé permettant une adaptation fine du flux de données initial aux capacités du client 16. Un exemple de mise en oeuvre par le serveur 14 du procédé permettant une adaptation fine du flux de données initial aux capacités du client 16 est décrit en relation avec les Figs. 4A et 4B.
Dans un mode de réalisation, le serveur 14 diffuse l'information représentant les flux de données disponibles sur le serveur 14 avant d'avoir reçu effectivement les flux de données correspondants. C'est alors la réception par le serveur de la demande d'informations descriptives pour un flux de données qui déclenche l'obtention effective par le serveur 14 du flux de données demandé. Les Figs. 3B et 3C illustrent schématiquement un exemple de mise en oeuvre du protocole FILS par le serveur 14. Dans une étape 302, le serveur 14 adapte le flux de données initial pour obtenir une pluralité de premiers flux de données. Chaque premier flux de données est adapté à des capacités respectives d'un type de clients appartenant à un ensemble de types de clients prédéfinis. Les capacités d'un client comprennent par exemple : - un format de compression vidéo supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression vidéo suivants : MPEG-2 (ISO/IEC 13818-2), MPEG-4 partie 2 (ISO/CEI 14496-2), H264/AVC (ISO/IEC 14496-10 - MPEG-4 Part 10, codage vidéo avancé (« Advanced Video Coding » en terminologie anglo-saxonne) / ITU-T H.264), HEVC (ISO/IEC 23008-2 - MPEG-H Part 2, codage vidéo haute efficacité (High Efficiency Video Coding en terminologie anglo-saxonne) / ITU-T H.265), - un format de compression audio supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression audio suivants : MP3(MPEG-1 niveau III), AAC (Codage Audio Avancé, « Advanced Audio Coding » en terminologie anglo-saxonne), - un format de compression d'images supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression d'image suivants : JPEG (ISO/CEI 10918-1/UIT-T Recommandation T.81), JPEG2000 (ISO/CEI 15444-1), - si le client possède des moyens de décodage de sous-titres, - un type de réseau utilisé par le client : Ethernet, Wi-Fi, CPL, - un débit de réception, - une résolution maximum d'images supportée par le client, - un nombre de canaux audio supporté par le client. Plusieurs types d'adaptation peuvent être appliqués à un flux de données initial lors de l'obtention des premiers sous-flux de données. Lorsqu'un flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, un transcodage peut être appliqué au flux vidéo afin de réduire un débit dudit flux vidéo et/ou de réduire une résolution d'images dudit flux vidéo et/ou de réduire une fréquence d'images dudit flux vidéo et/ou de transformer ledit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo. Lorsqu'un flux de données initial comprend un flux audio encodé dans un premier format de compression audio, un transcodage peut être appliqué au flux audio afin de réduire un débit dudit flux audio et/ou de réduire un nombre de canaux dudit flux audio et/ou de transformer ledit flux audio afin d'assurer une compatibilité avec un second format de compression audio. D'autres types d'adaptation peuvent comprendre une suppression d'un flux de sous-titres lorsqu'un type de clients de l'ensemble de types de clients prédéfini n'est pas en capacité de décoder ledit flux de sous titres. Dans une étape 303, le serveur 14 décompose en segments, dits premiers segments, chaque premier flux de données. Lors de l'étape 303, le serveur 14 associe chaque segment à une information représentative dudit segment comprenant une adresse URI, un numéro de séquence et une taille dudit segment. Lors d'étapes 304 et 305, le serveur 14 transmet au client 16, une première information descriptive permettant d'obtenir, pour chaque premier flux de données, au moins une caractéristique dudit premier flux de données et pour chaque premier segment, une adresse de chargement dudit premier segment. La première information descriptive permet au client 16 de demander une transmission de premiers segments en fonction de capacités du client 16 afin d'obtenir une version du flux de données initial adaptée auxdites capacités. Lors de l'étape 304, le serveur 14 crée un fichier liste de lecture pour chaque premier flux de données. Pour chaque premier flux de données, le serveur 14 insère l'information représentative de chaque segment dudit premier flux de données qu'il souhaite rendre accessible au client 16 dans le fichier liste de lecture correspondant audit premier flux de données. Suite à la création des fichiers liste de lecture, le serveur 14 alloue une adresse URI à chaque fichier liste de lecture. Un fichier liste de lecture maître est ensuite créé, dans lequel le serveur 14 insère, pour chaque premier flux de données, l'adresses URI du fichier liste de lecture correspondant audit premier flux de données et une description dudit premier flux de données. Une description d'un premier flux de données comprise dans un fichier liste de lecture maître peut, par exemple, indiquer pour quel type de clients de l'ensemble de types de clients prédéfini le premier flux de données a été adapté et/ou un débit du premier flux de données et/ou une résolution d'image d'un flux vidéo contenu dans le premier flux de données et/ou une fréquence d'image d'un flux vidéo contenu dans le premier flux de données et/ou un nombre de canaux audio d'un flux audio contenu dans le premier flux de données. Par la suite, le serveur 14 associe une adresse URI au fichier liste de lecture maître et envoie cette adresse URI au client 16 lors de l'étape 305. Cette adresse URI étant, pour le client 16, la première information descriptive permettant d'obtenir une version du flux de données initial. Dans une étape 311, le serveur 14 reçoit en provenance du client 16, une requête HTTP contenant l'URI du fichier liste de lecture maître. Suite à la réception de cette requête, le serveur 14 transmet le fichier liste de lecture maître au client 16 pour qu'il sélectionne un des premiers flux de données. Suite à cette sélection, le serveur 14 reçoit une requête HTTP contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné.
Lors d'une étape 312, le serveur 14 transmet au client 16 le fichier liste de lecture correspondant au flux de données sélectionné. Dans une étape 313, le serveur 14 vérifie s'il a reçu une requête HTTP contenant une adresse URI d'un premier segment demandé par le client 16. Si c'est le cas, lors d'une étape 315, le serveur 14 transmet le premier segment demandé au client 16 et retourne à l'étape 313. Si aucune requête HTTP pour un nouveau segment n'est reçue pendant une durée prédéfinie ou que le dernier segment transmis est un segment final du premier flux de données, le serveur 14 met fin à la diffusion du premier flux de données au cours d'une étape 314. La Fig. 3D illustre schématiquement un exemple de mise en oeuvre du protocole FILS par le client 16. Le client 16 est supposé avoir sélectionné un flux de données initial parmi un ensemble de flux de données disponibles sur le serveur 14. Dans cet exemple, le client 16 n'a pas transmis ses capacités au serveur 14. Le client 16 a donc reçu l'adresse URI du fichier liste de lecture maître correspondant au flux de données initial sélectionné transmise lors de l'étape 305.
Dans une étape 321, à un moment choisi, par exemple, par un utilisateur du client 16, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI du fichier liste de lecture maître correspondant au flux de données initial qu'il a sélectionné. En retour, le client 16 reçoit de la part du serveur 14, ledit fichier liste de lecture maître. Le client 16 sélectionne alors un premier flux de données parmi les premiers flux de données mentionnés dans le fichier liste de lecture maître en utilisant les descriptions de chaque premier flux de données. Lors de cette sélection, le client 16 compare les capacités dudit client 16 avec les informations contenues dans les descriptions de chaque premier flux de données. Si le client 16 correspond à un type de clients compris dans l'ensemble de types de clients prédéfini, le client 16 choisit le premier flux de données correspondant à ce type de clients de l'ensemble prédéfini. Si le client 16 ne correspond pas à un type de clients représenté dans l'ensemble de types de clients prédéfinis, le client 16 choisit un premier flux de données ayant des caractéristiques les plus proches possibles des capacités du client 16.
Après avoir sélectionné un des premiers flux de données, le client 16 transmet au serveur 14 une requête contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné. Lors d'une étape 322, le client 16 reçoit le fichier liste de lecture correspondant au premier flux de données qu'il a sélectionné.
Dans une étape 323, le client 16 recherche dans le fichier liste de lecture un premier segment à demander au serveur 14. Lorsque le client 16 demande pour la première fois un premier segment pour le premier flux de données qu'il a sélectionné, le client 16 sélectionne en général le premier segment ayant le numéro de séquence le plus faible dans le fichier liste de lecture qu'il a reçu.
Dans une étape 324, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit premier segment sélectionné. Dans une étape 325, le client 16 reçoit ledit premier segment et fournit ce premier segment à un module de décodage prenant en charge un décodage du premier segment.
Dans une étape 326, le client 16 vérifie si la diffusion du flux de données initial qu'il a sélectionné doit être poursuivie. La diffusion d'un flux de données peut, par exemple, être contrôlée par un utilisateur du client 16. Si la diffusion doit être poursuivie, le client 16 met de nouveau en oeuvre l'étape 323 et demande le premier segment suivant le premier segment précédemment demandé, i.e. le premier segment ayant un numéro de séquence incrémenté d'une unité par rapport au numéro de séquence du premier segment précédemment demandé. Si la diffusion ne doit pas être poursuivie, le client 16 y met fin lors d'une étape 327. Dans un mode de réalisation adapté à un client ayant des capacités variant dans le temps, lors de l'étape 321, le client 16 peut transmettre au serveur 14 une requête HTTP contenant toutes les adresses URI contenues dans le fichier liste de lecture maître. De cette manière le client 16 reçoit chaque fichier liste de lecture correspondant au flux de données initial qu'il a sélectionné. Lors de l'étape 326, si la diffusion du flux de données initial doit être poursuivie, le client 16 sélectionne un premier flux de données compatible avec des capacités du client 16 constatées au moment de la mise en oeuvre de l'étape 326. Le client 16 sélectionne ensuite le prochain segment à demander au serveur dans le fichier liste de lecture correspondant au premier flux de données sélectionné lors de l'étape 326. L'exemple de mise en oeuvre du protocole FILS décrit en relation avec les Figs. 10 3B, 3C et 3D montre que le protocole HLS actuel ne permet pas une adaptation fine du flux de données aux capacités du client 16. Les Figs. 4A et 4B illustrent schématiquement un exemple d'une mise en oeuvre par le serveur 14 d'un procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités d'un client. Ce procédé 15 correspond à l'étape 34 décrite en relation avec la Fig. 3A. Dans une étape 402 suivant l'étape 32, de la même manière que le serveur 14 avait adapté le flux de données initial aux capacités respectives des types de clients de l'ensemble de types de clients prédéfini pour obtenir les premiers flux de données, le serveur 14 adapte le flux de données initial à chaque capacité du client 16 reçue pour 20 obtenir un second flux de données. Dans une étape 403, le serveur 14 décompose en segments, dits seconds segments, le second flux de données. Chaque second segment est associé à une adresse URI. Lors d'étapes 404 et 405, le serveur 14 transmet au client 16 une seconde 25 information descriptive permettant d'obtenir, pour chaque second segment, l'adresse URI dudit second segment. La seconde information descriptive permet au client 16 de demander une transmission des seconds segments afin d'obtenir le second flux de données. Lors de l'étape 404, le serveur 14 crée un fichier liste de lecture et y insère les 30 adresses URI, les numéros de séquence et les durées des seconds segments. Le serveur 14 alloue ensuite une adresse URI au fichier liste de lecture ainsi créé. Lors de l'étape 405, l'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments est transmise au client 16. L'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments correspond à la seconde information descriptive permettant au client 16 de demander une transmission des seconds segments afin d'obtenir le second flux de données. Dans une étape 411, le serveur 14 reçoit une requête HTTP en provenance du client 16 contenant l'adresse URI du fichier liste de lecture contenant les adresses URI des second segments. Dans une étape 412, le serveur 14 transmet le fichier liste de lecture contenant les adresse URI des seconds segments au client 16. Dans une étape 415, suite à une réception, lors d'une étape 413, d'une requête HTTP contenant une adresse URI d'un second segment en provenance du client 16, le serveur 14 transmet au client 16 le second segment correspondant à ladite adresse URI. L'adresse URI dudit second segment a été obtenue par le client 16 à partir du fichier liste de lecture transmis par le serveur 14. Si, lors de l'étape 413, aucune requête HTTP pour un nouveau segment n'est reçue pendant une durée prédéfinie ou que le dernier segment transmis est un segment final du second flux de données, le serveur 14 met fin à la diffusion du second flux de données au cours d'une étape 414. La Fig. 4C illustre schématiquement un exemple d'une mise en oeuvre par un client du procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités du client.
Dans une étape 420, le client 16 transmet au serveur 14 une information représentative de ses capacités. Dans une étape 421, à un moment choisi, par exemple, par un utilisateur du client 16, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments. En retour, le client 16 reçoit de la part du serveur 14, ledit fichier liste de lecture lors d'une étape 422. Dans une étape 423, le client 16 recherche dans le fichier liste de lecture un second segment à demander au serveur 14. Lorsque le client 16 demande pour la première fois un second segment, le client 16 sélectionne en général le second segment ayant le numéro de séquence le plus faible dans le fichier liste de lecture qu'il a reçu. Dans une étape 424, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit second segment sélectionné.
Dans une étape 425, le client 16 reçoit ledit second segment et fournit ce second segment à un module de décodage prenant en charge un décodage du second segment. Dans une étape 426, le client 16 vérifie si la diffusion du flux de données initial qu'il a sélectionné doit être poursuivie. Si la diffusion doit être poursuivie, le client 16 met de nouveau en oeuvre l'étape 423 et demande le second segment suivant le segment précédemment demandé, i.e. le second segment ayant un numéro de séquence incrémenté d'une unité par rapport au numéro de séquence du second segment précédemment demandé. Si la diffusion ne doit pas être poursuivie, le client 16 y met fin lors d'une étape 427.
Dans un mode de réalisation, le client 16 peut ouvrir une connexion HTTP avec le serveur 14 pour transmettre ses capacités. Cette connexion peut être fermée par le serveur dès réception des capacités du client 16. Dans un mode de réalisation, le procédé décrit en relation avec la Fig. 4C pourrait être mis en oeuvre par un second client non représenté dans la Fig. 1. Dans ce cas le client 16 serait compatible avec le protocole FILS alors que le second client serait compatible avec le protocole FILS et le procédé décrit en relation avec les Figs. 4A, 4B et 4C. Dans un mode de réalisation, lors de l'étape 402, le serveur 14 génère aussi des premiers flux de données tels que décrits en relation avec l'étape 302. Lors de l'étape 403, le serveur 14 génère aussi des premiers segments tels que décrits en relation avec l'étape 303. Lors de l'étape 404, le serveur 14 génère aussi un fichier liste de lecture pour chaque premier flux de données tel que décrit en relation avec l'étape 304. Les adresses URI des fichiers liste de lecture correspondant aux premiers flux de données et au second flux de données sont insérées dans un fichier liste de lecture maître. Lors de l'étape 405, l'adresse URI du fichier liste de lecture maître est transmise au client 16. Dans ce mode de réalisation, le client 16 peut choisir parmi les premiers flux de données et le second flux de données, le flux de données le plus approprié à ses capacités à un instant donné. Dans ce mode de réalisation, un autre client que le client 16 pourrait aussi recevoir le fichier liste de lecture maître et choisir parmi les premiers flux de données et le second flux de données, le flux de données le plus approprié à ses capacités. Ainsi, un client qui n'implémenterait pas le procédé décrit en relation avec la Fig. 4C, mais uniquement le protocole FILS, pourrait recevoir le second flux de données si ses capacités sont plus proches de celles du client 16 que de celles des types de clients de l'ensemble de types de clients prédéfini.
Dans un mode de réalisation, le client 16 peut envoyer au serveur 14 de nouvelles informations représentatives de ses capacités à intervalles réguliers ou lorsque ses capacités ont évolué de manière significative par rapport aux dernières capacités envoyées. L'envoi de nouvelles informations représentatives des capacités du client 16 provoque une nouvelle adaptation du flux de données initial par le serveur 14 pour générer un nouveau second flux de données adapté aux nouvelles capacités. La Fig. 2A illustre schématiquement un exemple d'architecture matérielle d'un dispositif client mettant en oeuvre le protocole FILS et/ou le procédé décrit en relation avec la Fig. 4C. Nous prenons ici l'exemple du client 16. Le client 16 comprend alors, reliés par un bus de communication 165 : un processeur ou CPU (« Central Processing Unit » en anglais) 160; une mémoire vive RAM (« Random Access Memory » en anglais) 161 ; une mémoire morte ROM (« Read Only Memory » en anglais) 162 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD (« Secure Digital » en anglais) 163 ; un ensemble 164 d'interfaces de connexion permettant de connecter le client 16 au serveur 14. Le processeur 160 est capable d'exécuter des instructions chargées dans la RAM 161 à partir de la ROM 162, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque le client 16 est mis sous tension, le processeur 160 est capable de lire de la RAM 161 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 160, de tout ou partie des procédés décrits en relation avec les Figs. 3C et 4C. La Fig. 2B illustre schématiquement un exemple d'architecture matérielle d'un dispositif serveur mettant en oeuvre l'invention. Nous prenons ici l'exemple du serveur 14. Le serveur 14 comprend alors, reliés par un bus de communication 145 : un processeur ou CPU (« Central Processing Unit » en anglais) 140 ; une mémoire vive RAM (« Random Access Memory » en anglais) 141 ; une mémoire morte ROM (« Read Only Memory » en anglais) 142; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD (« Secure Digital » en anglais) 143 ; un ensemble 144 d'interfaces de connexion permettant de connecter le serveur 14 au client 16 et à la passerelle réseau 12. Le processeur 140 est capable d'exécuter des instructions chargées dans la RAM 141 à partir de la ROM 142, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque le serveur 14 est mis sous tension, le processeur 140 est capable de lire de la RAM 141 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 140, de tout ou partie des procédés décrits en relation avec les Figs. 3A, 3B, 4A et 4B.
Tout ou partie de l'algorithme décrit en relation avec les Figs.
3A, 3B, 3C, 4A, 4B et 4C peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, telle qu'un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA (« Field- Programmable Gate Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais).

Claims (13)

  1. REVENDICATIONS1) Procédé de transmission d'un flux de données entre un client et un serveur utilisant un protocole de diffusion en direct, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes mises en oeuvre par le serveur : obtenir (30) un flux de données initial ; recevoir (31) une demande d'informations descriptives pour le flux de données initial de la part dudit client ; vérifier (32) qu'au moins une information représentative d'une capacité dudit client a été reçue en provenance dudit client ; si aucune information représentative d'une capacité dudit client n'a été reçue : adapter (302) le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de client appartenant à un ensemble de types de client prédéfinis ; décomposer (303) en segments, dits premier segments, chaque premier flux de données ; et, transmettre (304, 305) audit client une première information descriptive permettant au client de demander (324) une transmission de premiers segments d'au 20 moins un premier flux de données; et si au moins une information représentative d'une capacité dudit client a été reçue : adapter (402) ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; 25 décomposer (403) en segments, dits seconds segments, le second flux de données ; et, transmettre (404, 405) au client une seconde information descriptive permettant au client de demander (424) une transmission de seconds segments du second flux de données. 30
  2. 2) Procédé selon la revendication 1, caractérisé en ce que le protocole de diffusion en direct est le protocole de diffusion en direct basé sur HTTP.
  3. 3) Procédé selon la revendication 2, caractérisé en ce que la seconde information descriptive est mise sous forme d'un fichier liste de lecture compatible avec le protocole de diffusion en direct (404).
  4. 4) Procédé selon la revendication 3, caractérisé en ce que la transmission de la seconde information descriptive comprend une transmission (405) au client d'une adresse de chargement du fichier liste de lecture compatible avec le protocole de diffusion en direct.
  5. 5) Procédé selon la revendication 4, caractérisé en ce que le serveur transmet (412) le fichier liste de lecture compatible avec le protocole de diffusion en direct au client, suite à une réception (411), en provenance du client, d'une requête HTTP contenant ladite adresse de chargement.
  6. 6) Procédé selon la revendication 5, caractérisé en ce que le serveur transmet (415) un second segment suite à une réception (413), en provenance du client, d'une requête HTTP contenant une adresse de chargement correspondant audit second segment, ladite adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct.
  7. 7) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les capacités du client comprennent un format de compression vidéo supporté et/ou un format de compression audio supporté et/ou un format de compression d'image supporté et/ou un format de sous-titres supporté et/ou un type de réseau utilisé et/ou un débit de réception et/ou une résolution maximum d'image supporté et/ou un nombre de canaux audio supporté.
  8. 8) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, lorsque ledit flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux vidéo et/ou une résolution d'images dudit flux vidéo et/ou une fréquence d'image dudit flux vidéo et/ou une transformation dudit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo, et lorsque ledit flux de données initial comprendun flux audio encodé dans un premier format de compression audio, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux audio et/ou un nombre de canaux audio et/ou une transformation dudit flux audio afin d'assurer une compatibilité avec un second format de compression audio.
  9. 9) Dispositif de type serveur apte à transmettre un flux de données en utilisant un protocole de diffusion en direct, comprenant les moyens suivants : des moyens d'obtention (30) pour obtenir un flux de données initial ; des moyens de réception (31) pour recevoir une demande d'information descriptive pour le flux de données initial de la part d'un client ; des moyens de vérification (32) pour vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue ; des moyens (33) mis en oeuvre lorsqu'aucune information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation (302) pour adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de client appartenant à un ensemble de types de clients prédéfinis ; des moyens de décomposition (303) pour décomposer en segments, dits premiers segments, chaque premier flux de données ; et, des moyens de transmission (304, 305) pour transmettre à un client une première information descriptive permettant au client de demander (324) une transmission des premiers segments d'au moins un premier flux de données; des moyens (34) mis en oeuvre lorsqu'au moins une information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation (402) pour adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; des moyens de décomposition (403) pour décomposer en segments, dits seconds segments, le second flux de données ; et, des moyens de transmission (404, 405) pour transmettre au client une seconde information descriptive permettant au client de demander (424) une transmission de seconds segments du second flux de données.
  10. 10) Dispositif de type client apte à recevoir un flux de données en utilisant le protocole de diffusion en direct basé sur HTTP, comprenant les moyens suivants : des moyens de transmission pour transmettre au moins une information représentative d'une capacité dudit dispositif de type client à un serveur ; des moyens pour recevoir un fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP, le fichier texte correspondant à un fichier de données initial et permettant d'obtenir des adresses de chargement de segments correspondant à un flux de données, dit second flux de données, résultant d'une adaptation par le serveur du flux de données initial à chaque capacité dudit dispositif de type client ; des moyens de transmission pour transmettre une requête contenant une adresse de chargement d'un segment du second flux de données, l'adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP ; et, des moyens de réception pour recevoir le segment correspondant à la requête transmise.
  11. 11) Système de transmission d'un flux de données comprenant un serveur selon la revendication 9 et au moins un client selon la revendication 10.
  12. 12) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en oeuvre, par un dispositif, le procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté par un processeur du dispositif.
  13. 13) Moyens de stockage, caractérisés en ce qu'ils stockent un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté par un processeur dudit dispositif 25 30
FR1550342A 2015-01-16 2015-01-16 Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct. Expired - Fee Related FR3031862B1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR1550342A FR3031862B1 (fr) 2015-01-16 2015-01-16 Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct.
US15/541,133 US20180198834A1 (en) 2015-01-16 2016-01-14 Method for transmitting a data stream using a streaming protocol
EP16700626.1A EP3245794A1 (fr) 2015-01-16 2016-01-14 Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct
CN201680005854.6A CN107211166A (zh) 2015-01-16 2016-01-14 用于使用直接广播协议发送数据流的方法
PCT/EP2016/050697 WO2016113364A1 (fr) 2015-01-16 2016-01-14 Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct
BR112017014537A BR112017014537A2 (pt) 2015-01-16 2016-01-14 processo de transmissão de um fluxo de dados utilizando um protocolo de difusão diretamente.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1550342A FR3031862B1 (fr) 2015-01-16 2015-01-16 Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct.

Publications (2)

Publication Number Publication Date
FR3031862A1 true FR3031862A1 (fr) 2016-07-22
FR3031862B1 FR3031862B1 (fr) 2017-02-17

Family

ID=53269627

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1550342A Expired - Fee Related FR3031862B1 (fr) 2015-01-16 2015-01-16 Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct.

Country Status (6)

Country Link
US (1) US20180198834A1 (fr)
EP (1) EP3245794A1 (fr)
CN (1) CN107211166A (fr)
BR (1) BR112017014537A2 (fr)
FR (1) FR3031862B1 (fr)
WO (1) WO2016113364A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11102259B2 (en) * 2019-01-22 2021-08-24 Apple Inc. Network system for content playback on multiple devices
CN111917511B (zh) * 2020-07-06 2024-01-30 青岛海尔科技有限公司 一种数据的接收方法
CN117097813B (zh) * 2023-10-19 2024-01-26 广州宇中网络科技有限公司 协议适配方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2566172A1 (fr) * 2011-09-02 2013-03-06 Thomson Licensing Procédé et appareil pour le transcodage adaptatif d'un flux multimédia
WO2014058431A1 (fr) * 2012-10-11 2014-04-17 Affirmed Networks, Inc. Extension d'un jeu de flux de données et transcodage de vidéos sur internet s'adaptant au protocole http dans un réseau mobile
EP2744215A1 (fr) * 2012-12-17 2014-06-18 Thomson Licensing Procédé de transmission en continu de contenu AV et procédé de présentation de contenu AV
US20140359166A1 (en) * 2013-05-31 2014-12-04 Broadcom Corporation Providing multiple abr streams using a single transcoder

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250308A1 (en) * 2004-08-31 2007-10-25 Koninklijke Philips Electronics, N.V. Method and device for transcoding
US8947492B2 (en) * 2010-06-18 2015-02-03 Microsoft Corporation Combining multiple bit rate and scalable video coding
BR112013016607A2 (pt) * 2010-12-30 2017-09-26 Thomson Licensing método de processamento de um conteúdo de vídeo que permite a adaptação a diversos tipos de dispositivos de exibição
CN102111685B (zh) * 2011-02-24 2012-07-25 深信服网络科技（深圳）有限公司 一种网络视频加载的加速方法、设备及系统
EP2730072B1 (fr) * 2011-07-07 2016-09-07 Telefonaktiebolaget LM Ericsson (publ) Capacité de réseau optimisé pour le streaming http adaptatif
US8762452B2 (en) * 2011-12-19 2014-06-24 Ericsson Television Inc. Virtualization in adaptive stream creation and delivery
PL2798816T3 (pl) * 2011-12-29 2016-11-30 Inicjowane sieciowo sterowanie strumieniowego przesyłania zawartości
US9584573B2 (en) * 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
CN102932670B (zh) * 2012-11-29 2015-09-02 百视通网络电视技术发展有限责任公司 一种流媒体切片方法及系统
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US9392307B2 (en) * 2013-07-01 2016-07-12 Ericsson Ab Smart pre-load for video-on-demand in an HTTP adaptive streaming environment
FR3029381A1 (fr) * 2014-11-27 2016-06-03 Orange Procede de composition d’une representation video intermediaire

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2566172A1 (fr) * 2011-09-02 2013-03-06 Thomson Licensing Procédé et appareil pour le transcodage adaptatif d'un flux multimédia
WO2014058431A1 (fr) * 2012-10-11 2014-04-17 Affirmed Networks, Inc. Extension d'un jeu de flux de données et transcodage de vidéos sur internet s'adaptant au protocole http dans un réseau mobile
EP2744215A1 (fr) * 2012-12-17 2014-06-18 Thomson Licensing Procédé de transmission en continu de contenu AV et procédé de présentation de contenu AV
US20140359166A1 (en) * 2013-05-31 2014-12-04 Broadcom Corporation Providing multiple abr streams using a single transcoder

Also Published As

Publication number Publication date
US20180198834A1 (en) 2018-07-12
BR112017014537A2 (pt) 2018-01-16
CN107211166A (zh) 2017-09-26
EP3245794A1 (fr) 2017-11-22
FR3031862B1 (fr) 2017-02-17
WO2016113364A1 (fr) 2016-07-21

Similar Documents

Publication Publication Date Title
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
FR2864407A1 (fr) Procede et dispositif de transmission continue d'une video dans un reseau de communication
EP3225027A1 (fr) Procédé de composition d'une représentation vidéo intermédiaire
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3072303B1 (fr) Diffusion adaptative de contenus multimedia
WO2016113364A1 (fr) Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct
EP2767060B1 (fr) Passerelle, et procédé, programme d'ordinateur et moyens de stockage correspondants
EP3461135A1 (fr) Procédé de gestion du droit d'accès à un contenu numérique
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique au sein d'un terminal de restitution d'un réseau de communication local
WO2021058910A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données
EP3987820A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d'un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d'ordinateur correspondants
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
WO2015181468A1 (fr) Téléchargement de contenu et mise a disposition de réseaux
EP3481069B1 (fr) Procédé et système de traitement d'un contenu multimédia dans un réseau de zone métropolitaine
EP3675505B1 (fr) Procede et systeme de distribution d'un contenu audiovisuel
FR3054765B1 (fr) Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
EP2957104B1 (fr) Procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
FR3124344A1 (fr) Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
EP2879352A1 (fr) Contrôle de la diffusion de contenus multimedia
EP3866432A1 (fr) Transmission de flux de données adaptable
FR2968500A1 (fr) Procede pour le partage d'une emission de television enregistree par des enregistreurs numeriques connectes entre eux.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160722

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

ST Notification of lapse

Effective date: 20220905