FR3103668A1

FR3103668A1 - Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session en fonction d’un godet de données

Info

Publication number: FR3103668A1
Application number: FR1912990A
Authority: FR
Inventors: Mathieu Rivoalen; Hervé MARCHAND
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2019-11-21
Filing date: 2019-11-21
Publication date: 2021-05-28

Abstract

Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session en fonction d’un godet de données L'invention concerne un procédé de gestion du téléchargement progressif adaptatif (HAS) de contenus numériques au sein d’un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Un 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 au cours d’une session, appelé godet de données, est alloué au terminal lecteur de flux multimédia. Selon l’invention, un tel procédé comprend : une estimation (406), en fonction d’un volume de données consommé par téléchargement progressif adaptatif de contenus numériques au cours d’au moins une période par le terminal lecteur de flux multimédia, d’un volume de données qui pourrait être consommé par le terminal par téléchargement progressif adaptatif des contenus numériques au cours de la session ; une détermination (407) d’un débit d’encodage maximum autorisé pour le téléchargement de segments temporels des contenus numériques au cours de la session afin que le volume de données estimé soit inférieur ou égal à un seuil de consommation déterminé du godet de données. Figure pour l’abrégé : Fig 4

Description

Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session 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 Transfer 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, et à la variation des conditions de distribution du contenu par le serveur, 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 au cours d’une session. 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 au cours d’une session 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. De même, une carte prépayée achetée à l’opérateur du réseau de communication mobile est associée à un volume de données maximum consommable par l’utilisateur.

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 ressources 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.

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 (ou plus généralement en début de session), le privant de ressources pour la fin de la période (i.e. de la session). Elle peut également conduire l’utilisateur à consommer une trop grosse part de son godet data pour le téléchargement de contenus HAS (par exemple, des programmes TV en HD), au détriment d’autres applications consommatrices de données (par exemple, la messagerie électronique, la messagerie instantanée, le système de géolocalisation…)

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 limiter la part de son godet de données consacrée au téléchargement progressif adaptatif de contenus au cours d’une session, tout en lui garantissant l’accès à ces contenus tout au long de cette session.

Il existe encore un besoin d’une telle technique qui permette une adaptation constante et automatique du profil de consommation de flux HAS d’un utilisateur, en fonction de ses habitudes et besoins.

L'invention répond à ce besoin en proposant un procédé de gestion du téléchargement progressif adaptatif (HAS) de contenus numériques au sein d’un terminal lecteur de flux multimédia connecté à un réseau de communication mobile. Un 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 au cours d’une session, appelé godet de données, est alloué au terminal lecteur de flux multimédia.

Selon l’invention, un tel procédé comprend:

une estimation, en fonction d’un volume de données consommé par téléchargement progressif adaptatif de contenus numériques au cours d’au moins une période par le terminal lecteur de flux multimédia, d’un volume de données qui pourrait être consommé par ce terminal par téléchargement progressif adaptatif de contenus numériques au cours de la session;
une détermination d’un débit d’encodage maximum autorisé pour le téléchargement de segments temporels des contenus numériques au cours de la session afin que le volume de données estimé soit inférieur ou égal à un seuil de consommation déterminé 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 cours d’une session au sein de son réseau mobile 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. La session correspond alors à la périodicité du forfait (par exemple, un mois pour un forfait mensuel), ou à la durée de validité de la carte prépayée.

Le procédé selon un mode de réalisation de l'invention propose de déterminer un débit d’encodage maximum des segments temporels des contenus autorisé au cours de la session, afin d’éviter une surconsommation du godet data sur cette session. 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, ce débit d’encodage est bridé, pour une meilleure maîtrise de la consommation du godet data.

Le débit d’encodage maximum autorisé sur la session est déterminé par observation de la consommation de l’utilisateur sur une ou plusieurs période(s), et estimation, à partir de cette observation, de ce que pourrait être sa consommation sur la session.

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, une valeur initiale du seuil de consommation déterminé du godet de données est choisie par un utilisateur, par exemple sous forme d’une proportion du godet de données.

