FR3101503A1 - 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 - Google Patents

Abstract

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. L'invention concerne un procédé de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique (C1) au sein d’un terminal lecteur de flux multimédia (30) connecté à un réseau de communication mobile. Le contenu numérique est associé à un fichier de description (7) du contenu numérique, comprenant une liste de segments temporels (C1i@Nj) du contenu, associés chacun à plusieurs débits d’encodage du contenu. Un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia. Selon l'invention, au lancement du téléchargement progressif adaptatif du contenu numérique, un tel procédé de gestion met en œuvre : - une détermination (DET 301) d’un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels à au moins certains des débits d’encodage, - une sélection (SEL 302) d’un débit d’encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données. Figure pour l’abrégé : Fig 3

Description

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

Le domaine de l'invention est celui des contenus multimédias numériques, à savoir les contenus audio et/ou vidéo numériques. Plus précisément, l'invention concerne la gestion de la consommation de données d’un utilisateur souhaitant accéder à des contenus numériques selon une technique dite de téléchargement progressif adaptatif, au travers d’un réseau de communication mobile.

Art antérieur

L’accès à un contenu multimédia, tel que la télévision ou la vidéo à la demande, est possible aujourd’hui, pour la plupart des terminaux de restitution, même lorsqu’ils sont en situation de mobilité, à travers un réseau de communication mobile de type 4G par exemple.

Le terminal émet généralement une requête à destination d’un serveur, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu.

Le terminal est adapté pour recevoir ces contenus numériques sous forme de données multimédia et pour en faire une restitution. Cette restitution consiste à fournir au niveau du terminal le contenu numérique sous une forme accessible à l’utilisateur. Par exemple, des données reçues correspondant à une vidéo sont généralement décodées, puis restituées au niveau du terminal sous la forme d’un affichage de la vidéo correspondante avec sa bande-son associée. Dans la suite, par souci de simplification, on assimilera le contenu numérique à une vidéo et la restitution par le terminal, ou consommation par l’utilisateur du terminal, à une visualisation sur l’écran du terminal.

La diffusion de contenus numériques est souvent basée sur des protocoles client-serveur de la famille HTTP (de l’anglais « Hyper Text Transport Protocol »). En particulier, le téléchargement en mode progressif des contenus numériques, aussi appelé streaming, permet de transporter et consommer les données en temps réel, c'est-à-dire que les données numériques sont transmises sur le réseau et restituées par le terminal au fur et à mesure de leur arrivée. Le terminal reçoit et stocke une partie des données numériques dans une mémoire tampon avant de les restituer. Ce mode de distribution est particulièrement utile quand le débit dont dispose l’utilisateur n’est pas garanti pour le transfert en temps réel de la vidéo, ce qui est tout particulièrement le cas lorsque le terminal est connecté à un réseau de communication mobile, par exemple un réseau de type 4G, connu pour ses variabilités de bande passante.

Le téléchargement progressif adaptatif, en anglais HTTP Adaptative Streaming, d’abréviation HAS, permet de surcroît de diffuser et recevoir des données suivant différentes qualités correspondant par exemple à différents débits. Ces différentes qualités sont décrites dans un fichier de paramètres disponible en téléchargement sur un serveur de données, par exemple un serveur de contenus. Quand le terminal client souhaite accéder à un contenu, ce fichier de description permet de sélectionner le bon format pour le contenu à consommer en fonction de la bande passante disponible ou des capacités de stockage et de décodage du terminal client. Ce type de technique permet notamment de tenir compte des variations de bande passante sur la liaison entre le terminal client et le serveur de contenus.

Il existe plusieurs solutions techniques pour faciliter la distribution d’un tel contenu en streaming, comme par exemple les solutions propriétaires Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming ou encore la norme MPEG-DASH de l’organisme ISO/IEC qui sera décrite ci-après. Ces méthodes proposent d’adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents ou manifestes, contenant les adresses des différents segments aux différentes qualités du contenu multimédia.

Ainsi, la norme MPEG-DASH (pour l’anglais “Dynamic Adaptive Streaming over HTTP”, en français « diffusion en flux adaptatif dynamique sur HTTP ») est un standard de format de diffusion audiovisuelle sur Internet. Il se base sur la préparation du contenu en différentes présentations de qualité et débit variables, découpées en segments de courte durée (de l’ordre de quelques secondes), également appelés « chunks ». Chacun de ces segments est rendu disponible individuellement au moyen d'un protocole d'échange. Le protocole principalement ciblé est le protocole HTTP, mais d'autres protocoles (par exemple FTP) peuvent également être utilisés. L'organisation des segments et les paramètres associés sont publiés dans un manifeste au format XML.

Le principe sous-jacent à cette norme est que le client MPEG-DASH effectue une estimation de la bande passante disponible pour la réception des segments, et, en fonction du remplissage de son tampon de réception, choisit, pour le prochain segment à charger, une représentation dont le débit :

• assure la meilleure qualité possible,
• et permet un délai de réception compatible avec le rendu ininterrompu du contenu.

Ainsi, pour s’adapter à la variation des conditions réseau, notamment en termes de bande passante, les solutions existantes de téléchargement adaptatif permettent au terminal client de passer d’une version du contenu encodée à un certain débit, à une autre encodée à un autre débit, au cours du téléchargement. En effet, chaque version du contenu est divisée en segments de même durée. Pour permettre une restitution en continu du contenu sur le terminal, chaque segment doit atteindre le terminal avant son instant programmé de restitution. La qualité perçue associée à un segment augmente avec la taille du segment, exprimée en bits, mais dans le même temps, des segments plus gros requièrent un temps de transmission plus important, et donc présentent un risque accru de ne pas être reçus à temps pour une restitution en continu du contenu.

Le terminal de restitution doit donc trouver un compromis entre la qualité globale du contenu, et sa restitution ininterrompue, en sélectionnant avec soin le prochain segment à télécharger, parmi les différents débits d’encodage proposés. Il existe pour ce faire différents algorithmes de sélection de la qualité du contenu en fonction de la bande passante disponible, qui peuvent présenter des stratégies plus ou moins agressives, ou plus ou moins sécuritaires.

