FR3092720A1 - Streaming adaptatif et contextuel - Google Patents
Streaming adaptatif et contextuel Download PDFInfo
- Publication number
- FR3092720A1 FR3092720A1 FR1901403A FR1901403A FR3092720A1 FR 3092720 A1 FR3092720 A1 FR 3092720A1 FR 1901403 A FR1901403 A FR 1901403A FR 1901403 A FR1901403 A FR 1901403A FR 3092720 A1 FR3092720 A1 FR 3092720A1
- Authority
- FR
- France
- Prior art keywords
- tracks
- server
- content
- context
- client
- 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
Links
- 230000003044 adaptive effect Effects 0.000 title description 10
- 238000000034 method Methods 0.000 claims description 38
- 230000008859 change Effects 0.000 claims description 20
- 238000004891 communication Methods 0.000 claims description 6
- 238000011156 evaluation Methods 0.000 claims description 4
- 238000007726 management method Methods 0.000 description 19
- 238000006243 chemical reaction Methods 0.000 description 13
- 238000004806 packaging method and process Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 10
- 238000000060 site-specific infrared dichroism spectroscopy Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 7
- 230000006978 adaptation Effects 0.000 description 6
- 238000013459 approach Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000003860 storage Methods 0.000 description 5
- 238000009826 distribution Methods 0.000 description 4
- 230000007613 environmental effect Effects 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 230000008685 targeting Effects 0.000 description 2
- 101150012579 ADSL gene Proteins 0.000 description 1
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 1
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 1
- 206010048865 Hypoacusis Diseases 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
Classifications
-
- 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 or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or manipulating encoded video stream 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/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- 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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
-
- 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44227—Monitoring of local network, e.g. connection or bandwidth variations; Detecting new devices in the local network
-
- 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/64—Addressing
- H04N21/6405—Multicasting
-
- 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/64—Addressing
- H04N21/6408—Unicasting
-
- 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)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Library & Information Science (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
L’invention propose de distribuer du contenu depuis un serveur (100) vers des clients (300), le contenu étant disponible en différentes qualités. Un client reçoit (772), du serveur, un fichier de description (132) définissant une pluralité de qualités différentes du même contenu disponibles en streaming. Au moins une des qualités est également diffusée en mode multicast par le serveur. Le client obtient (752, 774) une information de contexte représentative d’un environnement dans lequel il évolue. Il sélectionne (776) alors en fonction du contexte, une ou plusieurs pistes de contenu, incluant, si le contexte le permet, au moins une correspondant à une des premières qualités du flux multicast, et met uniquement celles-ci à disposition (782, 784, 786) d’un lecteur (310) en mode unicast. Un lecteur classique peut ainsi être utilisé, qui garde le contrôle sur la qualité de contenu récupérée tout en réduisant efficacement la consommation réseau grâce à l’utilisation d’un flux multicast.
Description
La présente invention concerne la diffusion en continu, ou « streaming », adaptative dynamique de contenus (ou «Dynamic Adaptative Streaming» en langue anglo-saxonne).
Pour une diffusion adaptative dynamique, le même contenu source, typiquement un contenu multimédia tel que l’audio-vidéo, est encodé par un serveur en plusieurs flux selon des qualités différentes (et donc paramètres et/ou des débits différents). Un client qui accède au contenu bascule dynamiquement entre ces différents flux (et qualités) en fonction de critères déterminés localement, par exemple des conditions réseau et/ou des conditions de lecture.
Il est classique que le client soit un équipement mobile, tel un téléphone intelligent (smartphone), une tablette, un ordinateur portable, etc. Or, un tel client est amené à changer régulièrement de contexte environnemental, c’est-à-dire de réseau de communication lui permettant d’accéder au serveur de contenu. Par exemple, un smartphone peut être relié à un réseau wifi (nom commercial) résidentiel, puis basculer sur un réseau de télécommunication mobile (type 3G, 4G ou 5G) lorsque l’utilisateur quitte son domicile, puis à nouveau basculer sur un réseau wifi d’un établissement (musée, stade, gare, aéroport) ou moyen de transport (train, avion).
Ces contextes environnementaux présentent des contraintes réseau différentes (notamment en termes de débit et de latence) qui sont parfois excessivement contraignantes (par exemple dans un avion).
Il existe ainsi un besoin d’améliorer les techniques de diffusion ou « streaming » connues pour tenir compte de ces contraintes réseau.
La publication WO 2015/101782 propose de combiner la technique de diffusion adaptative dynamique, dans le cas du MPEG DASH («Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP» - nom commercial), avec une diffusion multicast aux fins de réduire la charge réseau en cas de pic d’accès au contenu par des clients (par exemple lors d’un événement sportif ou, dans ce cas, d’un mariage princier).
A cet effet, un convertisseur côté serveur, c’est-à-dire avant le réseau de diffusion, convertit toutes les qualités du contenu disponibles en mode unicast en des flux multicast (donc de qualités différentes).
Un convertisseur côté client, c’est-à-dire après le réseau de diffusion, s’abonne à ces flux multicast auprès du serveur puis bascule dynamiquement entre ces différents flux multicast en fonction des conditions réseau. Le convertisseur côté client génère également un fichier MPD (pour «media presentation description») en DASH décrivant une unique piste de contenu disponible pour les clients. Le convertisseur convertit alors les datagrammes reçus (des divers flux multicast entre lesquels il bascule dynamiquement) en segments accessibles par un client (c’est-à-dire un lecteur de contenu) en mode unicast pour l’unique piste déclarée dans le fichier MPD. Ce convertisseur côté client utilise également, quand nécessaire, les pistes unicast, par exemple lors de pertes de paquets des flux multicast.
Cette approche, bien que bénéfique par l’utilisation du multicast, présente cependant l’inconvénient d’avoir un lecteur de contenu qui ne choisit pas lui-même la qualité souhaitée (puisque c’est le convertisseur, distinct du lecteur, qui effectue la sélection dynamique) et qui ne connaît pas la qualité réelle du contenu finalement obtenue et affichée. Cette approche s’avère donc contraire à certaines exigences requises pour valider des applications aux fins de les rendre disponibles sur des portails d’applications. De telles exigences requièrent par exemple que l’euristique de choix de la qualité vidéo lue en temps réel (sur réseau cellulaire type 3G, 4G, 5G sur plus de 10 minutes) soit portée par le lecteur vidéo. Cette situation n’est donc pas entièrement satisfaisante pour améliorer les techniques de diffusion ou « streaming » selon les différentes contraintes réseau que le client peut rencontrer. Il est en effet préférable, dans certains environnements normalisés, d’avoir un lecteur de contenu (côté client) qui conserve un contrôle sur le choix final de la qualité de contenu obtenue.
Dans ce contexte, l’invention propose tout d’abord un procédé de distribution de contenu depuis un serveur vers des clients d’un réseau, le contenu étant disponible en différentes qualités. Le procédé comprend les étapes suivantes au niveau d’un client du réseau.
Le client reçoit, du serveur, un ou plusieurs fichiers de configuration définissant une pluralité de pistes correspondant aux qualités différentes du même contenu disponibles aux clients en mode unicast auprès du serveur, au moins une qualité de contenu étant (également) disponible en mode multicast auprès du serveur. Cette ou ces qualités également disponibles en multicast sont appelées « première(s) qualité(s) » dans la suite de ce document.
Un tel fichier de configuration peut notamment être un fichier de description (de présentation média) connu sous l’appellation de « manifest » ou « MPD » pour le protocole DASH, et « liste de lecture maître » ou « master playlist » (en anglais) pour le protocole HLS (pour «HTTP Live Streaming»).En variante, le fichier de configuration peut simplement lister les pistes unicast et multicast, sans avoir le format d’un manifest ou master playlist, ou être une ou plusieurs API serveur, ou tout autre moyen de récupérer des informations à distance.
Le client peut déterminer la ou les premières qualités (c’est-à-dire existantes en multicast) de différentes manières, par exemple à partir du fichier de configuration ou d’un autre fichier de configuration (autre que le manifest) reçu du serveur, à partir d’informations reçues sur un canal distinct (par exemple via un équipement local au client) ou à partir d’une API (application programming interface) avec le serveur. Les informations ainsi reçues permettent au client d’obtenir une liste de l’ensemble des flux multicast disponibles et de leurs qualités associées, ainsi qu’éventuellement les adresses multicast. En variante, l’indication des premières qualités peut être directement prévue dans le fichier de description (manifest ou media playlist par exemple), via notamment des balises propriétaires interprétées par le lecteur vidéo client.
Le client obtient par ailleurs une information de contexte représentative d’un environnement (notamment réseau) dans lequel le client évolue.
Cette information peut être obtenue à partir de caractéristiques propres à un réseau local auquel le client se connecte. Par exemple, le client peut déterminer l’information de contexte à partir d’un identifiant d’une borne d’accès réseau vers le serveur (par exemple adresse IP de la borne), borne à laquelle est connecté le client, ou à partir d’un identifiant d’un réseau local auquel le client est connecté (par exemple le nom SSID, pour «Service Set Identifier», du réseau local). La borne peut être une borne Wifi, une passerelle réseau (Ethernet), une station de base d’un réseau de téléphonie mobile, etc. En variante, le client peut déterminer l’information de contexte à partir de la découverte d’un équipement prédéfini dans un réseau local auquel le client est connecté. Typiquement, la découverte dans le réseau local d’un décodeur grand public (settop box) permet d’inférer qu’il s’agit d’un contexte de domicile. Cet équipement local peut également distribuer des informations au client (par exemple la liste des pistes disponibles en multicast et leurs adresses).
En variante, le client peut déterminer l’information de contexte à partir d’une évaluation de contexte faite et envoyée par le serveur au client. Cette évaluation est ici déterminée à distance par le serveur, par exemple grâce à l’adresse publique IP de la borne/passerelle par laquelle il reçoit des requêtes.
En variante, le client ou le serveur peut combiner des informations de contexte collectées localement ou à distance, pour déterminer, soit localement soit côté serveur, le contexte.
Puis, le client sélectionne, en fonction de l’information de contexte, un jeu de pistes parmi plusieurs jeux comprenant une ou plusieurs pistes de contenu, au moins un jeu de pistes comprenant au moins une piste correspondant à l’au moins une première qualité d’un flux multicast. En d’autres termes, il peut sélectionner un nombre différent de qualités de contenu selon le contexte détecté. Typiquement, il peut s’agir de sélectionner un sous-ensemble des qualités décrites dans le fichier de configuration ou de description reçu. Ce fichier peut déjà avoir été pré-filtré par le serveur avant envoi, sur la base d’une information de contexte, par exemple pour ajouter ou retirer des pistes unicast ou multicast dans le fichier d’origine et dans le fichier/API listant les pistes unicast et multicast, pour participer à la prise de décision. A titre illustratif, le serveur peut avoir modifié l’ordre des pistes selon le contexte, enlevé des pistes basses qualité ou haute qualité, ou tout autre filtrage pertinent selon le contexte.
Par exemple, le client effectue la sélection à partir d’un autre fichier de configuration (par exemple reçu du serveur ou stocké en local) associant, à chaque information de contexte, un jeu de piste listant une ou plusieurs pistes autorisées (et donc qualités) et leurs modes de diffusion respectifs, unicast ou multicast, depuis le serveur. Ainsi, le client sait aisément déterminer les qualités qu’il doit mettre à disposition du lecteur compte tenu du contexte et, parmi celles-ci, celles qu’il récupère en multicast depuis le serveur et celles qui seront accédées directement en unicast auprès du serveur par le lecteur.
A titre d’exemple, l’étape de sélection comprend la sélection, pour une première information de contexte, d’un premier jeu de pistes comportant seulement une ou des pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur. Uniquement cette ou ces premières qualités en mode multicast sont alors conservées et présentées au lecteur vidéo dans ce premier contexte. Un exemple typique d’un tel contexte est le cas d’un avion, où il est important d’empêcher la récupération de vidéo en unicast. En effet, le contexte étant tellement contraint que des récupérations en unicast engorgeraient, de façon désavantageuse, la connexion réseau avec le sol et rendraient l’usage impossible ou fortement dégradé.
Le premier jeu de piste peut ne comporter qu’une seule piste correspondant à la première qualité du flux multicast. En variante, le premier jeu peut comporter deux ou plus premières qualités diffusées en multicast par le serveur. Cette approche permet notamment d’optimiser l’usage du réseau pour des qualités privilégiées par les lecteurs client, par exemple les formats HD et 4K.
De même, l’étape de sélection peut comprendre la sélection, pour une deuxième information de contexte (i.e. différente de la première information), d’un deuxième jeu de pistes comportant une ou des (une seule, deux voire plus) pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur et comportant un sous-ensemble des pistes correspondant à des qualités disponibles en mode unicast auprès du serveur (i.e. telles que définies dans le fichier de description reçu).
Aussi, l’étape de sélection peut comprendre la sélection, pour une troisième information de contexte (i.e. différente des première et deuxième informations), d’un troisième jeu de pistes comportant une ou des (une seule, deux voire plus) pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur et comportant l’ensemble des pistes correspondant aux autres qualités disponibles en mode unicast auprès du serveur.
Par ailleurs, l’étape de sélection peut comprendre pour une quatrième information de contexte (i.e. différente des première, deuxième et troisième information), un quatrième jeu de pistes ne comportant aucune piste correspondant à une première qualité disponible en mode multicast auprès du serveur et comportant l’ensemble (ou un sous-ensemble) des pistes correspondant aux qualités disponibles en mode unicast auprès du serveur. Ce contexte correspond, à titre d’exemple, à un cas où les ouvertures réseau multicast n’auraient pas été réalisées.
La sélection s’opère ainsi parmi un ensemble de jeux de pistes comportant tout ou partie des premier, deuxième, troisième et quatrième jeux. Toute combinaison de ces quatre jeux, complétée ou non d’autres jeux, peut être envisagée.
A noter que certaines informations peuvent devoir être récupérées en parallèle pour un fonctionnement efficace. C’est par exemple le cas de l’identité du client, la liste de chaînes accessibles par le client, ou, plus important encore, la ou les licences DRM nécessaires à la lecture. Généralement, ces données utilisent très peu de ressources réseau et leur récupération présente un impact marginal sur l’utilisation de ces ressources par rapport aux ressources nécessaires pour de la diffusion des contenus (par exemple vidéo) à proprement parler. Aussi, cette récupération peut être effectuée en mode unicast auprès du serveur ou de toute entité idoine même dans un contexte très contraint (avion ou train par exemple) où les contenus sont uniquement récupérés en multicast.
Dans un mode de réalisation, l’étape de sélection peut comprendre en outre l’ajout d’une piste correspondant à une qualité d’un autre flux du contenu reçu via un récepteur de diffusion (en mode broadcast) présent dans un réseau local au client. Il s’agit par exemple d’un décodeur TV recevant en broadcast une chaîne TV qui est également diffusée en streaming par le serveur. Dans ce cas, le client peut accéder à cet autre flux en mode unicast ou multicast auprès du récepteur équipé d’un module de diffusion unicast ou multicast, et peut mettre à disposition du lecteur client, en mode unicast, le flux ainsi récupéré.
Enfin, le client met à disposition d’un lecteur de contenu du client, en mode unicast, la ou les seules qualités de contenu correspondant aux pistes ainsi sélectionnées. Cela permet au lecteur de réaliser une adaptation dynamique de qualité du contenu, c’est-à-dire notamment de garder connaissance de la qualité effectivement choisie. Le lecteur vidéo n’a besoin d’aucune adaptation, et n’est même pas conscient des mécaniques mises en œuvre pour optimiser la réception vidéo, permettant par exemple d’utiliser tel quel les lecteurs vidéo natifs des systèmes d’exploitation, ou des lecteurs vidéo conçus initialement uniquement pour la lecture de vidéo en unicast.
La mise à disposition est classiquement réalisée par l’envoi d’un fichier de description, par exemple manifest ou media playlist, au lecteur vidéo.
Pour réaliser cette mise à disposition du contenu dans la première qualité en utilisant le flux multicast, le client peut s'abonner au flux multicast correspondant à cette première qualité pour recevoir le flux multicast, et convertir le flux multicast reçu en segments accessibles localement, en mode unicast, par le lecteur de contenu demandant cette première qualité de contenu. Cette conversion permet de tirer profit de la diffusion multicast pour réduire l’utilisation de la bande passante réseau dans un environnement collectif.
Dans un mode de réalisation, la mise à disposition comprend des étapes consistant à générer un fichier client de description contenant la ou les seules pistes de contenu sélectionnées (avec possiblement modification de l’ordre et/ou de paramètres tels que des adresses d’accès aux pistes), et à transmettre (localement) le fichier client au lecteur de contenu de sorte que le lecteur de contenu accède par requêtes unicast audit contenu selon une qualité choisie par lui parmi celle ou celles correspondant aux pistes du fichier client. Ce fichier de description est dit « client » car généré localement par le client, à partir du fichier de configuration ou de description reçu du serveur. Aussi, le fichier client de description peut être un fichier modifié du fichier de description reçu.
De préférence, le fichier client de description indique une URL locale (au client) pour la ou les pistes correspondant à l’au moins une première qualité (correspondant à un flux multicast), de sorte que le lecteur sollicite localement le client, et non le serveur, pour l’obtention de segments média selon la première qualité. C’est en effet le client qui, dans ce cas, réalise une conversion du flux multicast récupéré, en segments média. En variante cependant, il est possible, pour ces premières qualités, de conserver les URL réelles distantes (celles du serveur) telles qu’indiquées dans le fichier de configuration/description reçu du serveur, et de les intercepter localement (au niveau du client) pour rediriger les requêtes du lecteur vers un fichier local.
La description des pistes non diffusées en multicast peut rester inchangée par rapport au fichier de description reçu, notamment conservant une URL du serveur où demander les segments media associés, ou être référencée via des URL locales (auquel cas le client s’occupe de récupérer les segments média auprès du serveur pour les mettre à disposition sur ces URL locales).
D’autres réalisations pour la mise à disposition sont envisagées comme par exemple la transmission, au lecteur, du fichier de description reçu (du serveur) complété d’une ou plusieurs pistes correspondant à un ou des flux multicast et éventuellement à un ou des flux broadcast récupérés localement par un récepteur. En variante, seules les descriptions des pistes non également transmises en multicast peuvent être conservées du fichier de description reçu, complétées par une ou plusieurs pistes correspondant à des flux multicast (éventuellement créées à partir des pistes de qualité correspondantes du fichier reçu) et éventuellement à des flux broadcast récupérés localement par un récepteur. Dans ces cas, si le lecteur doit charger un nouveau fichier des segments média propres à la piste choisie (typiquement une liste de lecteur média pour le protocole HLS), le client peut utiliser ce fichier pour contrôler la mise à disposition des seules qualités autorisées : si une qualité/piste non autorisée mais décrite dans le fichier est demandée, un fichier déclarant les segments média manquants ou non disponibles est envoyé (permettant au lecteur vidéo de savoir rapidement qu’il doit changer de piste, avant de recevoir une erreur), alors que si une qualité/piste autorisée est demandée, un fichier déclarant de façon valide les segments média est envoyé. En variante, le client peut rerouter une qualité autorisée par le contexte dans une piste choisie par le lecteur qui ne correspond pas à une qualité autorisée, pour « tromper » le lecteur, permettant de gérer certains cas de changement de contexte plus aisément.
D’une façon générale, l’invention, en proposant une sélection contextuelle des qualités mises à disposition du lecteur incluant une ou plusieurs qualités obtenues via un flux multicast, permet d’optimiser l’utilisation de la bande passante du réseau tout en permettant au lecteur de conserver un contrôle sur le choix de la qualité de contenu et par conséquent sur l’adaptation dynamique (en qualité) de la diffusion du contenu. L’invention s’applique donc particulièrement bien à un streaming vers des clients mobiles évoluant au sein de contextes environnementaux aux contraintes réseau différentes, et utilisant des lecteurs vidéo natifs aux systèmes d’exploitation.
L’invention concerne également un dispositif client connecté à un réseau qui comprend un serveur distribuant du contenu, le contenu étant disponible en différentes qualités. Le dispositif comprend :
- un lecteur de contenu,
- une interface de communication configurée pour recevoir, du serveur, un ou plusieurs fichiers de configuration définissant une pluralité de pistes correspondant aux qualités différentes du même contenu disponibles à des clients en mode unicast auprès du serveur, au moins une première qualité de contenu étant disponible en mode multicast auprès du serveur,
- un module de détermination de contexte configuré pour obtenir une information de contexte représentative d’un environnement dans lequel le dispositif client évolue,
- un module de sélection configuré pour sélectionner, en fonction de l’information de contexte, un jeu de pistes parmi plusieurs jeux comprenant une ou plusieurs pistes de contenu, au moins un jeu de pistes comprenant au moins une piste correspondant à l’au moins une première qualité d’un flux multicast, et
- un module de gestion configuré pour mettre à disposition du lecteur de contenu, en mode unicast, la ou les seules qualités de contenu correspondant aux pistes ainsi sélectionnées.
- un lecteur de contenu,
- une interface de communication configurée pour recevoir, du serveur, un ou plusieurs fichiers de configuration définissant une pluralité de pistes correspondant aux qualités différentes du même contenu disponibles à des clients en mode unicast auprès du serveur, au moins une première qualité de contenu étant disponible en mode multicast auprès du serveur,
- un module de détermination de contexte configuré pour obtenir une information de contexte représentative d’un environnement dans lequel le dispositif client évolue,
- un module de sélection configuré pour sélectionner, en fonction de l’information de contexte, un jeu de pistes parmi plusieurs jeux comprenant une ou plusieurs pistes de contenu, au moins un jeu de pistes comprenant au moins une piste correspondant à l’au moins une première qualité d’un flux multicast, et
- un module de gestion configuré pour mettre à disposition du lecteur de contenu, en mode unicast, la ou les seules qualités de contenu correspondant aux pistes ainsi sélectionnées.
D’autres caractéristiques optionnelles de modes de réalisation de l’invention sont définies dans les ·revendications dépendantes.
Notamment, le procédé peut également comprendre des étapes consistant à :
- détecter un changement d’environnement dans lequel le client évolue et obtenir une nouvelle information de contexte correspondante, et
- sélectionner, en fonction de la nouvelle information de contexte, un nouveau jeu de pistes à mettre à disposition du lecteur de contenu.
- détecter un changement d’environnement dans lequel le client évolue et obtenir une nouvelle information de contexte correspondante, et
- sélectionner, en fonction de la nouvelle information de contexte, un nouveau jeu de pistes à mettre à disposition du lecteur de contenu.
Ce jeu de piste peut inclure ou non, selon le contexte correspondant, la ou les pistes correspondant à l’au moins une première qualité. Il peut s’agir des premier, deuxième, troisième, quatrième jeux évoqués plus haut.
Cette disposition permet de gérer les changements de contexte du client, c’est-à-dire lorsque l’utilisateur se déplace d’un environnement vers un autre environnement ayant des contraintes réseau différentes. Le client peut ainsi par exemple passer de l’un de ces quatre jeux de pistes à un autre, lui offrant d’autres (en plus ou en moins par exemple) qualités disponibles du même contenu.
Dans un mode de réalisation, cette gestion peut comprendre une étape consistant à générer un nouveau fichier client de description en fonction du nouveau jeu de pistes et le transmettre (localement) au lecteur de contenu. Cela permet au lecteur de poursuivre le streaming adaptatif dynamique en fonction des qualités finalement disponibles dans le nouveau contexte. Dans certains modes de réalisation, par exemple lorsque le lecteur demande périodiquement un fichier de description mis à jour, le nouveau fichier client de description peut être récupéré lors de la prochaine demande périodique. Dans ce cas, la restitution du contenu (par exemple affichage sur un écran du client) n’est pas interrompue. En variante cependant, le procédé peut comprendre l’envoi, au lecteur de contenu, d’une notification de relance (relance automatique ou message invitant l’utilisateur à effectuer une telle relance), de sorte que le lecteur de contenu, lorsqu’il est relancé (i.e. redémarré), charge le nouveau fichier modifié, avec un impact aussi minimal que possible pour l’utilisateur.
L’invention concerne également un produit programme d’ordinateur comprenant des instructions configurées pour une mise en œuvre des étapes du procédé ci-dessus lorsque ledit programme est exécuté sur un dispositif électronique, ainsi qu’un support tangible comprenant un tel produit programme d’ordinateur.
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif.
Description détaillée
La présente invention concerne la diffusion, ou « streaming », de contenus média généralement multimédia, tels des films, programmes TV, de la musique, etc.
LaFigure 1illustre schématiquement un système classique 10 de streaming de contenus média, dans lequel peut être mis en œuvre l’invention.
Il comporte un serveur de contenus 100 connecté à un réseau de communication 200, typiquement l’Internet. Le serveur peut être accédé, via le réseau 200, par une pluralité de terminaux clients 300a-300d.
Ces terminaux, généralement référencés 300, sont préférentiellement des équipements portatifs, par exemple des téléphones intelligents (smartphones), tablettes, ordinateurs portables, objets connectés (montres, appareils photo, etc.). Ainsi, leurs propriétaires peuvent les utiliser dans divers lieux pour accéder aux contenus média du serveur 100.
Par exemple, dans le contexte A, l’utilisateur se situe dans un avion, son terminal 300a étant connecté à une borne ou passerelle 400a de l’avion. Cette borne/passerelle 400a (Wifi (nom commercial), Ethernet ou autres) fournit un accès au serveur 100, ici au travers d’un lien satellite 500 (via un équipement intermédiaire 501 ou non) et le réseau 200. Bien entendu, le serveur 100 peut être accédé directement via le seul lien satellite 500.
Dans le contexte B, l’utilisateur est à son domicile, son terminal 300b étant connecté à une borne, par exemple Wifi, 400b locale, elle-même fournissant un accès au réseau 200. De façon optionnelle, un récepteur multimédia 600, typiquement un décodeur TV (satellitaire, câble ou autre) est également prévu dans le réseau local (par exemple Wifi), lequel récepteur 600 reçoit en diffusion (broadcast), par voie satellitaire, câble ou autre (non représentée), un ou des contenus également disponibles en streaming auprès du serveur 100.
Dans le contexte C, l’utilisateur se situe dans un véhicule terrestre, par exemple voiture, car, métro ou train, et utilise son terminal 300c et le réseau de téléphonie mobile (par exemple 3G, 4G ou 5G via des stations de base 400c, ou via un équipement réseau relais installé dans le véhicule (typiquement Wifi ou autre technologie) qui est lui ensuite connecté via un équipement intermédiaire à un réseau extérieur (par exemple 3G, 4G, 5G, CPL, Internet par les rails, WiMax) pour accéder au réseau 200 et au serveur 100.
Dans le contexte D, l’utilisateur évolue dans un espace collectif privé ou public, par exemple un stade, un musée, une salle de concert, etc. Son terminal 300d est connecté à une des bornes 400d Wifi de l’espace, qui lui offre un accès au serveur 100 via le réseau 200.
Comme montré schématiquement sur laFigure 2, le serveur 100 de streaming comporte des sources 110 de média, un ou plusieurs encodeurs 120 de média, un module 130 d’empaquetage des flux encodés en segments média unicast (« packager ») et un module de streaming 140 pour la diffusion en continu (streaming) des segments media avec les clients 300. Parfois, les modules 120 et/ou 130 et/ou 140 sont combinés dans un même module.
Tous ces éléments peuvent être mis en œuvre dans un ou plusieurs serveurs physiques. Notamment, les sources 110 peuvent être déportées en plusieurs lieux (éditeurs de contenus) de telle sorte que l’encodeur 120 reçoit les flux sources via un réseau de communication (généralement privé). Aussi « le serveur 100 » peut désigner une pluralité de serveurs interconnectés permettant la mise en œuvre du service de streaming.
Sur la Figure, une seule source correspondant à un service multimédia accessible aux clients (service 1), par exemple une chaîne TV, est illustrée. Bien entendu, un grand nombre de sources, correspondant à des services multimédia respectifs (par exemple un bouquet de chaînes TV) est généralement prévu permettant à plusieurs sources d’être récupérées et/ou affichées simultanément par plusieurs lecteurs client voire par le même lecteur client (par exemple pour mettre en œuvre une fonctionnalité dite « multi-live »). Le traitement décrit ci-après pour chaque source peut être indépendant des autres sources.
La source 110 génère une ou plusieurs composantes vidéo 111, une ou plusieurs composantes audio 112, une ou plusieurs composantes de sous-titrage 113, et/ou une ou plusieurs autres composantes de données 114. Par exemple, les composantes vidéo peuvent être une vidéo à gamme dynamique standard (SDR) et une vidéo à haute gamme dynamique (HDR) ou être plusieurs vidéos d’une même scène selon des angles différents. Les composantes audio 112 peuvent être des pistes en langues différentes ou dans des formats différents (par exemple stéréo downmixées ou non et multicanal (« surround » « atmos ») ou avec des dynamiques différentes, ou tout autre traitement audio). Les composantes de sous-titrages 113 peuvent être selon des langues différentes ou des types différents (sous-titre mal entendant par exemple). Les autres composantes de données 114 peuvent inclure des données applicatives, par exemple des applications interactives que l’utilisateur peut déclencher sur son lecteur, et/ou inclure des métadonnées de description des vidéos (par exemple des métadonnées temps réel décrivant le flux live, des composantes de tracking).
Le ou les encodeurs 120 convertissent les flux sources 111-114 en des formats compressés pour une diffusion aux clients. Des normes classiquesd’encodage/compression peuvent être utilisées, par exemple le format MPEG-4. Des formats d’encodage différents peuvent être utilisés pour les différentes composantes sources.
Comme illustré sur la Figure, un média source peut être encodé en plusieurs qualités différentes constituant ainsi des variantes (ou « pistes ») disponibles à l’utilisateur pour le même média source.
A titre d’exemple, une composante vidéo peut être encodée au format SD (définition standard), HD (haute définition), Full HD, 4K (ou Ultra-HD), 8K, etc., définissant autant de qualités disponibles pour les clients 300. Sur la Figure, seul l’encodage de la composante vidéo SDR en trois qualités est montrée : qualité faible (L) au format SD, qualité moyenne (M) au format HD et haute qualité (H) au format 4K. On désigne par la suite ces qualités L(SD), M(HD) et H(4K), respectivement.
Bien que dans cet exemple les qualités se distinguent par des définitions (tailles) différentes de l’image compressée, des qualités différentes peuvent de façon générale être générées en utilisant des définitions d’image différentes, des codecs différents, des débits différents, des valeurs différentes de tout autre paramètre vidéo ou toute combinaison de ces critères.
De même, une composante audio peut être encodée avec différents débits, codecs, dynamique, nombre de pistes et formats ; par exemple 96 Kbits/s, 128 Kbits/s, 256 Kbits/s ou 320 Kbits/s, définissant autant de qualités disponibles pour les clients 300. Sur la Figure, seul l’encodage de la composante audio FR en deux qualités est montrée : qualité faible (L) en débit 128 Kbits/s et haute qualité (H) en débit 256 Kbits/s.
Bien entendu, un nombre différent de qualités que celui montré sur la Figure peut être généré, lequel nombre peut varier d’une composante à l’autre (ayant la même nature – vidéo/audio/sous-titre – ou non) au sein d’un même service multimédia.
Une qualité peut être également la combinaison d’une qualité vidéo et d’une qualité audio lorsque par exemple une composante vidéo est multiplexée avec une composante audio de telle sorte que les deux composantes sont traitées ensemble (demandées et envoyées).
L’empaqueteur 130 fragmente les flux encodés ainsi obtenus et génère, pour chaque flux, des paquets de données 131 qui satisfont un format de streaming. Ces paquets de données sont connus sous l’appellation de segments média. Généralement, les segments média 131 d’un même flux média porte le même nom de fichier complété par exemple d’un compteur s’incrémentant. Les segments media sont stockés, sous ces noms, en mémoire 141 du module de streaming 140 pour diffusion continu en mode unicast. Les media segment audio et video peuvent être, ou non, selon les cas, multiplexés ensembles.
Le module de streaming 140 est prévu, de façon classique, pour répondre aux requêtes unicast des clients souhaitant accéder à un contenu par streaming. A chaque requête unicast reçue (du typeGET dataprécisant le ou les fichiers segments média), le module 140 renvoie le ou les segments média portant le(s) nom(s) indiqué(s) dans la requête.
Différentes technologies de streaming existent, notamment le protocole DASH et le protocole HLS. Ces technologies utilisent des conteneurs de segments média au format TS («Transport stream») pour HLS, ISO-BMFF («ISO base media file format» ou ISO/IEC 14496-12 – MPEG-4 Part 12) pour DASH ou CMAF («Common Media Application Format») pour HLS et DASH. Ces protocoles s’appuient tous sur la transmission d’un fichier de description qui déclare, sous forme de pistes, toutes les qualités disponibles pour permettre aux lecteurs des clients de choisir la qualité la plus appropriée. Ce fichier de description peut également directement lister (déclarer) les segments vidéo (par leurs noms) composant chaque piste comme dans le cas DASH ou renseigner un fichier réalisant ce listage comme dans le cas HLS.
L’empaqueteur 130 génère ainsi, outre les segments média 131, un fichier de description 132 des différentes qualités de contenu disponibles aux clients. Un tel fichier est par exemple généré pour chaque service multimédia (par exemple chaîne TV). Ce fichier de description est appelé « manifest » ou MPD dans le protocole DASH et « liste de lecture maître » («m aster playlist») dans le protocole HLS. Le fichier de description est généré une unique fois pour des contenus fixes (par exemple un service de vidéo à la demande) ou est généré dynamiquement pour des contenus variables (par exemple un événement filmé en direct). Il est obtenu sur requête par le client 300.
Chaque « qualité » (en termes de taille d’image, de codec, et/ou de débit) est décrite, dans le fichier de description, sous forme de représentation ou « piste » («track»). Par la suite, les termes « qualité » et « piste » sont indifféremment utilisés pour désigner une représentation particulière.
Dans le manifest DASH, la piste indique en outre le nom (ou un motif ou règle permettant de le déterminer) des segments média qui composent le flux encodé correspondant. La liste de lecteur maître HLS renseigne, elle, le nom d’une liste de lecture média («media playlist») à récupérer, dans laquelle sont listés les segments média (ou bien est donnée une règle permettant de désigner les segments).
LaFigure 2Aillustre un exemple simplifié d’extrait de manifest DASH déclarant les trois pistes ou « représentations » H(4K), M(HD) et L(SD) de la composante vidéo SDR.
Chaque piste comporte une indication du débit (« bandwidth »), des dimensions de l’image (« width » et « height »), d’une adresse URL sur le serveur (« BaseURL ») et d’une information (<SeegmentBase indexRange>) permettant d’identifier les segments vidéo correspondants. Par exemple, la piste H(4K) est composée, pour la période courante, des segments média n°804-1123 du fichier indiqué dans la balise <BaseURL>.
Le terminal client 300 comporte un lecteur de contenu 310, généralement un lecteur multimédia, et une ou plusieurs interfaces utilisateur 390 permettant à l’utilisateur d’interagir avec le lecteur multimédia (par exemple un clavier, une souris, un écran tactile, etc.). De préférence, le lecteur de contenu 310 est intégré dans une application de streaming 305 installée dans le terminal 300. L’application 305 permet de gérer l’accès au service multimédia proposé par le serveur de streaming 100.
Le terminal client 300 est d’un type classique comportant des interfaces de communication avec le réseau 200 ainsi que des moyens de traitement (processeur).
LaFigure 3illustre, à l’aide d’un ordinogramme, des étapes générales de distribution d’un contenu depuis le serveur 100 vers le client 300. Ces étapes varient d’une implémentation à l’autre, mais les principes généraux restent les mêmes.
Le lecteur de contenu 310 ou l’application 305 l’intégrant est démarré à l’étape 700.
A l’étape 702, le lecteur 310 demande au serveur 100 la liste des services disponibles pour le service multimédia pour ce client, par exemple une liste de chaînes disponibles compte tenu de l’abonnement souscrit par le client. Cette requête est reçue par le serveur 100 (plus précisément le module 140) à l’étape 704, lequel serveur 100 récupère en mémoire 141 la liste des services disponibles ou des informations nécessaires à la génération de la liste à l’étape 706 puis envoie cette liste au lecteur 310 lors de l’étape 708.
Cette liste de services est reçue et affichée, par le lecteur 310 sur un écran du terminal 300, à l’utilisateur lors de l’étape 710. L’utilisateur interagit alors, à l’aide de l’interface utilisateur 390, avec la liste affichée. Le lecteur 310 reçoit donc, à l’étape 712, une instruction utilisateur. Si celle-ci correspond (test 714) à une instruction de sélection d’un nouveau service (sélection dans la liste ou plus généralement zapping vers un nouveau service / nouvelle chaîne par tout moyen de navigation idoine), le lecteur 310 demande au serveur 100 des informations sur le service sélectionné. C’est l’étape 716. La requête envoyée au serveur contient un identifiant du service souhaité (par exemple l’identifiant d’une chaîne que l’utilisateur souhaite accéder).
A réception de cette requête (étape 718), le serveur 100 récupère, en mémoire 141, les informations nécessaires pour initier la session de lecture du service demandé et génère un fichier d’initialisation contenant ces informations. C’est l’étape 720. Notamment, le serveur récupère une adresse (par exemple URL pour «Universal Resource Locator») où est stocké le fichier de description 132 (e.g. manifest DASH ou liste de lecture maître HLS) du contenu diffusé sur ce service. Optionnellement, le serveur récupère également une adresse de secours où est stockée une copie de ce fichier de description ou une version simplifiée du fichier de description.
Le fichier d’initialisation est alors envoyé, à l’étape 722, par le serveur 100 au lecteur 310 qui le reçoit à l’étape 724.
Le lecteur 310 demande alors, à l’étape 726, le fichier 132 de description de contenu à l’URL indiquée dans le fichier reçu. La requête étant reçue, le serveur récupère ou génère le fichier de description du contenu et l’envoie au lecteur 310 (étape 728). Selon certaines réalisations, le lecteur 310 peut demander périodiquement (par exemple toutes les 6 secondes) le ou les fichiers de description 132 correspondant au service (chaîne) visionnée.
En variante, le fichier de description 132 peut être reçu directement en réponse à la requête émise à l’étape 716 en réponse au zapping ou être totalement généré par l’application 305 à l’aide d’informations récupérées par exemple à l’étape 716.
A réception du fichier de description 132 (étape 730), le lecteur 310 effectue (étape 732) une sélection de la ou des pistes (qualité) les plus appropriées compte tenu par exemple de l’état de sa connexion réseau avec le serveur 100 (issu notamment d’une mesure de débit effectuée par lui-même) et des capacités du lecteur vidéo. Il est ici rappelé que les lecteurs vidéo peuvent également restreindre eux-mêmes les pistes qu’ils lisent, soit pour raison de capacités techniques (par exemple, non lecture d’un flux encodé au format H265 sur un terminal n’ayant pas la capacité pour le décoder), soit pour raison de pertinence (par exemple, non lecture d’une piste 4K sur un terminal HD et si présence d’une piste HD de qualité suffisante), ou toute autre règle interne au lecteur vidéo utilisé.
Le lecteur 310 peut notamment choisir une qualité ou piste par composante (par exemple une qualité pour la vidéo SDR, une pour la vidéo HDR, une pour l’audio FR, une pour l’audio EN, etc.). Le « contenu » accédé par le lecteur 310 peut ainsi s’entendre de l’ensemble des composantes formant un service souhaité (par exemple une chaîne), comme d’une simple composante du service choisi. La qualité ou la piste du contenu s’entend alors comme désignant la qualité/piste correspondant à la composante considérée, ou plus généralement l’ensemble des qualités/pistes correspondants aux différentes composantes formant le contenu.
Le lecteur 310 sollicite le serveur 100 pour récupérer les segments média 131 constitutifs de chaque piste sélectionnée à l’étape 732. Ainsi, un échange de requêtes unicast (par exemple GET data) émises par le lecteur et de réponses contenant les segments média demandés s’établit entre le lecteur et le serveur (étapes 734 et 736). A titre d’exemple, une requête unicast peut être envoyée périodiquement (par exemple toutes les 6 secondes) pour récupérer l’ensemble des segments média 131 de chaque piste sélectionnée pour cette période. C’est la diffusion en continu (streaming) du contenu.
Les segments média obtenus sont alors restitués visuellement ou auditivement à l’utilisateur.
De façon connue, le streaming adaptatif dynamique de contenus permet au lecteur 310, lors de ces échanges, de changer de pistes par composante (en amélioration ou diminution de qualité), par exemple selon l’évolution des performances du réseau 200, une fois une évaluation précise du débit stable réel du client, ou après lancement de la vidéo (une optimisation classique étant de débuter une session sur une qualité intermédiaire pour réduire le temps de zapping).
De façon similaire à l’étape 712, le lecteur 310 peut recevoir à l’étape 738 une nouvelle instruction de l’utilisateur qui, si elle consiste à changer de service (chaîne) (test 740), permet de retourner à l’étape 716. Autrement, toute autre instruction est traitée de façon classique (traitement non représenté sur la figure).
De retour à laFigure 1, certains environnements où évoluent les utilisateurs de services de streaming sont contraints en termes de débit réseau disponible. C’est par exemple le cas du contexte A de l’avion ou du contexte D d’un stade où un grand nombre d’utilisateurs doit potentiellement se partager une bande passante limitée. Leur permettre à tous un accès en mode unicast aux contenus du serveur 100 n’apparaît pas envisageable : cela requerrait une important bande passante et/ou la qualité du streaming sur chaque terminal s’en trouverait drastiquement réduite.
Par ailleurs, il est fréquent qu’un utilisateur change d’environnement, c’est-à-dire voit son terminal 300 changer de réseau local ou de borne 400 d’accès au réseau 200 (et au serveur 100). Par exemple l’utilisateur peut quitter un hall d’aéroport (contexte D) et embarquer dans un avion (contexte A). Il peut aussi quitter son domicile (contexte B) pour prendre un moyen de transport (contexte C). Les contraintes réseau auxquelles sont confrontés les terminaux sont donc susceptibles de varier subitement et de façon importante.
Il existe ainsi un besoin d’améliorer les techniques de diffusion ou « streaming » connues pour tenir compte de ces contraintes réseau.
La présente invention s’appuie sur la technique de diffusion multicast d’au moins une qualité de contenu demandée par plusieurs terminaux 300 afin de mutualiser les ressources réseau et sur une sélection, en fonction du contexte dans lequel évolue le terminal, des pistes (ou qualités) effectivement mise à disposition du lecteur 310 pour un accès en mode unicast.
Grâce à l’accès en mode unicast seulement malgré l’utilisation de la technique de diffusion multicast, un lecteur 310 conventionnel peut être utilisé. Par ailleurs, la mise à disposition d’un nombre variable de pistes (qualités) du même contenu selon le contexte environnemental du terminal permet au lecteur 310 de garder un contrôle sur le choix de la qualité du contenu finalement obtenu dans le cadre du streaming adaptatif dynamique, contrairement à l’approche proposée dans la publication WO 2015/101782. En outre, contrairement à cette dernière, l’invention ne requiert pas nécessairement la présence de plusieurs flux multicast de qualités différentes. Enfin, cette solution existante n’est pas compatible avec les règles imposées par certains magasins d’applications ; elle n’appréhende également pas la gestion des contenus protégés par une DRM.
LaFigure 4illustre schématiquement l’idée de l’invention. Le terminal 300 reçoit le fichier de description 132 qui décrit plusieurs pistes (et donc qualités correspondantes) d’un même contenu. En variante, un simple fichier de configuration listant les pistes et qualités peut être reçu, ou une ou plusieurs API, ou tout autre moyen de récupérer des informations à distance.
Au moins une qualité de contenu, dite « première qualité » (par exemple la piste M(HD)), est également disponible en mode multicast auprès du serveur 100 (c’est-à-dire diffusée en mode multicast par le serveur).
Si le contexte courant du terminal le permet, et si les qualités multicast proposées sont pertinentes dans le contexte courant, le terminal 300 s’abonne au flux multicast le plus pertinent compte tenu du contexte de lecture, et reçoit les datagrammes multicast 133 correspondants.
Un module proxy 320 obtient une information de contexte représentative d’un environnement dans lequel le client 300 évolue, puis fonction de celle-ci, sélectionne et met à disposition du lecteur 310 en mode unicast uniquement un jeu de pistes (ou qualités) décrites dans le fichier 132 et qui sont autorisées pour ce contexte précis. Plusieurs jeux sont prévus pour plusieurs contextes. Au moins un jeu inclut une première qualité correspondant à une piste multicast. Le module proxy 320 conserve idéalement au moins une piste que le lecteur de vidéo est en capacité technique de lire, afin de laisser la lecture possible. Le cas échéant, si aucune piste disponible dans le contexte courant n’est lisible par le lecteur, la lecture serait alors impossible. Il convient donc de sélectionner des premières qualités lisibles par un maximum d’équipements pour minimiser cette limitation.
Le lecteur 310 fonctionne de façon classique en sélectionnant une piste en fonction de la qualité souhaitée et demande les segments média correspondants. Il peut donc choisir, de façon classique, entre une piste reçue par le terminal 300 en mode multicast et une piste accessible en mode unicast auprès du serveur.
Le module 320 peut alors opérer comme simple relais des requêtes unicast (et réponses correspondantes) si la piste choisie n’est pas celle correspondant au flux multicast, mais une piste accessible auprès du serveur 100 par voie unicast. En revanche, si la piste choisie correspond au flux multicast, le module 320 opère comme convertisseur du flux multicast en segments média accessibles localement, en mode unicast, par le lecteur 310 demandant cette première qualité de contenu.
A titre d’exemple notamment, lorsque le contexte A est détecté, seule la piste multicast, disons M(HD), est mise à disposition du lecteur 310 en mode unicast par le module 320. Un premier jeu contextuel de pistes est donc limité à la seule piste multicast. Dans ce cas, aucune des pistes initialement disponibles auprès du serveur 100 en mode unicast n’est accessible par le lecteur 310. Cette restriction peut être réalisée, comme décrite par la suite, à l’aide d’un fichier de description modifié envoyé par le proxy 320 au lecteur 310, ce fichier ne décrivant que la piste du flux multicast.
Ainsi, tous les terminaux 300 dans le contexte A accèdent au contenu (par exemple une chaîne live) au travers de la seule diffusion multicast, bien que localement chaque lecteur 310 sollicite son proxy respectif 320 en mode unicast. La bande passante utilisée entre l’avion et le serveur 100 est donc minimisée.
En revanche, lorsque le contexte B est détecté, toutes les pistes déclarées dans le fichier de description 132 peuvent être conservées, celle correspondant à la qualité M(HD) pouvant être gérée par le proxy 320 de telle sorte que les segments média issus de la conversion du flux multicast soient délivrés au lecteur 310 demandant cette qualité. Un deuxième jeu contextuel de pistes comporte ainsi la (ou plusieurs) piste(s) multicast et l’ensemble des pistes unicast correspondant aux autres qualités disponibles (et décrites dans le fichier 132). Cela permet de mettre à disposition du lecteur 310 un grand nombre de qualités du même contenu, certaines accessibles auprès du serveur 100 en mode unicast, d’autres récupérées auprès du serveur 100 en mode multicast et converties localement en segments média pour un accès local en mode unicast par le lecteur 310. L’adaptation dynamique de la diffusion permet au lecteur 310 de basculer de l’une à l’autre de ces qualités, tout en conservant le contrôle de la qualité choisie.
Dans le contexte C, une partie des pistes décrites dans le fichier 132 peut être conservée en accès unicast directement au serveur 100 et une ou deux pistes multicast peuvent être proposées pour des qualités traditionnellement choisies par les clients 300. Un troisième jeu contextuel de pistes comporte ainsi la (ou plusieurs) piste(s) multicast et un sous-ensemble des pistes unicast correspondant aux autres qualités disponibles (et décrites dans le fichier 132).
D’autres jeux contextuels de pistes peuvent être envisagés, incluant un quatrième jeu ne comportant aucune piste multicast mais seulement tout ou partie des pistes unicast décrites dans le fichier 132.
LaFigure 5illustre un système pour une mise en œuvre de l’invention. LaFigure 5reprend des éléments de laFigure 2qui portent les mêmes références.
Côté serveur 100, les sources 110 et encodeurs 120 demeurent identiques. Le packager 130 comporte un module d’empaquetage unicast 135 et un module d’empaquetage multicast 136.
Le module d’empaquetage unicast 135 effectue les opérations d’empaquetage des flux encodés en segments média unicast comme décrit plus haut en lien avec laFigure 2. Chaque segment média est ainsi identifié dans le fichier de configuration 132 ou dans un fichier (liste de lecture média par exemple) référencé par ce dernier pour la piste correspondante. L’identification peut se faire au travers d’un nom spécifique par exemple ou bien au travers d’un nom de fichier (pour le contenu à ladite qualité) et d’indexes de segments (comme dans l’exemple de laFigure 2A).
Le module d’empaquetage multicast 136 prépare un ou plusieurs flux encodés pour une diffusion multicast où les données média ont le même nommage que les segments média identiques de la piste unicast correspondante (même qualité).
Pour ce faire, la liste du ou des flux à convertir en flux multicast peut être préconfigurée, par exemple à l’aide d’un fichier de configuration 1360. Ces flux particuliers ont donc vocation à être diffusés en unicast et en multicast pour une exploitation optimisée par les clients 300 en fonction du contexte dans lequel ceux-ci évoluent.
Le fichier de configuration 1360 peut par exemple contenir toutes les « qualités » dont les flux doivent être transmis en multicast. A titre d’exemple pour la suite de la description, considérons que la qualité M(HD) de la vidéo SDR doit être diffusée en multicast.
A noter que, les adresses IP multicast étant actuellement limitées en nombre et potentiellement difficiles à obtenir, dans certains contextes il peut être intéressant d’utiliser une même adresse IP multicast pour diffuser les media segments des composantes video et audio (voire plus), et non pas créer une adresse IP multicast pour chacune des composantes. A titre d’alternative, la composante audio pourrait être récupérée en unicast, et la composante vidéo (plus volumineuse) en multicast.
La préparation de ce flux est classique : segmentation du flux encodé M(HD), préparation de datagrammes 1361 et transmission de ceux-ci au module de streaming 140.
Dans cet exemple, le module d’empaquetage multicast 136 reçoit en entrée les flux encodés par les encodeurs 120. Cela permet des traitements rapides (sans latence) utiles lors de la diffusion d’évènements sportifs.
Dans une variante, le module d’empaquetage multicast 146 peut recevoir en entrée non pas les flux encodés du module d’encodage 120, mais les segments média générés par le module d’empaquetage unicast 135. Dans ce cas, le module d’empaquetage multicast 136 effectue une conversion unicast vers multicast des segments média. Cette variante permet d’utiliser des solutions sur étagère.
Le module de streaming 140 comprend un module de streaming unicast 145 et un module de streaming multicast 146. Le module de streaming unicast 145 traite les requêtes unicast des clients de façon classique comme décrit plus haut en lien avec laFigure 2pour récupérer, en mémoire 141, et transmettre, au client les demandant, le fichier de description 132 et les segments média 131 de la ou les pistes sélectionnées par le client.
Le module de streaming multicast 146 procède, de façon classique, à la diffusion, sur le réseau 200, des datagrammes à destination des clients ayant souscrit un abonnement au flux correspondant. A cet effet, le module de streaming multicast 146 est également en charge de la gestion des demandes d’abonnement aux divers flux multicast par les clients 300. En variante, cette gestion des abonnements peut être réalisée par un autre module, voire par un autre équipement serveur.
Côté client 300, le module proxy 320 selon l’invention comporte un module 330 de détermination d’un contexte réseau, un module 340 de mise à disposition de flux et un module de gestion des flux 350.
Le module de détermination d’un contexte réseau 330 est configuré avec un fichier ou informations de configuration CONFIG1 (non représenté) pour connaître la liste de contextes déclarés (par exemple les contextes A à D de laFigure 1). Le fichier ou les informations attribuent à chaque contexte un identifiant unique et précise les critères définissant ce contexte.
LaFigure 6illustre un exemple simplifié de fichier dans lequel un premier contexte (identifiant ID=1) correspond à un environnement où le réseau local porte un nom (SSID) prédéfini (ici parmi une liste « SSID1 », « SSID2 », etc.) ou la borne 400 présente une adresse IP prédéfinie (ici parmi « @IP1 », « @IP2 », etc.).
Par exemple, un SSID détecté comme « Airline Company On Board » peut définir un contexte particulier, notamment le contexte A de laFigure 1.
LaFigure 6illustre un deuxième contexte (identifiant ID=2) défini par l’identification d’un équipement particulier sur le réseau local lors d’une procédure de découverte. Dans l’exemple, le protocole de découverte « Bonjour » est utilisé et le contexte ID=2 (par exemple le contexte B de domicile de laFigure 1) est détecté si une set-top box Canal+ est découverte à l’issue de la procédure de découverte.
Bien entendu, d’autres critères permettant de déterminer une caractéristique propre à un réseau local, et par voie de conséquence à un contexte réseau particulier, peuvent être utilisés, pris seuls ou en combinaison entre eux et/ou avec ceux qui précèdent.
Par exemple, la détection d’une connexion du terminal à une borne 400c de téléphonie mobile peut correspondre à un nouveau contexte (par exemple le contexte C d’itinérance de laFigure 1). L’adresse IP publique permet également d’aider à la prise de décision du contexte (par exemple en connaissant la liste des adresses IP publiques d’une compagnie aérienne, ou un fournisseur Internet), ou toute information présente dans une requête http entrante sur un serveur. La localisation géographique peut également être un indicateur. La détection d’une information sur un réseau local (certificat, identifiant, nom de réseau, autre) également. Un test empirique d’accès à un fichier ou une IP multicast peut également être utilisé dans certains contextes.
Par ailleurs, un contexte par défaut (ID=0) peut être défini.
En fonctionnement, le module de détermination d’un contexte réseau 330 récupère, d’un système d’exploitation (non représenté) du client 300, le SSID du réseau local, une adresse IP de la borne 400 auquel le client est connecté, l’identification des équipements découverts sur le réseau local, ou toute autre information réseau utile. A partir de ces informations récupérées, le module 300 détermine un contexte local, à l’aide du fichier de configuration de laFigure 6par exemple.
A titre illustratif, lorsque l’utilisateur entre dans un avion et que son téléphone portable 300 se connecte à la borne wifi 400b de l’avion, le module 330 récupère le SSID « Airline Company On Board » du réseau wifi local et détermine, à l’aide du fichier, le contexte local comme étant le contexte A. Si par contre aucune des informations récupérées ne permet d’identifier un contexte local particulier, le contexte local par défaut (par exemple contexte B) est considéré comme étant détecté.
Le fichier CONFIG1 de configuration du module 330 peut être généré et stocké localement à partir de saisies effectuées localement (via 390) par l’utilisateur ou un administrateur. De façon avantageuse, il peut s’agir d’un fichier chargé dans le terminal client 300, depuis le serveur 100 ou tout autre dispositif de stockage. Ce chargement peut être effectué une seule fois, éventuellement au démarrage du terminal, ou être effectué périodiquement ou être initié par le serveur 100 (en mode « push »). Ainsi, une flotte de terminaux clients 300 peut aisément être mise à jour en cas d’évolution de contextes (nouveaux contextes, nouvelles bornes déployées, etc.). A titre alternatif, il peut être récupéré en temps réel via une API serveur lors d’une action effectuée dans l’application (démarrage, demande de la liste de chaînes, demande de zapping, changement de contexte), ou sur notification distante, ou toute autre solution permettant de récupérer des informations interprétables par un logiciel informatique.
L’information de contexte local est transmise au module 340 de mise à disposition de flux. Il peut simplement s’agir de transmettre l’identifiant ID.
Le module de mise à disposition de flux 340 est configuré par exemple avec un fichier de configuration CONFIG2 (non représenté) pour connaître, pour chaque contexte, la liste des services autorisés et la liste de pistes (qualités) autorisées par service. C’est ce fichier qui permet de réaliser une sélection des pistes à mettre à disposition du lecteur de contenu 310 lorsque ce dernier accès à un service (une chaîne par exemple) dans un contexte donné. A titre alternatif, il peut être récupéré en temps réel via une API serveur lors d’une action effectuée dans l’application (démarrage, demande de la liste de chaînes, demande de zapping, changement de contexte), ou sur notification distante, ou toute autre solution permettant de récupérer des informations interprétables par un logiciel informatique.
Comme montré dans l’exemple de laFigure 7, un tel fichier CONFIG2 peut associer chaque contexte (ID) à un jeu de pistes autorisées, c’est-à-dire une liste des pistes autorisées dans ce contexte, pour chaque service (par exemple chaîne) et peut préciser le moyen (mode de diffusion unicast ou multicast) pour y accéder auprès du serveur.
L’absence de piste autorisée pour un service signifie que ce dernier n’est pas accessible aux clients.
Pour une meilleure lisibilité, cet exemple de la Figure montre uniquement des composantes vidéo d’un premier service (chaîne n°1). Une déclaration similaire peut être réalisée pour les autres services (chaînes n°2 à N) et au sein de chaque service, pour les composantes audio, sous-titres et autres.
En variante, on peut prévoir un tel fichier CONFIG2 pour chaque service (chaîne) auquel cas un fichier ne contient que les jeux contextuels de pistes autorisées pour ce service.
Dans l’exemple, une seule piste vidéo de la chaîne n°1 est déclarée comme autorisée dans le jeu contextuel du contexte ID=1. Il s’agit par exemple de la seule piste disponible en mode multicast auprès du serveur 100, ici correspondant à la qualité M(HD). Cela signifie que les autres qualités (prévues en unicast dans le fichier de description 132) et les autres éventuelles qualités disponibles en multicast ne seront pas accessibles aux clients.
Plusieurs pistes vidéo sont autorisées dans le jeu contextuel du contexte ID=2. Pour la composante vidéo SDR, une seule piste disponible en mode multicast auprès du serveur, ici correspondant à la qualité M(HD), est déclarée accompagnée d’une ou plusieurs pistes (ici une) correspondant à des qualités (ici L(SD)) disponibles en mode unicast auprès du serveur. Pour la composante vidéo HDR, seules des pistes correspondant à des qualités (ici L(SD) et M(HD)) disponibles en mode unicast auprès du serveur sont autorisées. Aucune piste multicast pour la composante HDR n’est autorisée dans cet exemple (potentiellement car aucune n’est disponible auprès du serveur en mode multicast).
Dans le jeu de pistes du troisième contexte illustré, ici le contexte par défaut ID=0, toutes les qualités prévues dans le fichier de description 132 sont conservées, au moins pour une composante (ici pour les deux composantes vidéo). Pour la composante vidéo SDR, une seule piste disponible en mode multicast auprès du serveur, ici correspondant à la qualité M(HD), est déclarée accompagnée de l’ensemble des pistes (ici deux) correspondant aux autres qualités (ici L(SD) et H(4K)) disponibles en mode unicast auprès du serveur. Pour la composante vidéo HDR, toutes les pistes correspondant à des qualités (ici L(SD), M(HD) et H(4K)) disponibles en mode unicast auprès du serveur sont autorisées.
Bien que ces exemples n’envisagent qu’une seule piste (qualité) en mode multicast pour le service considéré, il pourrait être prévu de déclarer deux pistes (ou plus) en mode multicast pour au moins un contexte. Cela est bénéfique notamment lorsqu’une majorité de terminaux clients opère selon deux (ou plus) formats différents (par exemple des terminaux HD et des terminaux 4K).
Le fichier CONFIG2 de configuration du module 340 peut être généré et stocké localement à partir de saisies effectuées localement (via 390) par l’utilisateur ou un administrateur. De façon avantageuse, il peut s’agir d’un fichier chargé dans le terminal client 300, depuis le serveur 100 ou tout autre dispositif de stockage. Ce chargement peut être effectué une seule fois, éventuellement au démarrage du terminal, ou être effectué périodiquement ou être initié par le serveur 100 (en mode « push »). Ainsi, une flotte de terminaux clients 300 peut aisément être mise à jour en cas d’évolution de contextes (nouveaux contextes, changement des pistes autorisées par contexte, etc.).
Les fichiers de CONFIG1 et CONFIG2 peuvent également être mis en œuvre au sein d’un seul et même fichier.
Dans un mode de réalisation, le fichier CONFIG2 peut en outre comprendre pour chaque qualité multicast déclarée, l’adresse IP multicast du serveur 100 correspondant à ce flux multicast ou toute autre information permettant au client 300 de s’abonner au flux multicast comme décrit par la suite. En variante, cette information (adresse IP multicast correspondant à un flux multicast) peut être stockée dans un autre fichier CONFIG3 (non représenté) accessible par exemple auprès du serveur 100.
Sur la base de ce fichier de configuration CONFIG2, du fichier de description 132 (ou de tout autre fichier de configuration contenant les mêmes informations) qu’il reçoit du serveur 100 et d’un contexte courant déterminé par le module 330, le module de mise à disposition de flux 340 sélectionne le jeu de pistes autorisées pour le service choisi par l’utilisateur et les met à disposition du lecteur de contenu 310, en accès unicast.
Le contexte courant peut simplement être le contexte local déterminé par le module 330. En variante, il peut s’agir d’un contexte déterminé à distance par le serveur pour le client 300 concerné et retourné à ce dernier lors d’échanges de messages comme décrit dans l’exemple de laFigure 8. En variante encore, il peut s’agir d’un contexte déduit du contexte local et d’un contexte à distance fourni par le serveur, notamment à l’aide d’une table de correspondance liant différents contextes (courants) à des couples de contexte local-contexte à distance.
Dans un mode de réalisation, le contexte courant est le plus restrictif entre le contexte local et le contexte à distance. Le caractère restrictif ou non d’un contexte peut être évalué au regard du nombre de services disponibles pour les clients : le contexte le plus restrictif est alors celui qui, dans le fichier CONFIG2, présente le moins de services ayant au moins un flux unicast ou multicast autorisé. Il peut aussi s’agir de celui offrant le moins de pistes autorisées ou celui favorisant les pistes multicast (en nombre ou en ratio des pistes autorisées). D’autres critères peuvent bien entendu être utilisés.
Connaissant le contexte courant, le module 340 peut générer, à partir du fichier 132 reçu pour le service auquel souhaite accéder l’utilisateur, un fichier client de description 341 comprenant les seules qualités autorisées par le fichier CONFG2 pour le service à accéder, afin de le communiquer au lecteur 310. Ce fichier client 341 peut suivre un format classique de fichier de description de flux unicast, type manifest (DASH) ou liste de lecture maître (HLS), de telle sorte que le lecteur de contenu 310 accède par requêtes unicast audit contenu selon une qualité choisie par lui parmi celle ou celles correspondant aux pistes du fichier modifié.
Dans un mode de réalisation décrit à titre principal par la suite, le fichier client de description 341 est un fichier modifié du fichier de description 132 reçu.
En variante, notamment si seulement un fichier de configuration (par exemple CONFIG2) est reçu du serveur, le client peut générer lui-même le fichier client de description 341 à partir du fichier de configuration, d’une ou plusieurs API, ou de tout autre moyen permettant de récupérer des informations à distance, compte tenu du contexte. Cette approche peut être plus pratique dans certains cas.
Les pistes déclarées en unicast dans le fichier de configuration CONFIG2 pour le contexte courant et le service accédé sont notamment conservées inchangées par rapport au fichier de description 132 reçu. Notamment, ces pistes conservent l’adresse URL du serveur 100 où les segments média 131 (la liste de lecture média dans le cas HLS) peuvent être récupérés par le lecteur 310. Ainsi, le lecteur 310 pourra accéder de façon classique au streaming unicast délivré par le serveur 100 s’il choisit l’une de ces pistes. A titre d’alternative, les adresses URL peuvent être aussi converties aux URL locales, laissant le module proxy 320 rediriger ensuite ces requêtes vers les URL originelles.
La ou les pistes déclarées en multicast dans le fichier de configuration CONFIG2 pour le contexte courant sont ajoutées dans le fichier modifié 341 avec une adresse URL locale fournie par le module de gestion 350 afin que le lecteur 310 accède au contenu multicast (converti comme décrit par la suite) à l’aide d’appels unicast classiques auprès du module 350. C’est en ce sens que le module 320 opère comme proxy pour l’accès aux contenus du serveur. Cela permet aussi de conserver un lecteur 310 conventionnel.
A titre d’exemple, la description, dans le fichier 132, de la piste unicast qui correspond au flux multicast à déclarer peut être conservée dans le fichier modifié 341 avec cependant la ou les adresses URL sur le serveur 100 (pour fournir les segments média 131 ou la liste de lecture média dans le cas HLS) qui sont remplacées par des adresses URL locales à utiliser. Dans le cas DASH, il s’agit des adresses URL locales du proxy 320 où sont stockés les segments média issus de la conversion du flux multicast en segments unicast par le module 350. Dans le cas HLS, il s’agit de l’adresse URL locale dans le proxy 320 où est stockée la liste de lecture média décrivant le contenu unicast du flux récupéré en mode multicast. Le module 340 génère alors la liste de lecture média correspondant à cette piste multicast, liste dans laquelle à nouveau des adresses URL locales sont utilisées pour indiquer l’emplacement de stockage des segments média issus de la conversion du flux multicast en segments unicast par le module 350.
En reprenant l’exemple de laFigure 2A, le fichier client de description 341 peut contenir une unique piste autorisée correspondant à la première qualité M(HD) diffusée en multicast par le serveur 100 comme montré sur laFigure 5A. Comparativement à la description de cette qualité dans le fichier de description initiale 132, l’URL <BaseURL> est modifiée en une adresse locale au proxy 320. Le nom du contenu (sdr-medium.mp4) ainsi que les indexes des segments média sont maintenus inchangés.
Dans l’exemple de laFigure 5B, des pistes accessibles auprès du serveur en mode unicast sont conservées, ici celles des qualités H(4K) et L(SD).
Ainsi, le lecteur 310 recevant le fichier client de description 341 peut uniquement choisir parmi les qualités autorisées dans le fichier CONFIG2 fonction du contexte courant. Une diffusion adaptative dynamique classique par le lecteur 310 est donc toujours possible.
Si une qualité choisie par le lecteur 310 est déclarée en accès unicast dans le fichier CONFIG2, alors un accès classique unicast auprès du serveur 100 est réalisé. Cet accès classique est réalisé grâce à la présence d’une URL du serveur (<BaseURL>) dans la description de la piste correspondante, dans le fichier client 341. En variante, pour le cas où des adresses URL locales sont tout de même utilisées pour les pistes unicast, le module 350 peut rediriger les requêtes unicast vers le serveur 10 (et les réponses en retour).
Si en revanche une qualité choisie par le lecteur 310 est déclarée comme acquise en multicast dans le fichier CONFIG2, alors le lecteur récupère le contenu auprès du module 350 de gestion, par accès unicast. Cet accès local est rendu possible grâce à l’URL locale (<BaseURL>) prévue dans la description de la piste correspondante, dans le fichier client 341. C’est alors le module 350 qui gère, comme décrit par la suite, la récupération auprès du serveur 100 du flux multicast correspondant à la qualité choisie et la conversion à la volée de ce flux en segments média pour le distribuer en mode unicast au lecteur 310.
A noter que, si le contexte le permet, alors que le lecteur vidéo demande auprès du serveur 100 une piste correspondant à un flux multicast, le module 350 de gestion peut toutefois récupérer des segments média en unicast pour faire face à certaines situations (déclenchement plus rapide de lecture, gestion d’erreur, ou toute autre situation le requérant).
En variante à la génération d’un fichier client de description 341 restreint aux seules qualités de contenu autorisées par la fichier CONFIG2 pour le service accédé compte tenu du contexte courant, le module 340 peut générer un fichier de description 341’ (non représenté sur les figures) qui comporte toutes les pistes du fichier de description 132 auxquelles sont ajoutées une ou plusieurs nouvelles pistes correspondant à ou aux flux multicast que le serveur 100 diffuse. Ces flux multicast sont par exemple connus du fichier CONFIG3 évoqué plus haut ou déduits de l’ensemble des flux multicast déclarés dans le fichier CONFIG2. Les nouvelles pistes peuvent reprendre les mêmes éléments descriptifs (débit, qualité, etc.) que ceux de la piste correspondante (i.e. avec la même qualité) dans le fichier de description initial 132, avec cependant l’adresse ou les adresses URL sur le serveur 100 qui sont remplacées par les adresses URL locales à utiliser.
Ce fichier complet 341’ peut être généré une unique fois pour un service considéré et être réutilisé quel que soit le contexte courant.
Dans un mode de réalisation où ce fichier de description 341’ référence la ou les listes de lecture média (ou équivalent) qui listent les segments média des pistes correspondantes (comme c’est le cas dans HLS par exemple), le contrôle sur la mise à disposition des seules qualités correspondant au contexte courant peut être effectué en jouant sur les listes de lecture média effectivement fournies lorsque le lecteur 310 tente d’accéder à une des pistes.
Par exemple, le module 350 peut délivrer au lecteur 310 une liste de lecture média déclarant les segments média comme manquants ou non disponibles pour toutes les pistes non autorisées et délivrer une liste de lecture déclarant les segments média de façon normale pour les pistes autorisées dans le contexte courant. Ainsi, si le lecteur 310 sélectionne une piste non autorisée, il est incapable d’obtenir les segments média correspondant et est donc forcé à basculer sur une autre piste (autre qualité) jusqu’à sélectionner une piste autorisée.
Comme la piste sélectionnée par le lecteur 310 peut être décrite comme accessible directement en mode unicast auprès du serveur (i.e. l’URL référence le serveur), le proxy 320 est configuré pour intercepter toute liste de lecture média demandée par le lecteur 310 et la modifier le cas échéant (si la piste n’est pas autorisée) pour déclarer les segments média comme manquants. Si le proxy 320 génère lui-même cette liste (par exemple dans le cas du flux multicast rendu accessible localement en mode unicast), il peut directement générer la liste de lecture média en déclarant les segments média comme manquants, pour les pistes non autorisées.
Dans un autre mode de réalisation utilisant le fichier complet 341’, le contrôle sur la mise à disposition des seules qualités correspondant au contexte courant est effectué par le module de gestion 350. Par exemple, lorsque le module de gestion 350 détecte que le lecteur 310 sélectionne une qualité non autorisée et demande les segments média correspondants, le module 350 peut retourner les segments média d’une autre piste, elle, autorisée. Il peut s’agir des segments média de la piste autorisée ayant la qualité la plus proche de celle sélectionnée par le lecteur 310. En variante, le module 350 peut retourner les segments média du même contenu obtenus via un flux multicast (après conversion multicast-unicast), ayant idéalement la qualité la plus proche possible de celle sélectionnée par le lecteur 310.
Le module de gestion des flux 350 permet de fournir les segments média au lecteur 310.
Pour les pistes accessibles directement en mode unicast auprès du serveur 100 par le lecteur 310 (car l’URL du fichier 341, 341’ est celle du serveur 100), le module 350 opère comme simple relais des requêtes/réponses unicast entre le lecteur 310 et le serveur 300. Le cas échéant, le module 350 présence une capacité d’interception des pistes de lecture média pour les modifier ou des requêtes de segments média d’une piste non autorisée pour les substituer par des segments média d’une piste autorisée du même contenu.
Pour traiter les pistes récupérées du serveur en mode multicast, typiquement le flux multicast M(HD), le module de gestion des flux 350 comporte un module 351 de gestion de flux multicast.
Ce module 351 s’active par exemple lorsqu’il existe un (ou plusieurs) flux multicast pour le contexte courant, ce qui peut être déterminé à l’aide du fichier CONFIG2. Le module 351 s’abonne à ce (ou ces) flux multicast auprès du serveur 100, soit automatiquement à détection du contexte, soit de préférence en réponse à la sélection par le lecteur 310 du service (chaîne) auquel appartient ce flux.
Le module 351 de gestion de flux multicast convertit alors à la volée les datagrammes 1361 reçus du flux multicast en segments média 352 qu’il stocke aux adresses URL locales telles que prévues dans le fichier de description 341/341’ ou dans les listes de lecture média (cas HLS) que ce fichier 341/341’ référence. Le gestionnaire 350 est alors en charge de délivrer ces segments média au lecteur 310 en mode unicast (local).
LesFigure s 8et8Aillustrent, à l’aide d’un ordinogramme, des étapes générales d’une distribution de contenu depuis le serveur 100 vers un client 300 selon l’invention. Ces étapes peuvent être mises en œuvre de façon indépendante par plusieurs clients. Ces clients peuvent évoluer dans le même contexte (c’est-à-dire appartenant au même réseau local) ou dans des contextes distincts.
Cette description de la Figure s’appuie à titre principal sur le mode de réalisation mettant en œuvre le fichier de description modifié 341. Des ajustements accessibles à l’homme du métier sont à prévoir pour l’adapter à l’utilisation des fichiers de description 341’ évoqués plus haut.
LesFigure s 8et8Areprennent des étapes de laFigure 3qui portent les mêmes références.
Au démarrage de l’application 305, le lecteur 310 démarre (700) ainsi que le proxy 320 (750).
En réponse à ce démarrage, le proxy 320 détermine le contexte local du client 300 à l’étape 752. Cette étape est réalisée par le module 330 de détermination d’un contexte réseau comme décrit plus haut. Par exemple, le module 330 détecte que le SSID du réseau local auquel le terminal 300 est connecté s’appelle « Airline Company On Board » et détermine alors que le contexte est le contexte A (ID=1) par exemple.
A l’étape 754, l’application 305 demande au serveur 100 la liste des services disponibles en précisant le contexte local. L’intérêt du contexte local est de pouvoir restreindre la liste des services disponibles à ceux autorisés (selon le fichier CONFIG2 par exemple) avec le contexte local. Typiquement dans un contexte avion, la liste de chaînes disponibles peut être restreinte à une, deux, trois, quatre ou cinq chaînes pour ne pas saturer la liaison satellite.
Cette demande avec le contexte local est reçue à l’étape 756 (similaire à l’étape 704) par le serveur 100.
Ce dernier peut optionnellement déterminer, à l’étape 758, un contexte « à distance » du client représentatif de l’environnement réseau dans lequel le client 300 évolue. Par exemple, le serveur 100 peut récupérer l’adresse IP publique de la borne 400 du lieu où évolue le client (cette adresse IP publique est indiquée dans les paquets IP reçus à l’étape 756) et comparer cette adresse IP publique avec des valeurs prédéfinies associées à des contextes. De la sorte, le serveur 100 peut par exemple différencier un contexte B de domicile (adresse IP d’une box Internet grand public), d’un contexte C d’itinérance (adresse IP d’un équipement de réseau de téléphonie mobile) ou encore d’un contexte D d’espace collectif (adresses IP d’un stade ou d’un musée répertoriées).
L’étape 760 consiste alors à récupérer en mémoire 141 la liste des services disponibles (de façon similaire à l’étape 706) compte tenu du contexte dans lequel évolue le client 300. Le serveur peut soit utiliser le seul contexte local reçu à l’étape 756, soit le seul contexte « à distance » déterminé à l’étape 758, soit utiliser un contexte courant déterminé à partir des contextes local et à distance, par exemple en choisissant le contexte le plus restrictif en terme du nombre de services disponibles. Pour ce faire, le serveur accède le fichier (ou une copie) CONFIG2 ou équivalent évoqué plus haut.
La liste, optionnellement accompagnée du contexte « à distance » déterminé à l’étape 758, est retournée au client 300 lors de l’étape 762. L’application 305 la reçoit à l’étape 764 commandant l’affichage des services à l’utilisateur (étape 710). Lorsque l’utilisateur souhaite accéder à un contenu (i.e. un service tel qu’une chaîne – étapes 712-714-716), l’application 305 peut ajouter (766) à nouveau le contexte local déterminé à l’étape 752, dans la demande envoyée à l’étape 716.
Celle-ci est reçue par le serveur à l’étape 718 (avec éventuellement le contexte local). L’étape 768 consiste alors pour le serveur 100 à récupérer, en mémoire 141, les informations nécessaires pour initier la session de lecture du service demandé et générer un fichier d’initialisation contenant ces informations (comme à l’étape 720). A noter que les informations retournées dans le fichier peuvent, dans ce cas, être fonction du contexte (local, à distance ou courant) du client 300. Par exemple, l’adresse URL indiquée pour le fichier de description 132 peut être différente selon le contexte : celle d’un premier serveur pour un premier contexte, celle d’un second serveur pour un second contexte. Cela permet de faciliter l’accès au fichier 132 dans certains contextes et/ou de stocker différents fichiers de description 132 du même contenu selon le contexte (par exemple visant des segments média sur des espaces de stockage différents). Il en résulte une amélioration de l’accès au contenu selon le contexte dans lequel se trouve le client 300.
Le fichier d’initialisation, comprenant éventuellement l’indication du contexte « à distance », est alors envoyé au proxy 320 à l’étape 770 et reçu à l’étape 772 par le proxy 320. A l’étape optionnelle 774, celui-ci détermine le contexte courant comme décrit plus haut : contexte local (notamment si aucun contexte distant n’est reçu), contexte le plus restrictif, etc.
Puis à l’étape 776, le proxy 320, et plus précisément le module 340 de mise à disposition de flux, récupère la liste des pistes autorisées, avec leur mode d’obtention depuis le serveur 100 (unicast ou multicast), pour le contexte courant. Il s’agit pour le proxy 320 d’obtenir le fichier CONFIG2 et d’y récupérer le jeu contextuel de pistes autorisées correspondant au contexte courant.
A l’étape 778, le proxy 320 demande le fichier de description 132 de façon similaire à l’étape 726 et le reçoit à l’étape 780 (la demande est traitée à l’étape 728 par le serveur 100). A nouveau, le fichier de description 132 peut être obtenu directement en réponse à la requête de l’étape 716.
Les étapes 774-776 peuvent être réalisées avant, après ou en parallèle des étapes 778-780.
A l’étape 782, le proxy 320, et plus précisément le module 340 de mise à disposition de flux, sélectionne dans le fichier de description 132 reçu les pistes autorisées afin de générer le fichier de description modifié 341. En variante, le proxy 320 peut générer lui-même le fichier client de description 341 à partir de données de configuration reçues (qui n’ont pas déjà le format d’un fichier de description type manifest ou media playlist). C’est à cette étape 782 que le fichier 341’ peut être généré en lieu et place du fichier modifié 341 selon le mode de réalisation mis en œuvre. Le fichier modifié résultant peut par exemple être celui représenté, de façon simplifiée, à laFigure 5A.
Dans l’exemple de la chaîne 1 du contexte ID=1 (Figure 7), seule une piste de qualité M(HD) est conservée avec des adresses URL mises en local puisqu’il s’agit de contrôler le lecteur 310 pour qu’il demande, en mode unicast au proxy 320, les segments média générés par la conversion multicast-unicast du flux multicast M(HD) reçu du serveur 100.
Le fichier modifiée 341 est transmis au lecteur 310 à l’étape 784, reçu à l’étape 786 (similaire à l’étape 730).
L’étape 732 de sélection de la ou des pistes (qualité) les plus appropriées par le lecteur 310 est réalisée sur la base des pistes déclarées dans le fichier modifié 341 reçu.
Le lecteur demande alors périodiquement (734) les segments média déclarés dans le fichier 341 pour la piste sélectionnée (et, dans certaines implémentations de lecteur vidéo, la ou les liste(s) de lecture média qui y sont renseignées et sélectionnées par le lecteur vidéo).
Si la piste sélectionnée par le lecteur 310 est une piste directement accessible par le lecteur en mode unicast auprès du serveur 100 (telle que déclarée dans le fichier CONFIG2), les requêtes du lecteur 310 sont à destination du serveur 100 (car le fichier 341 indique des adresses URL du serveur). Dans ce cas, le proxy 320 relaie (788) simplement les requêtes unicast de segments média envoyées par le lecteur et les réponses reçues en retour (étapes 734-736).
Si en revanche la piste sélectionnée par le lecteur 310 correspond à un flux multicast, typiquement la piste M(HD) (telle que déclarée dans le fichier CONFIG2), le module 350 du proxy 320 reçoit les requêtes du lecteur 310 (car le fichier 341 indique des adresses URL locales).
Dans ce cas, à réception de la première requête demandant un segment média du flux multicast M(HD), le proxy 320 (plus précisément le module 351) s’abonne (étapes 790-792) au flux multicast M(HD) auprès du serveur 100.
Les datagrammes diffusés en continu par le serveur (étape 794) sont reçus par le proxy 320 (étape 796), convertis en segments média et stockés localement aux adresses URL prévues à cet effet (étape 798).
A chaque requête de segment média, le module 351 du proxy 320 sert (étape 799) ainsi le lecteur 310 à partir des segments média stockés localement.
Le contenu formé des segments média obtenus peut alors être affiché à l’utilisateur.
Le lecteur 310 peut réaliser une adaptation dynamique du contenu streamé selon des techniques classiques, en basculant d’une piste à l’autre telles que déclarées dans le fichier 341.
Les étapes 738-740 qui suivent permettent de gérer le zapping de l’utilisateur vers un nouveau service, auquel cas le procédé retourne à l’étape 716.
LaFigure 9illustre, à l’aide d’un ordinogramme, des étapes permettant de gérer un changement de contexte selon un mode de réalisation utilisant par exemple le fichier modifié 341 contenant les seules pistes autorisées.
L’étape 800 est réalisée par le proxy 320, et plus précisément le module 330, de façon régulière (périodiquement) ou en réponse à un ou des événements prédéterminés (par exemple un changement de réseau local).
L’étape 800 consiste pour le module 330 à déterminer le contexte dans lequel évolue le terminal 300 compte tenu de mesures courantes (par exemple nom SSID du réseau local, adresse IP de la borne 400, etc.). Cette étape est similaire à l’étape 752 décrite plus haut.
S’il est détecté (test 802) que le contexte ainsi déterminé est le même que le dernier contexte déterminé (local à l’étape 752 ou 800 ou courant à l’étape 774), le procédé reste à l’étape 800.
Autrement, le module de mise à disposition 340 est averti de ce changement, lequel met à jour (étape 804) le fichier client de description 341 compte tenu du nouveau contexte. Cette étape 804 peut simplement consister à regénérer un nouveau fichier client 341 conformément à l’étape 782 décrite plus haut en fonction du nouveau contexte.
Puis, lorsque le lecteur 310 sollicite à nouveau le fichier de description auprès du proxy 320 (par exemple toutes les 6s ou en réponse à une notification du module 340 avertissant de la disponibilité d’un nouveau fichier 341), le nouveau fichier client de description 341 est transmis au lecteur 310 de façon similaire à l’étape 784. Le procédé se poursuit alors par l’étape 786 de laFigure 8. Dans le cas du HTTP Live Streaming, le media playlist peut également être modifié lors des appels suivant le changement de contexte, par exemple pour basculer d’une piste unicast à multicast (ou inversement), ou pour inciter le lecteur vidéo à changer de piste (en déclarant les segments média de la piste en cours comme non disponibles).
Ainsi, le lecteur 310 a désormais accès aux seules pistes autorisées dans le nouveau contexte, sans que la lecture du contenu n’ait été coupée.
A noter que le proxy 320 peut déterminer, à l’aide du fichier CONFIG2, les éventuelles chaînes (plus généralement services) qui sont désormais accessibles pour le nouveau contexte alors qu’elles n’étaient pas disponibles avec l’ancien contexte, ou inversement. Ces chaînes peuvent être proposées à l’utilisateur pour l’autoriser à zapper dessus. En cas de besoin, le proxy 320 peut automatiquement demander des informations sur ces nouvelles chaînes (par exemple le nom s’il n’est pas indiqué dans le fichier CONFIG2).
LaFigure 9Aillustre une variante de gestion du changement de contexte.
Les étapes 800 et 802 demeurent inchangées.
En cas de détection d’un changement de contexte (sortie OUI du test 802), une notification de changement de contexte est envoyée par le proxy 320 au lecteur 310 à l’étape 810.
Cette notification peut consister en un message à afficher à l’utilisateur l’invitant à relancer le lecteur 310 ou l’application 305.
En variante, il peut s’agir d’une instruction relançant automatiquement le lecteur 310 ou l’application 305, sans intervention de l’utilisateur.
En cas de relance du lecteur 310 ou de l’application 305 (test 812), le procédé permet de retourner à l’étape 700 de laFigure 8. Le lecteur 310 va ainsi obtenir un nouveau fichier de description 341 comprenant les pistes autorisées pour le nouveau contexte.
LaFigure 9Billustre une autre variante de gestion du changement de contexte dans un cas d’utilisation du fichier 341’.
Les étapes 800 et 802 demeurent inchangées.
A détection d’un changement de contexte (sortie OUI du test 802), la nouvelle liste des pistes autorisées est obtenue à l’étape 820 similaire à l’étape 776 compte tenu du nouveau contexte détecté.
Puis à l’étape 822, le proxy 320, plus précisément le module de gestion de flux 350, applique les règles de gestion des flux correspondant à cette liste, à savoir par exemple :
- il délivre au lecteur 310 une liste de lecture média déclarant les segments média comme manquants ou non disponibles pour toutes les pistes nouvellement non autorisées et délivre une liste de lecture déclarant les segments média de façon normale pour les pistes nouvellement autorisées ; ou
- il remplace les segments média demandés par le lecteur 310 pour des pistes non autorisées par des segments média correspondant (même contenu) d’une piste autorisée ; et
- il sert le lecteur 310 avec les segments média demandés pour des pistes autorisées (soit comme simple relais pour des pistes unicast, soit après conversion multicast-unicast pour un flux reçu en multicast tel M(HD)).
- il délivre au lecteur 310 une liste de lecture média déclarant les segments média comme manquants ou non disponibles pour toutes les pistes nouvellement non autorisées et délivre une liste de lecture déclarant les segments média de façon normale pour les pistes nouvellement autorisées ; ou
- il remplace les segments média demandés par le lecteur 310 pour des pistes non autorisées par des segments média correspondant (même contenu) d’une piste autorisée ; et
- il sert le lecteur 310 avec les segments média demandés pour des pistes autorisées (soit comme simple relais pour des pistes unicast, soit après conversion multicast-unicast pour un flux reçu en multicast tel M(HD)).
De la sorte, le contenu d’un service autorisé dans deux contextes est continuellement affiché par le lecteur 310 alors que l’utilisateur change de l’un de ces contextes à l’autre. Bien entendu, si le service suivi n’est plus autorisé dans le nouveau contexte, aucun autre segment média ne peut être délivré au lecteur 310.
Dans la description qui précède, le module de mise à disposition 340 du proxy 320 génère un fichier de description 341/341’ pour le lecteur 310 en se basant principalement sur le fichier de description 132 reçu (ou toutes autres données de configuration reçues). En outre, le module de gestion de flux 350 du proxy 320 sert le lecteur 310 avec des segments média envoyés par le serveur 100 ou des segments média issus d’une conversion d’un flux multicast reçu du serveur 100.
Dans un mode de réalisation particulier, le proxy 320 peut également intégrer un flux du même contenu reçu par un équipement tiers présent dans le réseau local du contexte où évolue le terminal 300. C’est par exemple le cas du décodeur 600 dans le contexte B de laFigure 1.
Le décodeur 600 reçoit par exemple un contenu (service ou chaîne) diffusée (en mode broadcast) par voie satellite, câble, ADSL, fibre ou numérique terrestre.
Le décodeur 600 peut comprendre un module de mise à disposition de ce contenu en streaming unicast ou multicast. Dans ce cas, le proxy 320 découvrant cet équipement 600 lors d’une procédure de découverte (par exemple suivant le protocole Bonjour) détecte la disponibilité de ce contenu en streaming unicast ou multicast.
Dans le cas unicast, il récupère par exemple le fichier de description (manifest ou liste de lecture maître) correspondant ou toute donnée de configuration similaire. Le proxy 320 peut alors déterminer s’il s’agit d’un contenu également disponible auprès du serveur 100 (par exemple via un nom de fichier identique tel que défini dans le fichier de configuration ou de description 132 reçu du serveur 100 et celui reçu du décodeur 600).
Dans le cas multicast, le proxy 320 s’abonne au flux, récupère les datagrammes, les convertit en segments média et met ces derniers à disposition du lecteur 310 en mode unicast.
En variante à une diffusion unicast ou multicast par le décodeur, le proxy 320 peut récupérer le contenu diffusé et effectuer la conversion en segments média unicast localement. Des indications sur le contenu ainsi reçu permettent de déterminer s’il s’agit d’un contenu également disponible auprès du serveur 100.
La conversion en streaming unicast consiste en des opérations de segmentation, empaquetage, etc. du flux broadcast reçu en segments média, de façon similaire aux opérations réalisées par les modules 120, 130 et 140 décrits plus haut.
Les segments média ainsi produits sont stockés localement dans le proxy 320 (soit à leur génération soit à réception du streaming unicast ou multicast depuis le décodeur 600).
Si les segments média ainsi stockés localement correspondent à une qualité proposée par le serveur 100 (c’est-à-dire cette qualité est disponible dans le fichier de description 132 reçu), alors le module de gestion de flux 350 peut décider de communiquer, au lecteur demandant des segments média de ce contenu, soit des segments média obtenus auprès du serveur 100 (ou issus d’une conversion d’un flux multicast du serveur) soit ces segments média stockés localement. Cela ne nécessite pas de modification du fichier de description 341/341’ fourni au lecteur 310 dans les procédés décrits plus haut.
Le choix de servir l’un ou l’autre type de segments média par le module 350 peut être basé sur des règles de priorisation, ayant par exemple pour but de maximiser la qualité d’image affichée au client, ou de maximiser la stabilité de lecture, ou tout simplement de réduire les coûts. Un exemple d’implémentation pourrait être de privilégier certaines sources sur d’autres, typiquement privilégier des flux en provenance d’un décodeur local car il sera probablement plus stable (issu du broadcast, et diffusé uniquement sur le réseau local donc non dépendant de la fluctuation de la bande passante Internet).
Si les segments média ainsi stockés localement ne correspondent pas à une qualité proposée par le serveur 100 (c’est-à-dire cette qualité n’est pas disponible dans le fichier 132), alors cette « nouvelle » qualité peut être ajoutée au fichier 341/341’ lors de l’étape 782 avec une URL locale visant leur espace de stockage dans le proxy 320 (ou dans le décodeur local 600), le lecteur 310 y accédant de façon classique via un streaming unicast local. Cette approche permet d’améliorer l’efficacité de l’adaptation dynamique de contenu par le lecteur 310.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.
Claims (16)
- Procédé de distribution de contenu depuis un serveur (100) vers des clients (300) d’un réseau, le contenu étant disponible en différentes qualités, le procédé comprenant les étapes suivantes au niveau d’un client du réseau :
- recevoir (772), du serveur, un ou plusieurs fichiers de configuration (132) définissant une pluralité de pistes correspondant aux qualités différentes du même contenu disponibles aux clients en mode unicast auprès du serveur, au moins une première qualité (M(HD)) de contenu étant disponible en mode multicast auprès du serveur,
- obtenir (752, 774) une information de contexte représentative d’un environnement dans lequel le client évolue,
- sélectionner (776), en fonction de l’information de contexte, un jeu de pistes parmi plusieurs jeux comprenant une ou plusieurs pistes de contenu, au moins un jeu de pistes comprenant au moins une piste correspondant à l’au moins une première qualité d’un flux multicast,
- mettre à disposition (782, 784, 786) d’un lecteur (310) de contenu du client, en mode unicast, la ou les seules qualités de contenu correspondant aux pistes ainsi sélectionnées. - Procédé selon la revendication 1, dans lequel l’étape de mise à disposition comprend les étapes suivantes réalisées par le client :
générer (782) un fichier client de description (341) contenant la ou les seules pistes de contenu sélectionnées, et
transmettre (784, 786) le fichier client de description (341) au lecteur (310) de contenu de sorte que le lecteur de contenu accède par requêtes unicast audit contenu selon une qualité choisie par lui parmi celle ou celles correspondant aux pistes du fichier client de description. - Procédé selon la revendication 1 ou 2, comprenant en outre des étapes consistant à :
- détecter (802) un changement d’environnement dans lequel le client (300) évolue et obtenir une nouvelle information de contexte correspondante, et
- sélectionner (776, 804, 820), en fonction de la nouvelle information de contexte, un nouveau jeu de pistes à mettre à disposition du lecteur de contenu. - Procédé selon les revendications 2 et 3, comprenant en outre une étape consistant à générer (804) un nouveau fichier client de description (341) en fonction du nouveau jeu de pistes et le transmettre (806) au lecteur de contenu (310).
- Procédé selon l’une des revendications 1 à 4, dans lequel obtenir l’information de contexte comprend déterminer (752) l’information de contexte à partir d’un identifiant d’une borne d’accès réseau (400) vers le serveur (100), borne à laquelle est connecté le client (300), ou à partir d’un identifiant d’un réseau local auquel le client est connecté.
- Procédé selon l’une des revendications 1 à 4, dans lequel obtenir l’information de contexte comprend déterminer l’information de contexte à partir de la découverte d’un équipement prédéfini (600) dans un réseau local auquel le client est connecté.
- Procédé selon l’une des revendications 1 à 6, dans lequel obtenir l’information de contexte comprend déterminer l’information de contexte à partir d’une évaluation de contexte faite (756) et envoyée (762) par le serveur (100) au client (300).
- Procédé selon l’une des revendications 1 à 7, dans lequel l’étape consistant à sélectionner (776) une ou plusieurs pistes est réalisée à partir d’une information de configuration (CONFIG2) associant, à chaque information de contexte, un jeu de pistes lisant une ou plusieurs pistes autorisées et leurs modes de diffusion respectifs, unicast ou multicast, depuis le serveur.
- Procédé selon l’une des revendications 1 à 8, dans lequel l’étape consistant à sélectionner (776) comprend la sélection, pour une première information de contexte, d’un premier jeu de pistes comportant seulement une ou plusieurs pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur (100).
- Procédé selon l’une des revendications 1 à 8, dans lequel l’étape consistant à sélectionner (776) comprend la sélection, pour une deuxième information de contexte, d’un deuxième jeu de pistes comportant une ou plusieurs pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur et comportant un sous-ensemble des pistes correspondant à des qualités disponibles en mode unicast auprès du serveur (100).
- Procédé selon l’une des revendications 1 à 8, dans lequel l’étape consistant à sélectionner (776) comprend la sélection, pour une troisième information de contexte, d’un troisième jeu de pistes comportant une ou plusieurs pistes correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur et comportant l’ensemble des pistes correspondant aux autres qualités disponibles en mode unicast auprès du serveur (100).
- Procédé selon l’une des revendications 1 à 8, dans lequel l’étape consistant à sélectionner (776) comprend la sélection, pour une quatrième information de contexte, d’un quatrième jeu de pistes ne comportant aucune piste correspondant à l’au moins une première qualité disponible en mode multicast auprès du serveur et comportant une ou plusieurs des pistes correspondant aux qualités disponibles en mode unicast auprès du serveur (100).
- Procédé selon l’une des revendications 9 à 12, dans lequel l’étape consistant à sélectionner (776) comprendre l’ajout d’une piste correspondant à une qualité d’un autre flux du contenu reçu via un récepteur de diffusion (600) présent dans un réseau local au client.
- Procédé selon l’une des revendications 1 à 13, dans lequel l’étape de mise à disposition comprend les étapes suivantes réalisées par le client :
- s'abonner (790) au flux multicast correspondant à la première qualité pour recevoir le flux multicast, et
- convertir (798) le flux multicast reçu (796) en segments accessibles localement, en mode unicast, par le lecteur (310) de contenu demandant la première qualité de contenu. - Procédé selon l’une des revendications 1 à 14, dans lequel le fichier de configuration est un fichier de description de présentation média.
- Dispositif client (300) connecté à un réseau (200) qui comprend un serveur (100) distribuant du contenu, le contenu étant disponible en différentes qualités, le dispositif comprenant :
- un lecteur de contenu (310),
- une interface de communication configurée pour recevoir, du serveur (100), un ou plusieurs fichiers de configuration (132) définissant une pluralité de pistes correspondant aux qualités différentes du même contenu disponibles à des clients (300) en mode unicast auprès du serveur, au moins une première qualité de contenu (M(HD)) étant disponible en mode multicast auprès du serveur,
- un module de détermination de contexte (330) configuré pour obtenir une information de contexte représentative d’un environnement dans lequel le dispositif client évolue,
- un module de sélection (340) configuré pour sélectionner, en fonction de l’information de contexte, un jeu de pistes parmi plusieurs jeux comprenant une ou plusieurs pistes de contenu, au moins un jeu de pistes comprenant au moins une piste correspondant à l’au moins une première qualité d’un flux multicast, et
- un module de gestion (340, 350) configuré pour mettre à disposition du lecteur de contenu, en mode unicast, la ou les seules qualités de contenu correspondant aux pistes ainsi sélectionnées.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1901403A FR3092720B1 (fr) | 2019-02-12 | 2019-02-12 | Streaming adaptatif et contextuel |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1901403A FR3092720B1 (fr) | 2019-02-12 | 2019-02-12 | Streaming adaptatif et contextuel |
| FR1901403 | 2019-02-12 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3092720A1 true FR3092720A1 (fr) | 2020-08-14 |
| FR3092720B1 FR3092720B1 (fr) | 2021-03-05 |
Family
ID=67185287
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1901403A Active FR3092720B1 (fr) | 2019-02-12 | 2019-02-12 | Streaming adaptatif et contextuel |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3092720B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024013463A1 (fr) | 2022-07-15 | 2024-01-18 | Groupe Canal + | Streaming vidéo adaptatif hybride amélioré |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015101782A1 (fr) | 2014-01-03 | 2015-07-09 | British Broadcasting Corporation | Acheminement de contenu |
| EP3016396A1 (fr) * | 2013-06-26 | 2016-05-04 | Sony Corporation | Dispositif, procédé et système de fourniture de contenu, programme et dispositif de terminal |
| US9674251B2 (en) * | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
-
2019
- 2019-02-12 FR FR1901403A patent/FR3092720B1/fr active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9674251B2 (en) * | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
| EP3016396A1 (fr) * | 2013-06-26 | 2016-05-04 | Sony Corporation | Dispositif, procédé et système de fourniture de contenu, programme et dispositif de terminal |
| WO2015101782A1 (fr) | 2014-01-03 | 2015-07-09 | British Broadcasting Corporation | Acheminement de contenu |
Non-Patent Citations (3)
| Title |
|---|
| MAMADOU TOURAD DIALLO ET AL: "Adaptation of audiovisual contents and their delivery means", COMMUNICATIONS OF THE ACM, vol. 56, no. 11, 1 November 2013 (2013-11-01), pages 86 - 93, XP055142159, ISSN: 0001-0782, DOI: 10.1145/2500726 * |
| QUALCOMM INCORPORATED ET AL: "Consistent Support for Hybrid Services", vol. SA WG4, no. Kista, Sweden; 20180409 - 20180413, 10 June 2018 (2018-06-10), XP051458435, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings%5F3GPP%5FSYNC/SA/Docs> [retrieved on 20180610] * |
| RICHARD BRADBURY: "ABR Multicast Taskforce - Reference architecture", no. r19, 13 February 2018 (2018-02-13), XP017855442, Retrieved from the Internet <URL:https://www.dvb.org/resources/restricted/members/documents/TM-IPI/ABR%20Multicast/TM-IPI3247r19_ABR-Multicast-Taskforce---Reference-architecture.docx> [retrieved on 20180213] * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024013463A1 (fr) | 2022-07-15 | 2024-01-18 | Groupe Canal + | Streaming vidéo adaptatif hybride amélioré |
| FR3138020A1 (fr) * | 2022-07-15 | 2024-01-19 | Groupe Canal + | Streaming vidéo adaptatif hybride amélioré |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3092720B1 (fr) | 2021-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2874472A1 (fr) | Procede, article de fabrication et dispositif destines a mettre a jour un logiciel dans un dispositif individuel | |
| FR2923111A1 (fr) | Procede de selection de service audio et/ou video recu. | |
| EP3840388B1 (fr) | Equipement décodeur à double liaison audio | |
| RU2668549C2 (ru) | Устройство сервера, устройство клиент, способ распределения содержания и компьютерная программа | |
| FR3092720A1 (fr) | Streaming adaptatif et contextuel | |
| WO2001041439A1 (fr) | Procede de diffusion de television numerique, signal numerique et equipement associes | |
| EP4035408A1 (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 | |
| 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 | |
| EP2362607B1 (fr) | Procédé de distribution d'un contenu vers un utilisateur | |
| FR3138020A1 (fr) | Streaming vidéo adaptatif hybride amélioré | |
| WO2023208688A1 (fr) | Gestion de la restitution d'un contenu multimédia | |
| FR3102595A1 (fr) | Procédé de diffusion d’une vidéo par un dispositif client, dispositif client et système associé | |
| EP2083554A1 (fr) | Procédé de transmission en direct de contenus en vue d'une récupération en différé en mode P2P après découpage, et dispositif de controle et équipements associés | |
| EP2854415B1 (fr) | Procédé de transmission dynamique de données d'information relatives à un programme audio et/ou vidéo | |
| EP3840391A1 (fr) | Gestion de la restitution d'un contenu multimédia et d'une interface de navigation sur un écran | |
| EP4184922A1 (fr) | Procédé de gestion de l' accès à un contenu multimédia | |
| WO2020234030A1 (fr) | Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has | |
| WO2013045815A1 (fr) | Procede et dispositif de gestion dynamique de la distribution de donnees dans un reseau de telecommunications | |
| 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. | |
| WO2021209706A1 (fr) | Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau | |
| WO2021105585A1 (fr) | Procédé de gestion d'une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants | |
| FR3030982A1 (fr) | Procede d'enregistrement automatique de contenus video recommandes, dispositif et produit programme d'ordinateur associes. | |
| 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 | |
| FR3131160A1 (fr) | Procédé de restitution d’un contenu multimédia, programme d’ordinateur et terminal lecteur de flux multimédia correspondants. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200814 |
|
| 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 |