Ainsi, lorsque l’utilisateur accède par exemple pour la première fois au service de téléchargement de contenus en HAS, il peut être invité à indiquer s’il souhaite ou non bénéficier d’un contrôle de consommation selon un mode de réalisation de l’invention. Dans l’affirmative, l’utilisateur peut être invité à indiquer s’il souhaite limiter sa consommation de contenus HAS à 50%, 70%, ou toute autre proportion de son godet data. L’utilisateur bénéficie ainsi de la maîtrise des conditions de sa consommation de contenus HAS.

Ce choix peut s’opérer 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. Il peut être valable uniquement pour une session donnée, ou être défini comme paramètre d’initialisation du service de téléchargement adaptatif HAS, pour l’ensemble des sessions.

Si le seuil de consommation est défini sous forme d’une proportion du godet data, il est bien sûr nécessaire que ce godet data soit également connu du terminal lecteur de flux multimédia.

Selon un mode de réalisation, ce godet de données est saisi par l’utilisateur sur un terminal de restitution associé au terminal lecteur de flux multimédia. 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).

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 premier aspect, la période est incluse dans la session, et l’estimation s’opère par extrapolation, sur la session, du volume de données consommé sur la période.

Par exemple, pour une session correspondant à un forfait mensuel, la période d’observation peut correspondre à la première semaine du mois. En fonction du volume de données consommé au cours de cette première semaine, il est possible par extrapolation d’estimer ce que sera le volume de données consommé sur le mois, et de le comparer au seuil de consommation fixé par l’utilisateur. En cas de dépassement du seuil fixé, le procédé selon un mode de réalisation de l’invention propose de brider le débit d’encodage maximum autorisé pour le téléchargement adaptatif des segments temporels de contenus sur la fin du mois, afin d’éviter ou limiter ce dépassement.

Selon un autre aspect, la période est de même durée que la session et l’estimation tient compte d’au moins un paramètre calendaire de la session par rapport à la période.

Ainsi, on estime par exemple le volume de données qui pourrait être consommé au cours d’un mois N, en fonction du volume de données qui a été consommé au cours du mois N-1, ou au cours du mois N de l’année précédente. On peut également tenir compte de la saison, ou d’une période de vacances, ou de jours fériés.

Dans un mode de réalisation, l’estimation peut tenir compte conjointement du volume de données consommé sur une première partie de la session (par exemple au cours de la première semaine d’un forfait mensuel), et du volume de données consommé au cours d’une session antérieure (par exemple au cours du même mois de l’année passée). L’estimation peut alors effectuer un calcul de moyenne pondérée, à partir de ces multiples observations.

Selon encore un autre aspect, l’estimation et la détermination du débit d’encodage maximum sont actualisées au moins deux fois au cours de la session.

Par exemple, dans le cadre d’un forfait mensuel, le contrôle de non dépassement de seuil et l’adaptation (si nécessaire) du débit maximum autorisé sont effectués de façon hebdomadaire, jusqu’à la fin du mois. Ainsi, on optimise conjointement la qualité d’expérience de l’utilisateur et la maîtrise de sa consommation. En effet, une consommation importante au cours de la première semaine peut conduire à une forte limitation du débit d’encodage maximum autorisé, et donc à une forte réduction de la qualité de restitution des contenus; cependant, si l’utilisateur consomme peu de contenus au cours des deux semaines suivantes, il est alors possible, pour la dernière semaine du mois, d’autoriser un débit d’encodage maximum plus élevé, et ainsi d’améliorer l’expérience de l’utilisateur en lui offrant des contenus de meilleure qualité.

Selon un mode de réalisation, à l’initialisation de la session, on affecte au débit d’encodage maximum autorisé une valeur d’un débit d’encodage maximum autorisé déterminé au cours d’une session précédente. En d’autres termes, en fin de session, on ré-initialise la prochaine session avec le même seuil et le profil de consommation de fin de session précédente.

On privilégie ainsi la qualité d’expérience de l’utilisateur, en évitant de trop fortes fluctuations de la qualité des contenus au moment du changement de session.