La consommation de contenus numériques en téléchargement progressif adaptatif (HAS) tend à se démocratiser. Elle est notamment utilisée par de nombreux services de streaming (en français, diffusion en mode continu, ou lecture en continu), mais également par certains décodeurs TV, ou set-top-box, qui l’utilisent pour accéder à des contenus délinéarisés, tels que la vidéo à la demande (VOD), la diffusion en différé de programmes télévisuels (Replay), ou encore les offres de type Network PVR (pour « Network Personal Video Recorder », i.e. un service d’enregistrement des contenus numériques, effectué par le fournisseur de contenus lui-même plutôt qu’au domicile de l’utilisateur final).

En outre, d’autres dispositifs tels que des appareils lecteurs de flux multimédia en temps réel accèdent également aux contenus numériques en mode de téléchargement adaptatif progressif pour des contenus télévisuels en temps réel (ou Live). C’est le cas par exemple de l’appareil Chromecast® développé par Google®, ou de la CléTV® d’Orange®. De tels appareils, plus génériquement désignés sous le nom de Clef HDMI, peuvent également être utilisés pour accéder à des contenus de type vidéo à la demande.

De tels appareils se branchent classiquement sur le port HDMI d’un téléviseur et communiquent, par exemple par connexion Wi-Fi®, avec un autre appareil du réseau de communication domestique connecté à un réseau de communication étendu (par exemple un téléphone intelligent de type smartphone, connecté à un réseau mobile 4G), afin de restituer, sur le téléviseur, le contenu multimédia reçu par une application logicielle compatible. On désignera par la suite ces appareils sous la désignation générique de Clef HDMI.

Dans ce cadre spécifique de diffusion de contenus sur un réseau de communication mobile, il est important de prendre en compte la limite de consommation de données autorisée pour le terminal client. Cette limite peut correspondre à un volume de données associé à une carte prépayée achetée par l’utilisateur, ou à un forfait mensuel qu’il a souscrit auprès de l’opérateur du réseau de communication étendu, par exemple le réseau mobile. Ce volume maximum de données consommable est plus communément désigné sous le terme de godet de données, ou « godet data ».

En effet, le terme anglais « data » signifie « données ». En langage mobile, la data représente les données téléchargées sur un téléphone ou un terminal mobile grâce à Internet. Un forfait data mobile permet donc aux utilisateurs de naviguer sur Internet avec un téléphone mobile, selon des volumes spécifiques alloués par l’opérateur du réseau. Les forfaits illimités dans ce domaine n'existent pas à proprement parler. Les forfaits data comportent un volume de données maximum autorisé, généralement exprimé en Mégaoctets ou Gigaoctets.

Lorsque l’utilisateur consomme un contenu ou un flux de données selon une technique de téléchargement progressif adaptatif HAS sur un réseau de communication mobile, le client HAS embarqué sur son terminal lecteur de flux multimédia a, par principe, pour objectif, d’atteindre la meilleure qualité de restitution possible pour l’utilisateur, en fonction des contraintes de ressource et de bande passante, et donc de viser le débit d’encodage maximum disponible pour le contenu à télécharger. Il en résulte que le téléchargement de contenu peut consommer une très grosse proportion, voire l’intégralité, du godet de données alloué à l’utilisateur, sans que ce dernier ne dispose d’un quelconque moyen d’action pour l’empêcher. En effet, la seule option dont dispose l’utilisateur est, de façon assez radicale, de renoncer à accéder au flux, et donc de renoncer à regarder le contenu multimédia choisi.

Cette situation s’avère problématique dans la mesure où elle peut conduire l’utilisateur, en situation de mobilité, à dépasser son « godet data », ce qui peut s’avérer onéreux, ou à en consommer l’intégralité en tout début de mois, le privant de ressources pour la fin de la période.

Il existe donc un besoin d’une technique de gestion de téléchargement progressif adaptatif de contenu, notamment pour un utilisateur connecté à un réseau de communication mobile, permettant une meilleure maîtrise de sa consommation de données, par rapport aux solutions antérieures. Notamment, il existe un besoin d’une telle technique qui permette à un utilisateur de visualiser un contenu téléchargé en HAS via un réseau mobile, tout en lui assurant une maîtrise de la consommation de son godet de données.

L'invention répond à ce besoin en proposant un procédé de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique au sein d’un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Le contenu numérique est associé à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage du contenu. Un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia.

Selon l’invention, au lancement du téléchargement progressif adaptatif du contenu numérique, un tel procédé de gestion met en œuvre :

• une détermination d’un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels du contenu à au moins certains des débits d’encodage,
• une sélection d’un débit d’encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données.

Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive du téléchargement progressif adaptatif de contenu, dans le cas où le terminal lecteur de flux multimédia dispose d’un volume maximum de données consommables au sein de son réseau d’accès au contenu. Une telle valeur limite de consommation de données, également appelée « godet data », peut correspondre à un volume de données autorisé dans le cadre d’un forfait mensuel souscrit auprès d’un opérateur du réseau, ou associé à une carte prépayée achetée auprès de cet opérateur.

Le procédé selon un mode de réalisation de l'invention propose de tenir compte de ce « godet data » dans le choix du débit d’encodage auquel le client HAS embarqué sur le terminal lecteur de flux multimédia télécharge les segments temporels du contenu. Ainsi, au lieu de systématiquement télécharger les segments temporels du contenu au débit d’encodage maximum accessible, compte tenu des contraintes du réseau et du serveur de contenu, on évalue la consommation de données résultant du téléchargement du contenu à différents débits d’encodage ; en tenant compte, de cette évaluation de consommation d’une part, et du godet data de l’utilisateur d’autre part, on sélectionne un débit d’encodage maximum permettant de brider le téléchargement progressif adaptatif HAS du contenu, afin de mieux maîtriser la part du godet data consacrée à ce téléchargement.

Il est ainsi possible pour l’utilisateur de bénéficier des avantages du téléchargement progressif adaptatif HAS de contenu, sans que cela ne se fasse au détriment de son godet data, qui doit pouvoir être utilisé à d’autres fins ou pour d’autres applications : on offre ainsi à l’utilisateur des outils intéressants de maîtrise de sa consommation de données.

Selon une caractéristique avantageuse, un tel procédé de gestion comprend également un affichage, sur un terminal de restitution associé au terminal lecteur de flux multimédia, des volumes de données consommés déterminés pour au moins certains des débits d’encodage.

L’utilisateur peut ainsi aisément avoir connaissance du volume de données qui sera consommé par son terminal s’il lance le téléchargement du contenu qu’il a choisi, à l’un ou l’autre des débits d’encodage disponibles : il lui suffit pour ce faire de consulter l’écran de son terminal de restitution, sur lequel ces volumes lui sont présentés. Ceci est particulièrement avantageux lorsque l’utilisateur est en solution de mobilité, et qu’il n’appréhende pas nécessairement l’impact qu’aura le lancement du téléchargement de contenu sur sa consommation de données, et donc sur son godet data. Une consultation de l’écran de son terminal de restitution (par exemple son téléphone mobile) lui indique directement, par exemple sous forme d’un tableau comparatif, les volumes de données, par exemple exprimés en Gigabits ou en Mégabits, associés aux différents débits d’encodage du contenu.

Pour simplifier le calcul, on fait par exemple l’hypothèse que tous les segments temporels du contenu seront téléchargés au même débit d’encodage, ou à la même résolution, sans tenir compte des éventuelles fluctuations associées aux évolutions des contraintes de ressources du réseau ou du serveur de contenu.

On notera que le terminal de restitution peut être le terminal lecteur de flux multimédia lui-même (par exemple un téléphone mobile intelligent de type smartphone), ou être distinct de celui-ci (par exemple un téléviseur connecté à une Clef HDMI).

Selon une caractéristique optionnelle avantageuse, les volumes de données consommés, déterminés pour au moins certains des débits d’encodage, sont affichés sous forme d’une proportion du godet de données.

L’utilisateur peut ainsi directement appréhender quel pourcentage de son godet data sera consommé en cas de lancement du téléchargement du contenu à tel ou tel débit d’encodage. Une telle présentation est plus parlante et compréhensible pour l’utilisateur. Elle nécessite bien sûr que ce godet data soit connu du terminal lecteur de flux multimédia.

Selon une autre caractéristique optionnelle avantageuse, un tel procédé de gestion comprend également un affichage, sur le terminal de restitution, d’un volume de données restant à consommer par le terminal lecteur de flux multimédia, à l’issue du téléchargement des segments temporels du contenu à au moins certains des débits d’encodage.

Ainsi, l’utilisateur sait, non seulement, quel volume de données sera consommé par téléchargement du contenu, mais également de quel volume de données il disposera encore à l’issue de ce téléchargement, en tenant compte de son godet data, et éventuellement de la part qu’il en a déjà consommée. Cet affichage de volume restant peut se faire en Gigabits/Megabits, ou en pourcentage du godet data. L’utilisateur peut ainsi aisément choisir le débit d’encodage maximum auquel il souhaite se limiter, pour ne pas consommer une trop grosse partie de son godet data, et conserver suffisamment de crédit de données, par exemple jusqu’à la fin du mois.

Selon une autre caractéristique avantageuse, les volumes de données affichés correspondent aux seuls débits d’encodage pour lesquels le téléchargement des segments temporels du contenu n’induit pas de dépassement du godet de données.

Ainsi, si le godet data de l’utilisateur est connu, on peut lui indiquer uniquement les débits d’encodage auxquels il peut prétendre pour pouvoir, a minima, voir intégralement le contenu, s’il ne lui reste plus assez de données consommables pour le voir en qualité maximale.

Selon une autre caractéristique, un tel procédé de gestion comprend également une saisie, sur un terminal de restitution associé au terminal lecteur de flux multimédia, du godet de données.

Ainsi, l’utilisateur pré-renseigne son godet data, pour que cette information soit accessible au terminal lecteur de flux multimédia. Cette saisie peut s’opérer dans une phase d’installation ou de configuration du service de téléchargement progressif adaptatif. Elle peut également être demandée à l’utilisateur par l’affichage d’une fenêtre de type « pop in », qui l’informe d’une nouveauté sur le service, et l’interroge sur cette nouvelle information utile qu’est son godet data.

En variante, si l’opérateur du réseau mobile contrôle de bout en bout le service de téléchargement progressif adaptatif, il peut extraire l’information du godet data de l’utilisateur de son profil ou de sa facturation, pour qu’elle soit accessible au terminal lecteur de flux multimédia.

Selon un mode de réalisation de l’invention, la sélection du débit d’encodage maximum du contenu autorisé pour le téléchargement est effectuée par un utilisateur via une interface d’un terminal de restitution associé au terminal lecteur de flux multimédia.

Ainsi, l’utilisateur choisit lui-même le débit d’encodage maximum à fixer, via l’interface de son terminal de restitution, par exemple par sélection d’un menu en surbrillance ou par saisie dans une fenêtre pop in. Cette sélection peut être valable uniquement pour un contenu donné, ou peut être prise en compte pour tous les contenus accessibles via le service de téléchargement adaptatif HAS, ou encore pour tous les contenus téléchargés pendant une période donnée (par exemple au cours du mois courant).

L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé tel que décrit précédemment, lorsqu’il est exécuté par un processeur.

L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique selon l’invention, tel que décrit ci-dessus.

Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.

D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d’affichage précité.

L’invention concerne encore un dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique au sein d’un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Un tel contenu numérique est associé à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage du contenu ; un volume maximum de données à consommer au sein du réseau de communication mobile, appelé godet de données, est alloué au terminal lecteur de flux multimédia.

Selon l’invention, un tel dispositif comprend :

- un module de détermination d’un volume de données qui serait consommé par le terminal lecteur de flux multimédia par téléchargement des segments temporels du contenu à au moins certains des débits d’encodage,

- un module de sélection d’un débit d’encodage maximum du contenu autorisé pour le téléchargement, en fonction du volume de données consommé qui lui est associé, et du godet de données.

Selon un mode de réalisation, un tel dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique comprend également un module de transmission d’une commande, vers un terminal de restitution associé au terminal lecteur de flux multimédia, d’affichage des volumes de données consommés déterminés pour au moins certains des débits d’encodage.

Une telle commande peut être une commande interne au dispositif lorsque ce dernier est intégré dans le terminal de restitution lui-même.

L’invention concerne encore un terminal lecteur de flux multimédia qui comprend un dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique tel que décrit précédemment.

Le dispositif de gestion du téléchargement progressif adaptatif, le terminal lecteur de flux multimédia de restitution et le programme d'ordinateur selon des modes de réalisation de l’invention présentent en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document. Notamment, ils présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion du téléchargement progressif adaptatif d’un contenu selon un mode de réalisation de la présente invention.