Selon un autre aspect, si, à l’issue de l’estimation, le volume estimé est sensiblement supérieur au seuil de consommation déterminé du godet de données, un tel procédé comprend une émission d’un message d’alerte vers un utilisateur du terminal lecteur de flux multimédia, et par exemple d’une invitation à modifier le seuil de consommation.

Ainsi, en cas de prévision d’un dépassement fort du seuil fixé par l’utilisateur, on en informe le client, par exemple par affichage d’un message sur un terminal de restitution associé au terminal lecteur de flux multimédia. Ce message peut l’informer de la possible nécessité de réviser la valeur du seuil qu’il a fixé, pour éviter par exemple une trop forte dégradation de la qualité de restitution des contenus, ou simplement l’inviter à réduire sa consommation de contenus sur la fin de la session.

Selon un mode de réalisation, un tel procédé de gestion du téléchargement progressif adaptatif de contenus numériques comprend également une analyse des volumes de données estimés et consommés sur une pluralité de sessions, et une adaptation du seuil de consommation déterminé du godet de données en fonction de cette analyse.

Ainsi, il est possible de procéder à une adaptation automatique du seuil de consommation initialement fixé par l’utilisateur, au fil du temps, en tenant compte par exemple de la saisonnalité de sa consommation.

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 contenu numérique est associé à un fichier de description du contenu numérique, 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 au cours d’une session, appelé godet de données, est alloué au terminal lecteur de flux multimédia.

Un tel dispositif comprend:

un module d’estimation, en fonction d’un volume de données consommé par téléchargement progressif adaptatif de contenus numériques au cours d’une période par le terminal lecteur de flux multimédia, d’un volume de données qui pourrait être consommé par le terminal lecteur de flux multimédia par téléchargement progressif adaptatif des contenus numériques au cours de la session;
un module de détermination d’un débit d’encodage maximum autorisé pour le téléchargement de segments temporels des contenus numériques au cours de la session afin que le volume de données estimé soit inférieur ou égal à un seuil de consommation déterminé du godet de données.

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];

présente sous forme d’organigramme les différentes étapes du procédé de gestion de téléchargement progressif adaptatif selon un mode de réalisation de l’invention.

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

Le principe général de l'invention repose sur l’adaptation automatique du profil de consommation de flux HAS d’un utilisateur au cours d’une session, à partir d’une observation des usages de consommation de l’utilisateur sur une ou plusieurs périodes.

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 par 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 ESTIM d’estimation du volume de données qui pourrait être consommé par la clef HDMI 8, au cours de la session, en fonction d’une observation du volume de données qui a été effectivement consommé par la clef HDMI 8, par téléchargement HAS de contenus requis par l’utilisateur au cours d’une ou plusieurs périodes temporelles.

Un tel module ESTIM collecte des informations relatives à la consommation de flux HAS de l’utilisateur au cours d’une période d’observation, telles que la durée des contenus qu’il a visionnés, leur qualité de restitution et le débit d’encodage correspondant des segments temporels de contenu téléchargés. Un tel module ESTIM calcule, à partir des informations collectées, une estimation du volume de données consommable en HAS par l’utilisateur au cours de la session.

La clef HDMI 8 comprend également un module DISP de gestion de l’interface avec un terminal de restitution, par exemple le téléphone intelligent 3 ou le téléviseur 5. Par l’intermédiaire d’un tel module DISP, 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’un seuil de consommation maximum autorisé au cours de la session, ou sélection de ce seuil de consommation 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.