Présentation des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

présente une architecture de téléchargement progressif sur réseau mobile basée sur l’utilisation du streaming adaptatif selon l’invention ;

illustre de façon schématique la structure matérielle d’un terminal lecteur de flux multimédia intégrant un dispositif de gestion de téléchargement progressif adaptatif selon un mode de réalisation de l’invention ;

décrit un exemple de bridage de la qualité maximale d’un flux multimédia obtenu en mode téléchargement progressif adaptatif par un terminal lecteur de flux multimédia de [Fig 1] ou [Fig 2].

Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention repose sur la possibilité, dans le cadre du téléchargement progressif adaptatif d’un contenu, de sélectionner le débit d’encodage maximum du contenu autorisé pour le téléchargement, afin de ne pas consommer une trop grosse part du godet de données de l’utilisateur, notamment lorsqu’il est en situation de mobilité.

On présente désormais, en relation avec , une architecture de téléchargement progressif basée sur l’utilisation du streaming adaptatif selon l’invention.

Le terminal 3, par exemple un téléphone intelligent de type « smartphone » et le terminal 4, par exemple une tablette, sont, dans cet exemple, connectés à un réseau mobile de communication étendu 1, par exemple un réseau de type 4G. Ils communiquent avec un terminal 8, par exemple une clef HDMI connectée à un téléviseur 5.

Un serveur de contenus numériques 2 se trouve selon cet exemple dans le réseau étendu (WAN, 1) et reçoit par exemple des chaînes de contenus de télévision numérique en provenance d’un réseau de télévision diffusée, non représenté, et/ou des vidéos à la demande, et les met à disposition des terminaux clients.

Les terminaux client 3 et 4 peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.).

Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre les terminaux client 3, 4 et le serveur 2, à une technique de téléchargement progressif adaptatif, en anglais « adaptive streaming », abrégé en HAS basée sur le protocole HTTP. Ce type de technique permet notamment d'offrir une bonne qualité de contenus à l’utilisateur en tenant compte des variations de bande passante qui peuvent se produire sur la liaison entre le terminal client 3, 4 et le serveur de contenus 2.

Classiquement, différentes qualités peuvent être encodées pour le même contenu d’une chaîne, correspondant par exemple à différents débits. Plus généralement, on parlera de qualité pour se référer à une certaine résolution du contenu numérique (résolution spatiale, temporelle, niveau de qualité associée à la compression vidéo et/ou audio) avec un certain débit. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (ou « fragments » de contenu, en anglais « chunks », ces trois mots étant utilisés indifféremment dans l’ensemble de ce document).

La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les fragments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L’ensemble de ces paramètres (qualités, adresses des fragments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description. On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d’informations descriptives du contenu, accessible à une certaine adresse.

Les terminaux 3, 4 possèdent leurs propres caractéristiques en termes de capacité de décodage, d’affichage, etc. Dans un contexte de téléchargement adaptatif progressif, ils peuvent adapter leurs requêtes pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui leur correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits 512 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté N1), 1024 kb/s (N2), 2048 kb/s (N3) et que le terminal client dispose d’une bande passante de 3000 kb/s, il peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 2048 kb/s. De manière générale, on note « Ci@Nj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description).

Les terminaux clients 3, 4 reçoivent les données en provenance du réseau mobile étendu 1 et assurent leur décodage, et éventuellement leur restitution sur leur écran, ou leur transmission à la clef HDMI 8 pour restitution sur l’écran du téléviseur 5. En variante, les décodeurs peuvent se trouver ailleurs dans le réseau, notamment au niveau d’un élément de type STB (de l’anglais Set-Top-Box) (non représenté) associé à un téléviseur.

Dans cet exemple, pour visualiser un contenu, le terminal 3, 4 ou 8 récupère tout d’abord une adresse du document de description 7 du contenu (par exemple, C1) souhaité. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH (noté « C.mpd ») et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifest ». Ce fichier peut être récupéré directement auprès d’un serveur Internet du réseau étendu 1, ou se trouver déjà sur le terminal au moment de la requête.

Un exemple de fichier manifest (MPD) conforme à la norme MPEG-DASH et comportant la description de contenus disponibles dans trois qualités différentes (N1 = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s) des contenus fragmentés est présenté enannexe 1. Ce fichier manifest simplifié décrit des contenus numériques dans une syntaxe XML (de l'Anglais « eXtended Markup Language»), comprenant une liste de contenus sous forme de fragments classiquement décrits entre une balise ouvrante (<SegmentList>) et une balise fermante (</SegmentList>). La découpe en fragments permet notamment de s’adapter finement aux fluctuations de la bande passante. Chaque fragment correspond à une certaine durée (champ « duration ») avec plusieurs niveaux de qualité et permet de générer leurs adresses (URL – Uniform Resource Locator). Cette génération est faite dans cet exemple à l’aide des éléments « BaseURL » (« HTTP://server.com ») qui indique l’adresse du serveur de contenus et « SegmentURL » qui liste les parties complémentaires des adresses des différents fragments :

- « C1_512kb_1.mp4 » pour le premier fragment du contenu « C1 » à 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »),

- « C1_512kb_2.mp4 » pour le second fragment,

- etc.

Une fois qu’il dispose des adresses de fragments correspondant au contenu souhaité, le terminal procède à l’obtention des fragments via un téléchargement à ces adresses. On notera que ce téléchargement s’opère ici, traditionnellement, au travers d’une URL HTTP, mais pourrait également s’opérer au travers d’une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple).

On suppose ici que la clef HDMI 8 est connectée au téléviseur 5 par branchement sur le port HDMI de ce dernier, et est utilisée pour restituer, sur l’écran du téléviseur 5, un contenu C1, décrit dans un fichier manifeste 7. On notera que le contenu C1 peut être un programme télévisuel diffusé en direct ou en différé, ou une vidéo à la demande, ou tout autre contenu multimédia de durée déterminée ou déterminable.

Dans cet exemple, la clef HDMI 8 est connectée en WiFi® directement à la tablette 4 ou au téléphone intelligent 3, par l’intermédiaire duquel elle peut accéder au réseau de communication étendu 1, par exemple via une connexion 4G.