Elle comprend encore un module DET de détermination d’un débit d’encodage maximum autorisé pour le téléchargement progressif adaptatif des segments d’un contenu au cours d’une session, 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 autorisée déterminée par le module DET.

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 de contenus au cours de différentes périodes, 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 cours de la session, 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 différents messages d’alerte directement sur l’écran du téléphone intelligent 3, et le module DET reçoit directement la valeur du seuil de consommation du godet de données choisi 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 et [Fig 4], un exemple de bridage de la qualité maximale des flux multimédia obtenus au cours d’une session 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]. On rappelle que par session, on entend la période associée à un forfait souscrit auprès d’un opérateur du réseau de communication mobile 1 (par exemple un mois pour un forfait mensuel), ou la durée de validité d’une carte prépayée achetée à cet opérateur.

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 notamment un module DISP 300 d’interface avec le terminal de restitution TX, un module ESTIM 301 de détermination du volume de données consommé par téléchargement HAS de contenus au cours d’une période donnée, un module DET 302 de détermination d’un débit d’encodage maximum autorisé pour le téléchargement de contenus au cours d’une session, et un module client HAS 303.

On considère par exemple le cas d’un client qui souhaite regarder des programmes télévisuels, en utilisant sa CléTV® 8 et son smartphone 3 en mode modem (partage de connexion 4G), sur son forfait mobile, souscrit auprès de l’opérateur de son réseau de communication. On considère dans cet exemple que le client a souscrit un forfait mensuel, auquel est associé un godet data mensuel de 50Go/mois.

On suppose que le terminal lecteur de flux multimédia 30 a connaissance de ce godet data de 50 Go/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.

Lorsque le client accède pour la première fois au service de téléchargement HAS (étape INIT 400), ou lors de l’installation initiale de ce service sur son terminal, le module DISP 300 gère l’affichage sur l’écran du terminal de restitution TX (ici, le smartphone 3) d’une fenêtre de dialogue, dans laquelle on demande au client s’il souhaite activer le contrôle de consommation de son godet data (étape CTRL_C° 401). La réponse du client peut s’opérer par sélection d’un menu en surbrillance sur l’écran du téléphone intelligent 3.

Si le client répond par l’affirmative, le module DISP 300 gère l’affichage d’une nouvelle fenêtre de dialogue sur l’écran du terminal, dans laquelle le client est invité à saisir le seuil de consommation qui lui convient (étape SEL_THR 402). Ce seuil peut s’exprimer sous forme d’une proportion de son godet de données, ou d’un volume maximum de données à ne pas dépasser, exprimé par exemple en Go.

Par exemple, le module DISP 300 pilote l’affichage d’une fenêtre dans laquelle sont proposées différentes limites de consommation, telles que 30% du godet data, 50% ou 70% du godet data. Le client sélectionne le seuil qui lui convient par déplacement d’un curseur correspondant à un affichage en surbrillance de l’un des seuils proposés.

Ce seuil peut être choisi une fois pour toutes à l’initialisation du service HAS, ou être actualisé à chaque début de session. Par exemple, dans le cas d’un forfait mensuel, à chaque début de mois, le client peut choisir le seuil qu’il souhaite appliquer pour le mois à venir.

On suppose dans cet exemple que le client sélectionne, par saisie tactile sur l’écran de son téléphone intelligent 3, un seuil de consommation de 50% de son godet data, ce qui signifie qu’il ne souhaite pas consommer plus de la moitié de son godet data pour le téléchargement de programmes télévisuels en HAS au cours du mois. Il souhaite en effet conserver des ressources de données pour d’autres applications, telles que des applications de géolocalisation, la gestion de sa messagerie électronique ou instantanée, ou l’accès à des sites internet.

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

Après initialisation du service de téléchargement HAS, le client commence à utiliser la Clé TV 8, par exemple pour regarder un programme télévisuel en direct sur une chaîne en haute définition (étape START_HAS(D<Dmax) 404). Lors de l’initialisation, le débit d’encodage maximum autorisé fixé par le module DET 302 est initialisé au débit d’encodage maximum disponible en HAS (voir Table 1), soit dans cet exemple 5Mb/s (étape Dmax:=Dmax(HAS) 403).

Le module ESTIM 301 du terminal lecteur de flux multimédia 30 commence à mesurer la durée de consommation de contenus téléchargés en HAS, et le débit moyen de flux consommé (étape MES_C° 405).

Par exemple, le module ESTIM 301 collecte les informations suivantes:

le client a regardé un contenu d’une durée de 30 minutes par téléchargement HAS à un débit de 5Mb/s le lundi;
le client a regardé un contenu d’une durée de 2 heures par téléchargement HAS à un débit de 5Mb/s le mardi;
le client a regardé un contenu d’une durée d’1 heure par téléchargement HAS à un débit de 5Mb/s le mercredi;
Etc.

Au bout d’une semaine d’observation par exemple (soit dans cet exemple environ un quart de la durée de la session associée au godet data), le module ESTIM 301 peut donc calculer une consommation moyenne de données sur la période. On suppose dans cet exemple que cette consommation moyenne s’élève à une heure par jour au débit maximum d’encodage de 5Mb/s, soit 5Mb/s*3600s/j=18Gb/j, soit 2,25Go/j, soit encore 2,25Go/j*7j/semaine=15,75Go/semaine.

En procédant à une extrapolation sur l’ensemble de la durée de la session, soit un mois, le module ESTIM 301 peut estimer que le client va consommer 15,75Go/semaine*4 semaines/mois=63Go au cours du mois (étape ESTIM_C° 406).

On rappelle que le godet data du client est de 50 Go/mois, et qu’il ne souhaite pas consacrer plus de 50% de son godet data au téléchargement de contenus en HAS, soit pas plus de 25Go.

Au bout d’une semaine seulement, et s’il continue, pour le reste du mois, à consommer du contenu en HAS selon le même rythme de consommation, le module ESTIM 3011 peut donc prédire une forte surconsommation du godet data mensuel du client.

Il convient donc de limiter la consommation de flux HAS du client au cours des prochaines semaines, pour respecter son souhait de contrôle de consommation.

Pour ce faire, le module DET 302 va fixer un débit d’encodage maximum autorisé auquel les prochains contenus HAS pourront être téléchargés jusqu’à la fin du mois (étape DET_Dmax 407). Le module ESTIM 301 fournit au module DET 302 les données collectées relatives à la consommation du client au cours de la première semaine d’observation, soit 15,75Go.

Au vu du seuil de consommation fixé par le client à 25Go, le module DET 302 détermine que le client peut encore consacrer 25Go-15,75Go=9,25Go=74Gb de données pour le téléchargement de contenus HAS au cours du mois, i.e. au cours des trois prochaines semaines environ.

Au cours de ces trois prochaines semaines, la consommation quotidienne de contenus en HAS doit donc être bridée à 74Gb/(3 semaines*7 jours)=3,52Gb/jour.

En faisant l’hypothèse que la durée de consommation quotidienne de flux HAS va rester constante à environ une heure par jour, le module DET 302 en déduit que le débit disponible pour une heure de consommation est de 3,52Gb/3600=977kb/s. Au vu des différents niveaux de débit disponibles pour la Clé TV 8 (voir Table 1), il est nécessaire de brider la résolution maximale à laquelle le client peut prétendre à 320x180 pixels.

Ainsi, jusqu’à la fin de la session courante, d’une durée d’un mois, soit au cours des trois prochaines semaines environ, le module DET 302 va brider le débit d’encodage maximum autorisé pour le téléchargement de contenus par le module HAS 303 pour qu’il corresponde à cette très faible résolution de 320x180 pixels.

Le débit d’encodage maximum autorisé Dmax est fourni au module de téléchargement HAS, qui le respecte pour le téléchargement de tous les contenus requis par le client au cours de la durée de la session.

La mesure de consommation MES_C° 405 continue au cours de la deuxième semaine du mois. A la fin de cette deuxième semaine, le module ESTIM 301 procède à une nouvelle estimation de la consommation de flux HAS sur le mois (étape ESTIM_C° 406), par extrapolation de la mesure effectuée sur les deux premières semaines. Sur la base de cette nouvelle estimation, le module DET 302 peut déterminer un nouveau débit d’encodage maximum autorisé Dmax au cours d’une étape DET_Dmax 407.