La clef HDMI 8 peut également être pilotée par l’utilisateur au moyen du téléphone intelligent 3, sur lequel est installé une application logicielle de commande de la clef HDMI 8.

Les fragments de contenu obtenus par le smartphone 3 ou la tablette 4 sont par exemple transmis en WiFi® à la clef HDMI 8, qui pilote leur affichage sur l’écran du téléviseur 5, pour restitution à l’utilisateur.

représente une architecture d’un terminal lecteur de flux multimédia selon un mode de réalisation de l’invention, par exemple la clef HDMI 8, ou le téléphone intelligent 3, de [Fig 1]. On décrit plus spécifiquement dans la suite l’exemple de la clef HDMI 8.

Il comprend, classiquement, des mémoires M associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l’anglais« Read Only Memory ») ou RAM (de l’anglais« Random Access Memory ») ou encore Flash. La clef HDMI 8 communique avec le réseau Internet étendu 1 via le module WIFI pour une communication locale sans fils avec un autre terminal de communication, par exemple le téléphone intelligent 3. La clef HDMI 8 comprend en outre un module de téléchargement progressif adaptatif HAS apte à demander un téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description 7. Ce fichier de description 7 peut être enregistré par exemple dans les mémoires M de la clef HDMI 8 ou se trouver à l’extérieur.

La clef HDMI 8 comprend également un module DET de détermination d’un volume de données qui serait consommé par téléchargement progressif adaptatif d’un contenu, aux différentes qualités proposées dans le fichier de description 7.

Il comprend également un module DISP de commande de l’affichage des volumes de données déterminés par le module DET sur un écran d’un terminal de restitution, par exemple le téléphone intelligent 3 ou le téléviseur 5. Plus généralement, un tel module DISP est un module de gestion de l’interface avec le terminal de restitution de l’utilisateur, par lequel la clef HDMI 8 obtient par exemple des informations sur les éventuelles interactions de l’utilisateur avec le terminal de restitution (action sur la télécommande du téléviseur par exemple par appui sur la touche volume ou une touche de changement de canal, ou sélection dans un menu en surbrillance sur l’écran du téléviseur d’une qualité maximale de contenu autorisée, ou sélection de cette qualité maximale sur l’écran tactile du téléphone intelligent 3 ou de la tablette 4), et par lequel elle peut piloter l’affichage sur l’écran du terminal de restitution de fenêtres pop-up, lui permettant de délivrer des messages, des informations sur les volumes de données consommés ou restants, ou des alertes à l’utilisateur.

Il comprend encore un module SEL de sélection d’un débit d’encodage maximal ou d’une résolution maximale autorisés pour le téléchargement du contenu, qui pilote le module de téléchargement progressif adaptatif HAS, afin de forcer ce dernier à demander un téléchargement progressif du contenu à une qualité, proposée dans le fichier de description 7, inférieure à la qualité optimale à laquelle il pourrait prétendre, dans le cas où cette qualité optimale est supérieure à la qualité maximale sélectionnée via le module SEL.

La clef HDMI 8 selon un mode de réalisation de l’invention peut aussi contenir d’autres modules comme un disque dur (non représenté) pour le stockage des fragments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues d’une tablette ou d’un smartphone sur lesquels est installée l’application de pilotage de la clef HDMI, grâce à laquelle l’utilisateur peut en contrôler le fonctionnement, etc.En effet, une telle clef HDMI 8 ne contient généralement pas de module d’interface E/S, et c’est le module d’interface E/S du téléphone intelligent 3 de l’utilisateur ou de sa tablette 4, ou du téléviseur 5, qui est utilisée par ce dernier pour choisir par exemple son contenu.

On notera que le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

Plus généralement, une telle clef HDMI 8 comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur CPU, et pilotée par un programme d'ordinateur, représentatif du module de gestion du téléchargement progressif adaptatif HAS, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur CPU de l'unité de traitement. La mémoire vive contient notamment le fichier de description manifest 7. Le processeur de l’unité de traitement pilote la détermination des volumes de données consommés par téléchargement du contenu à ses différents niveaux de qualité, l’affichage de fenêtres pop-up sur l’écran du terminal de restitution, et le bridage de la qualité du contenu téléchargé, au travers du choix des segments temporels et des débits d’encodage associés à télécharger, et l’émission de commandes correspondantes vers le module client HAS.

Dans le cas où le terminal lecteur de flux multimédia considéré n’est pas la clef HDMI 8 mais, par exemple, le téléphone intelligent 3, l’architecture proposée sur reste la même, à ceci près que le terminal communique directement avec le réseau de communication étendu via un module de communication mobile, par exemple de type 4G, en lieu et place du module WIFI. Le terminal de restitution est alors le terminal lecteur de flux multimédia lui-même, de sorte que le module DISP de commande de l’affichage pilote l’affichage des volumes de données estimés directement sur l’écran du téléphone intelligent 3, et le module SEL reçoit directement la valeur de la qualité maximale du contenu autorisée sélectionnée par l’utilisateur sur l’écran du téléphone intelligent 3 lui-même.

illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un terminal lecteur de flux multimédia, afin qu’il effectue les étapes du procédé détaillé ci-après, en relation avec [Fig 3] (dans l’un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

On présente désormais, en relation avec , un exemple de bridage de la qualité maximale d’un flux multimédia obtenu en mode téléchargement progressif adaptatif par un terminal lecteur de flux multimédia 30, par exemple la clef HDMI 8 ou le téléphone intelligent 3 de [Fig 1] et [Fig 2].

Le terminal lecteur de flux multimédia 30 est connecté à un terminal de restitution TX (par exemple la clef HDMI 8 est connectée au téléviseur 5 par l’intermédiaire d’une liaison HDMI ou au téléphone intelligent 3 par l’intermédiaire d’une liaison WIFI). Il comprend un module DISP 300 d’interface avec le terminal de restitution TX, un module DET 301 de détermination du volume de données consommé par téléchargement d’un contenu à ses différents débits d’encodage, un module SEL 302 de sélection d’un débit d’encodage maximum autorisé pour le téléchargement, et un module client HAS 303.

Un serveur de contenu HAS 2 expose une vidéo C1 sous forme de « chunks » C1_i@Nj encodés à différents débits d’encodage Nj, où l’indice i désigne un identifiant temporel du « chunk » C1_i@Nj.

Selon l’art antérieur, un module client HAS est chargé de venir récupérer ses « chunks » auprès du serveur de contenu HAS 2 en choisissant la qualité vidéo Nj en fonction de la ressource réseau disponible. On ne décrit pas ici plus en détail la façon dont le module client HAS choisit le débit d’encodage du prochain fragment vidéo à télécharger : il existe en effet de nombreux algorithmes permettant d’opérer ce choix, dont les stratégies sont plus ou moins sécuritaires ou agressives. On rappelle cependant que, le plus souvent, le principe général de tels algorithmes repose sur le téléchargement d’un premier fragment au débit d’encodage le plus faible proposé dans le manifeste, et sur l’évaluation du temps de récupération de ce premier fragment. Sur cette base, le module client HAS évalue si, en fonction de la taille du fragment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le fragment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des fragments de contenu téléchargés ; d’autres proposent des approches plus risquées, avec des sauts dans les niveaux des débits d’encodage des fragments successifs.

Dans le cas classique, si un « chunk » vidéo dure 3 secondes, la récupération du « chunk » par le module client HAS ne doit pas excéder 3 secondes, afin de permettre une restitution sans interruption du contenu par le terminal 30. Il convient donc pour le module client HAS d’opérer le meilleur compromis entre une qualité de restitution, et donc un débit d’encodage, aussi élevés que possible, et le temps de téléchargement du fragment, qui doit être suffisamment faible pour permettre une restitution en continu sur le terminal de restitution TX.

Dans le mode de réalisation illustré sur , en revanche, le module client HAS 303 peut ne pas commander le téléchargement du fragment au débit d’encodage optimal, afin de limiter la consommation du godet de données de l’utilisateur, comme décrit plus en détail par la suite.

Au cours d’une étape référencée 310, le module HAS 303 récupère le fichier manifest 7 afin de découvrir les fragments disponibles du contenu vidéo C1, et les différentes qualités vidéo Nj associées.

On considère par exemple le cas d’un client qui souhaite regarder une vidéo à la demande (VOD) d’une durée de deux heures, en utilisant sa CléTV® 8 et son smartphone 3 en mode modem (partage de connexion 4G).

On suppose que sur la Clef HDMI 8 qu’il veut utiliser, la technologie de transport du flux multimédia est de type HAS avec cinq niveaux de débit d’encodage et de résolution disponibles, selon l’exemple donné dans le tableau[Table 1]ci-dessous.

Résolution	Débit
320x180 pixels	600kb/s
569x320 pixels	1.2Mb/s
1024x576 pixels	2.1Mb/s
1280x720 pixels	3Mb/s
1920x1080 pixels	5Mb/s

Ainsi, dans l’exemple de , le contenu C1 est par exemple proposé sous forme de fragments de durée 3s, avec un premier débit d’encodage N1 = 600 kb/s, un deuxième débit d’encodage N2 = 1200 kb/s, un troisième débit d’encodage N3 = 2100 kb/s, etc.

Dans un mode de fonctionnement normal, non illustré sur , le module HAS 303 opère le téléchargement par exemple, des fragments successifs C11@N1 (soit le premier fragment temporel à un débit d’encodage de 600 kb/s), puis C12@N3 (soit le deuxième fragment temporel à un débit d’encodage de 2100 kb/s), puis C13@N3 (soit le troisième fragment temporel à un débit d’encodage de 2100 kb/s), ...

Les différents fragments téléchargés par le module client HAS 303 sont transmis au module d’interface DISP 300 pour leur restitution à l’utilisateur sur l’écran du terminal de restitution TX.

L’algorithme mis en œuvre par le module client HAS 303 pour déterminer quel fragment à quel débit d’encodage doit être téléchargé en mode de fonctionnement normal (c’est-à-dire en dehors du bridage du débit d’encodage par le module SEL 302) peut être l’un des algorithmes déjà existants de l’art antérieur. Cet algorithme ne sera donc pas décrit ici plus en détail.

En parallèle, conformément à , le module DET 301 détermine le volume de données qui serait consommé par téléchargement du contenu C1 aux différents niveaux de résolution de [Table 1]. Pour ce faire, le module DET 301 utilise par exemple une hypothèse simplificatrice, selon laquelle le téléchargement s’opère au même niveau de résolution pendant toute la durée du contenu, soit, dans cet exemple pendant deux heures, ou 7200 secondes. Bien qu’elle ne corresponde pas à la réalité de fonctionnement du téléchargement de type HAS, cette hypothèse permet une bonne estimation de la quantité de données qui pourrait être consommée par téléchargement du contenu à chacun des niveaux de résolution proposé dans le fichier manifest 7.

Ainsi, par exemple, pour une résolution de 320x180 pixels , le module DET 301 estime une consommation de données de : 600kb/s * 7200s=4,32Gb, soit 540Mo. Le résultat de l’ensemble des calculs effectués est résumé dans le tableau ci-dessous.

Résolution	Débit	Data
320x180 pixels	600kb/s	4.32Gb (540Mo)
569x320 pixels	1.2Mb/s	8.64Gb (1.08Go)
1024x576 pixels	2.1Mb/s	15.12Gb (1.89Go)
1280x720 pixels	3Mb/s	21.6Gb (2.7Go)
1920x1080 pixels	5Mb/s	36Gb (4.5Go)

On considère tout d’abord un premier cas, dans lequel le terminal 30 connaît le godet de données du client utilisateur. Ce godet de données correspond par exemple à un volume de données associé à une carte prépayée dont il a fait l’acquisition auprès de l’opérateur du réseau mobile 1. Il peut aussi correspondre à un forfait mensuel qu’il a souscrit auprès de cet opérateur, par exemple un forfait de 50Go/mois.

Dans le cas où le service de téléchargement HAS est maîtrisé de bout en bout par l’opérateur du réseau mobile 1, le godet de données de l’utilisateur est connu de l’opérateur, à partir de l’offre qu’a souscrit l’utilisateur, ou de ses informations de facturation. C’est donc l’opérateur qui transmet cette information au terminal 30.

En variante, ce godet de données peut également être renseigné par l’utilisateur lui-même. Il peut par exemple être saisi via l’interface du terminal de restitution TX (téléphone intelligent 3, ou téléviseur 5 par exemple), lors d’une phase d’installation du service de téléchargement HAS, ou en réponse à une requête du fournisseur de ce service, par exemple via une fenêtre « pop in » informant l’utilisateur de nouvelles fonctionnalités ou de nouveautés du service.

On considère donc l’exemple d’un godet de données de 50Go/mois, dont le client aurait déjà consommé 10Go au cours du mois courant. A nouveau, la connaissance de la consommation courante du client peut être fournie par l’opérateur du réseau mobile 1, ou par le client lui-même.

Le module DET 301 peut alors aisément déterminer, pour chacune des résolutions proposées dans le ficher manifest 7, la part du godet de données qui sera consommée en cas de téléchargement du contenu à cette résolution, et la part de ce godet qui restera au client après téléchargement, en fonction de sa consommation mensuelle courante. Le résultat des calculs effectués par le module DET 301 peut s’afficher, par exemple sous forme du tableau[Table 3]ci-dessous, sur l’écran du terminal de restitution TX.

Résolution	Débit	Data	% Godet	% Godet restant après conso à
320x180 pixels	600kb/s	4,32Gb (540Mo)	1,08%	78,92%
569x320 pixels	1,2Mb/s	8,64Gb (1,08Go)	2,16%	77,84%
1024x576 pixels	2,1Mb/s	15,12Gb (1,89Go)	3,78%	76,22%
1280x720 pixels	3Mb/s	21,6Gb (2,7Go)	5,4%	74,6%
1920x1080 pixels	5Mb/s	36Gb (4,5Go)	9%	71%

Ainsi, par simple consultation de l’écran du terminal de restitution TX, le client sait qu’en téléchargeant le contenu C1 à un débit d’encodage de 2,1Mb/s, il consommera 7200*2,1=15,12Gb, soit 15,12/8=1,89Go. Dans la mesure où son godet de données est de 50Go, cela représente donc 1,89Go*50Go/100=3,78% de son godet de données mensuel. Et comme il a déjà consommé 10Go de données depuis le début du mois, soit 20% de son godet de données, il lui restera, après téléchargement du contenu C1 à cette résolution de 1024x576 pixels, 100%-20%-3,78%=76,22% de son godet de données mensuel.

Le terminal 30 propose alors au client, fort de cette connaissance de son niveau de godet de données consommé et restant après téléchargement, de définir une limite haut du débit d’encodage du contenu à télécharger : les différents fragments du contenu C1 ne pourront alors pas être téléchargés à un débit d’encodage supérieur à cette limite haute sélectionnée par l’utilisateur.

Dans cet exemple, l’utilisateur décide par exemple qu’il souhaite visionner le contenu C1, mais sans dépasser 7% de consommation de son godet de données : il choisit donc de brider le téléchargement des fragments du contenu à une résolution maximale de 1280x720 pixels.

Pour ce faire, il utilise l’interface du terminal de restitution TX. Par exemple, sur l’écran du téléviseur 5, il sélectionne, au moyen d’une télécommande, l’une des lignes du tableau [Table 3], qui s’affiche par exemple en surbrillance. Dans un autre exemple, il sélectionne ce débit d’encodage maximum autorisé en cliquant sur la ligne idoine du tableau [Table3] affichée sur l’écran tactile du téléphone intelligent 3. Tout autre type de configuration d’interface pourrait également être utilisé, telle qu’un bandeau (en anglais « banner »), une fenêtre « pop in », etc.

On notera que le terminal lecteur de flux multimédia 30 peut opérer lui-même cette sélection, sans intervention de l’utilisateur, par exemple en appliquant un principe de précaution quant à la consommation du godet de données. Il peut aussi inciter l’utilisateur à sélectionner une valeur basse de débit d’encodage maximum autorisé, par exemple en affichant en surbrillance sur l’écran du terminal de restitution une valeur maximale de débit d’encodage préconisée, en fonction de la part du godet de données restante après téléchargement. L’utilisateur n’a alors plus qu’à confirmer ou infirmer cette pré-sélection.

La valeur sélectionnée alimente le module de sélection SEL 302, qui la communique au module HAS 303, de façon à brider le téléchargement des fragments de contenu au débit d’encodage maximum de 3Mb/s choisi par l’utilisateur.

Ainsi, comme illustré sur , le module client HAS 303 va télécharger successivement (312) les fragments C12@N3, C13@N3, C14@N2, C15@N1 et C16@N3, c’est-à-dire, télécharger le fragment de meilleure qualité possible en fonction des contraintes réseau, mais sans jamais dépasser la valeur maximale MAX 311 du débit d’encodage, qui a été sélectionnée par l’utilisateur comme étant égale à 2100kb/s.

Ainsi, si après avoir téléchargé les fragments C1₂@N3, C1₃@N3, C1₄@N2 et C1₅@N1, le module client HAS 303 détermine, en fonction des conditions réseau, que le débit optimal de fragment temporel auquel il peut prétendre est de 5000kb/s, il ne lance pas le téléchargement du prochain fragment à ce débit optimal, mais télécharge le fragment temporel C1₆@N3, au débit d’encodage maximum autorisé par le client.

On considère désormais un second cas, dans lequel le terminal lecteur de flux multimédia 30 n’a pas connaissance du godet de données de l’utilisateur. Dans ce cas, le module de détermination DET 301 du volume de données consommées ne peut déterminer que la valeur absolue du volume de données consommé par téléchargement du contenu C1 aux différents niveaux de résolution proposés dans le fichier manifest 7, et non sa valeur relative par rapport au godet de données. En d’autres termes, seules les données du tableau [Table 2] peuvent être affichées, sur action du module de commande d’affichage DISP 300, sur l’écran du terminal de restitution TX. Ainsi, on présente simplement le niveau de consommation du flux multimédia C1 à ses différents débits d’encodage, et l’utilisateur doit opérer une sélection du débit d’encodage maximum qu’il autorise en fonction seulement du nombre de Go consommés à chacun des débits.

L’utilisateur ayant le plus souvent connaissance de son godet de données, il peut effectuer un calcul rapide de tête pour l’aider à prendre une décision. Ainsi, s’il a envie de visionner la VOD C1, il peut être prêt à consommer 2,7Go de son godet de données mensuel, quitte à restreindre sa consommation pendant le reste du mois sur d’autres services ou applications. Dans ce cas, il sélectionne, dans le tableau [Table2], la résolution de 1280x720 pixels, et le débit d’encodage maximum associé de 3Mb/s. A nouveau, la configuration de l’interface du terminal de restitution TX rendant possible cette sélection peut prendre toute forme appropriée.

Dans ce second cas, on affiche donc sur l’écran du terminal de restitution des données permettant à l’utilisateur de mieux appréhender l’impact du téléchargement du contenu C1 sur sa consommation de données, afin qu’il dispose des outils nécessaires pour adapter sa consommation de contenu, en fonction de ses capacités.

On notera que, dans un mode de réalisation, la sélection du débit d’encodage maximum MAX 311 est effective pour le seul contenu C1 en cours de téléchargement HAS. En variante, cette sélection peut s’appliquer à tous les flux multimédias accessibles via le serveur de contenus 2, ou à tous les flux multimédias que l’utilisateur va télécharger au cours d’une période donnée (par exemple le mois courant en cas de forfait mensuel), ou pendant une période donnée au cours de laquelle l’utilisateur est en situation de mobilité.

Dans un autre mode de réalisation, le module DISP 300 n’affiche pas toutes les lignes des tableaux [Table 2] et [Table 3] sur l’écran du terminal de restitution TX, mais seulement les lignes correspondant aux débits d’encodage qui n’entraînent pas de dépassement du godet de données de l’utilisateur. En d’autres termes, on propose uniquement au client les débits d’encodage auxquels il peut prétendre pour pouvoir au minimum visionner le contenu C1 en intégralité, s’il ne lui reste plus assez de données consommables pour le voir à la qualité maximale disponible.

On a donné ci-avant l’exemple d’un contenu C1 de type vidéo à la demande (VOD). On notera que le contenu C1 peut également être un programme télévisuel en différé (ou « replay »), ou un programme télévisuel en direct (« Live »). Dans ce dernier cas, la durée du programme nécessaire au calcul par le module DET 301 du volume de données consommé peut être extraite du guide électronique des programmes EPG (« Electronic Program Guide »).

Dans ses différents modes de réalisation, la présente invention peut être mise en œuvre sur les boîtiers décodeurs (en anglais « set top box »), sur la CléTV® d’Orange® et généralement sur tous les terminaux consommant des vidéos en HAS en mobilité (sur réseau mobile).

ANNEXE 1 : exemple de fichier manifest

Claims (11)

1. Procédé de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique (C1) au sein d’un terminal (3, 4, 8) lecteur de flux multimédia connecté à un réseau de communication mobile (1),
   ledit contenu numérique étant associé à un fichier (7) de description dudit contenu numérique, comprenant une liste de segments temporels (C1_i@Nj) dudit contenu associés chacun à plusieurs débits d’encodage dudit contenu,
   un volume maximum de données à consommer au sein dudit réseau de communication mobile, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia,
   caractérisé en ce que, au lancement dudit téléchargement progressif adaptatif dudit contenu numérique, ledit procédé de gestion met en œuvre :
   - une détermination (DET 301) d’un volume de données qui serait consommé par ledit terminal lecteur de flux multimédia par téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d’encodage,
   - une sélection (SEL 302) d’un débit d’encodage maximum (MAX 311) dudit contenu autorisé pour ledit téléchargement, en fonction dudit volume de données consommé qui lui est associé, et dudit godet de données.
2. Procédé de gestion selon la revendication 1,caractérisé en ce qu’il comprend également un affichage (DISP 300), sur un terminal de restitution (TX) associé audit terminal lecteur de flux multimédia, desdits volumes de données consommés déterminés pour au moins certains desdits débits d’encodage.
3. Procédé de gestion selon la revendication 2,caractérisé en ce quelesdits volumes de données consommés, déterminés pour au moins certains desdits débits d’encodage, sont affichés sous forme d’une proportion dudit godet de données.
4. Procédé de gestion selon l'une quelconque des revendications 2 et 3,caractérisé en ce qu’il comprend également un affichage, sur ledit terminal de restitution, d’un volume de données restant à consommer par ledit terminal lecteur de flux multimédia, à l’issue dudit téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d’encodage.
5. Procédé de gestion selon l'une quelconque des revendications 2 à 4, caractérisé en ce que lesdits volumes de données affichés correspondent aux seuls débits d’encodage pour lesquels ledit téléchargement desdits segments temporels dudit contenu n’induit pas de dépassement dudit godet de données.
6. Procédé de gestion selon l'une quelconque des revendications 1 à 5,caractérisé en ce qu’il comprend également une saisie, sur un terminal de restitution associé audit terminal lecteur de flux multimédia, dudit godet de données.
7. Procédé de gestion selon l'une quelconque des revendications 1 à 6,caractérisé en ce queladite sélection dudit débit d’encodage maximum dudit contenu autorisé pour ledit téléchargement est effectuée par un utilisateur via une interface d’un terminal de restitution associé audit terminal lecteur de flux multimédia.
8. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 7, lorsqu’il est exécuté par un processeur.
9. Dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique au sein d’un terminal lecteur de flux multimédia connecté à un réseau de communication mobile,
   ledit contenu numérique étant associé à un fichier de description (7) dudit contenu numérique, comprenant une liste de segments temporels dudit contenu associés chacun à plusieurs débits d’encodage dudit contenu,
   un volume maximum de données à consommer au sein dudit réseau de communication mobile, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia,
   caractérisé en ce qu’il comprend:
   - un module de détermination (DET) d’un volume de données qui serait consommé par ledit terminal lecteur de flux multimédia par téléchargement desdits segments temporels dudit contenu à au moins certains desdits débits d’encodage,
   - un module de sélection (SEL) d’un débit d’encodage maximum dudit contenu autorisé pour ledit téléchargement, en fonction dudit volume de données consommé qui lui est associé, et dudit godet de données.
10. Dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique selon la revendication 9,caractérisé en ce qu’il comprend également un module (DISP) de transmission d’une commande, vers un terminal de restitution (3, 4, 5) associé audit terminal lecteur de flux multimédia (3, 4, 8), d’affichage desdits volumes de données consommés déterminés pour au moins certains desdits débits d’encodage.
11. Terminal lecteur de flux multimédia (3, 4, 8),caractérisé en ce qu’il comprend un dispositif de gestion du téléchargement progressif adaptatif (HAS) d’un contenu numérique selon la revendication 9 ou 10.