Ainsi, si le client a réduit sa durée de consommation de contenus HAS au cours de la deuxième semaine par rapport à la première semaine, le débit Dmax peut être revu à la hausse, de sorte que les prochains contenus pourront être téléchargés avec une meilleure résolution sur la fin de la période.

A l’inverse, si le client a augmenté sa consommation de flux HAS, il est possible que le module DET 302 doive imposer au module de téléchargement HAS un débit d’encodage maximum plus faible pour éviter une surconsommation du godet data, et/ou une famine en fin de mois.

La même estimation, et la même actualisation du débit d’encodage maximum autorisé peuvent à nouveau être effectués en fin de troisième semaine.

Plus généralement, toute fréquence de mesure et d’actualisation du débit d’encodage maximum autorisé peuvent être envisagés, en fonction de la durée de la session, et de la finesse de suivi souhaités.

A l’initialisation de la session suivante (i.e. au début du mois suivant), le service de téléchargement de contenus HAS est initialisé avec, d’une part, le seuil de consommation choisi par l’utilisateur lors de l’étape SEL_THR 402 (i.e. dans cet exemple 50% du godet data de 50Go), mais également le débit d’encodage maximum autorisé Dmax calculé au cours de la session précédente (étape DET_Dmax 407). On suppose par exemple qu’au cours de cette session, la consommation de l’utilisateur s’est finalement élevée à trois quarts d’heure de contenus HAS par jour, soit:

Data consommable pour 4 semaines: 50%*50Go=25Go=200Gb

Data consommable par jour: 200Gb/(4 semaines * 7 jours)=7,14Gb/jour

Débit disponible pour 0h45 de consommation quotidienne: 7,14/(45*60s)=2,64Mb/s

Au vu des niveaux de débit disponibles dans [Table1], la résolution maximale autorisée au cours du mois qui débute est établie à 1024x576 pixels.

Le débit d’encodage maximum autorisé Dmax est donc initialisé pour la nouvelle session mensuelle à 2,1Mb/s. Cependant, une nouvelle estimation et actualisation peut être effectuée en fin de première semaine, et ainsi de suite à la fin de chaque semaine, jusqu’à la fin du mois.

En se référant à l’exemple de , on considère qu’au cours du mois, le client souhaite accéder à un contenu C1, par exemple un programme télévisuel exposé par un serveur de contenu HAS 2 sous forme de «chunks» C1i@Nj encodés à différents débits d’encodage Nj, où l’indice i désigne un identifiant temporel du «chunk» C1i@Nj. Dans cet exemple, 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@N4 (soit le troisième fragment temporel à un débit d’encodage de 3000 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 maximum autorisé par le module DET 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 effet, on rappelle que 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. Il existe de nombreux algorithmes permettant au module HAS de choisir le débit d’encodage du prochain fragment vidéo à télécharger, 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 ci-avant en relation avec [Fig 4].

En effet, selon ce mode de réalisation de l’invention, le module DET 302 définit une limite haute 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 déterminée par le module DET 302, au vu de l’observation de la quantité de données consommée par le client au cours de la période précédente, et du seuil de consommation fixé par l’utilisateur par rapport à son godet data.

Dans cet exemple, la résolution maximale autorisée au cours du mois est établie à 1024x576 pixels et le débit d’encodage maximum autorisé Dmax est initialisé pour la session mensuelle à 2,1Mb/s.

Cette valeur Dmax est fournie par le module DET 302 au module HAS 303, de façon à brider le téléchargement des fragments de contenu au débit d’encodage maximum de 2,1Mb/s.

Ainsi, comme illustré sur , 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.

Ensuite, le module client HAS 303 va télécharger successivement (312) les fragments C1₂@N3, C1₃@N3, C1₄@N2, C1₅@N1 et C1₆@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 Dmax 311 du débit d’encodage, qui a été calculée par le module DET 302 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 module DET 302.

Selon un mode de réalisation de l’invention, le module DET 302 peut également tenir compte de la saisonnalité de la consommation de l’utilisateur pour établir le débit d’encodage maximum autorisé sur une période, et pondérer l’estimation fournie par le module ESTIM 301 en fonction de paramètres calendaires tels que la présence de vacances ou de jours fériés pendant la session.

Par exemple, pour déterminer le débit d’encodage maximum autorisé au cours du mois M de l’année N, le module DET 302 peut tenir compte, non seulement de l’estimation fournie par le module ESTIM 301 pour le mois M-1 de l’année N, mais également de l’estimation fournie par le module ESTIM 301 pour le mois M de l’année N-1.

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

Procédé de gestion du téléchargement progressif adaptatif (HAS) de contenus numériques (C1) au sein d’un terminal (3, 4, 8) lecteur de flux multimédia connecté à un réseau de communication mobile (1),
un 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 au cours d’une session, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia,
caractérisé en ce qu’il comprend:
- une estimation(406), en fonction d’un volume de données consommé par téléchargement progressif adaptatif de contenus numériques au cours d’au moins une période par ledit terminal lecteur de flux multimédia, d’un volume de données qui pourrait être consommé par ledit terminal lecteur de flux multimédia par téléchargement progressif adaptatif desdits contenus numériques au cours de ladite session;
- une détermination (407) d’un débit d’encodage maximum autorisé (Dmax) pour le téléchargement de segments temporels desdits contenus numériques au cours de ladite session afin que ledit volume de données estimé soit inférieur ou égal à un seuil de consommation déterminé dudit godet de données.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon la revendication 1,caractérisé en ce qu’une valeur initiale dudit seuil de consommation déterminé dudit godet de données est choisie (402) par un utilisateur.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 et 2,caractérisé en ce queladite période est incluse dans ladite session,et en ce queladite estimation (406) s’opère par extrapolation, sur ladite session, dudit volume de données consommé sur ladite période.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 à 3,caractérisé en ce queladite période est de même durée que ladite sessionet en ce queladite estimation (406) tient compte d’au moins un paramètre calendaire de ladite session par rapport à ladite période.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 à 4,caractérisé en ce queladite estimation et ladite détermination dudit débit d’encodage maximum sont actualisées au moins deux fois au cours de ladite session.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 à 5,caractérisé en ce que, à l’initialisation de ladite session, on affecte audit débit d’encodage maximum autorisé une valeur d’un débit d’encodage maximum autorisé déterminé au cours d’une session précédente.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 à 6,caractérisé en ce que, si, à l’issue de ladite estimation, ledit volume estimé est sensiblement supérieur audit seuil de consommation déterminé dudit godet de données, ledit procédé comprend une émission d’un message d’alerte vers un utilisateur dudit terminal lecteur de flux multimédia et d’une invitation à modifier ledit seuil de consommation.
Procédé de gestion du téléchargement progressif adaptatif de contenus numériques selon l'une quelconque des revendications 1 à 7,caractérisé en ce qu’il comprend également une analyse desdits volumes de données estimés et consommés sur une pluralité de sessions, et une adaptation dudit seuil de consommation déterminé dudit godet de données en fonction de ladite analyse.
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 à 8, lorsqu’il est exécuté par un processeur.
Dispositif de gestion du téléchargement progressif adaptatif (HAS) de contenus numériques (C1) au sein d’un terminal (3, 4, 8) lecteur de flux multimédia connecté à un réseau de communication mobile (1),
un 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 au cours d’une session, appelé godet de données, étant alloué audit terminal lecteur de flux multimédia,
caractérisé en ce qu’il comprend:
- un module d’estimation (301), en fonction d’un volume de données consommé par téléchargement progressif adaptatif de contenus numériques au cours d’une période par ledit terminal lecteur de flux multimédia, d’un volume de données qui pourrait être consommé par ledit terminal lecteur de flux multimédia par téléchargement progressif adaptatif desdits contenus numériques au cours de ladite session;
- un module de détermination (302) d’un débit d’encodage maximum autorisé pour le téléchargement de segments temporels desdits contenus numériques au cours de ladite session afin que ledit volume de données estimé soit inférieur ou égal à un seuil de consommation déterminé dudit godet de données.
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 10.