FR3124344A1 - Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif. - Google Patents

Abstract

Procédé de gestion d’accès à des contenus étant téléchargés en mode de téléchargement adaptatif. L’invention a trait à un procédé de gestion de l’accès à un contenu (C1) par un terminal de lecture de flux multimédia (DEC), le contenu étant reçu sous forme de segments vidéo disponibles selon plusieurs formats possibles définis dans un fichier de description (MF1), le fichier de description (MF1) du contenu (C1) étant renouvelable sur requête émise depuis le terminal de lecture (DEC), caractérisé en ce que l’émission de la requête de renouvellement est déclenchée dès réception d’une donnée d’événement incluse dans le contenu (C1) en cours de téléchargement et en ce que, suite à la réception du fichier de description renouvelé MF1(MF2), le procédé comprend une étape d’accès aux segments définis dans le fichier de description renouvelé. Figure 4.

Description

Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.

L’invention a trait aux domaines des télécommunications.

Le procédé a pour objet un procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif. L’invention vise tout particulièrement une gestion de l’accès à un contenu secondaire lors de la lecture d’un contenu principal par un terminal de lecture, le premier contenu et le deuxième contenu étant téléchargés en mode de téléchargement adaptatif.

Un contenu principal ou secondaire vise ici tous les contenus multimédias aptes à être transmis en mode de téléchargement adaptatif ; un tel contenu est par exemple un contenu dit en temps réel (ou en anglais « live »), une vidéo à la demande VOD, TVOD, etc.

Le terminal de lecture vise tout terminal apte à recevoir des contenus téléchargés en mode de téléchargement adaptatif. Un tel terminal est par exemple un décodeur de télévision numérique. Un tel terminal peut intégrer un écran ou être connecté à un terminal de restitution tel qu’un téléviseur pour la restitution du contenu.

Art antérieur

L’accès à un contenu multimédia, tel qu’à un contenu « live » ou la vidéo à la demande, est possible aujourd’hui, pour la plupart des terminaux de lecture. Le terminal de lecture émet généralement une requête à destination d’un serveur, en indiquant le contenu choisi et reçoit en retour un flux de données numériques relatives à ce contenu. Le contenu reçu est ensuite restitué.

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 restituer 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 de lecture 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, en fonction par exemple de la fluctuation de la bande passante disponible. En effet, une telle fluctuation peut induire une variation de la latence au fil du temps, appelée gigue, ou en anglais « jitter ».

On rappelle que la latence est définie, dans un réseau de transmission de données, comme le temps nécessaire à un paquet de données pour passer de la source à la destination au travers du réseau, i.e. le délai de transmission des données. Afin de compenser les effets néfastes de la gigue pour l’utilisateur, il est connu de placer une mémoire tampon (ou en anglais « buffer ») dans le terminal de restitution des flux de données reçus, dans laquelle sont stockées un certain nombre de paquets de données, avant le début de leur restitution à l’utilisateur. Ce tampon de gigue induit donc un délai détectable au début de la restitution du flux.

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 d’encodage. 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. Quand le terminal de lecture 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. Ces méthodes proposent d’adresser au terminal de lecture 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.

Il existe plusieurs modes de transport mettant en œuvre la norme MPEG-DASH. Parmi ces modes de transport, il y a le mode de transport connu sous le nom de CMAF-LL (sigle anglosaxon de « Common Media Application Format – Low Latency »). Dans ce mode CMAF-LL, les segments multimédias sont divisés en sous-segments. Ce mode est utilisé essentiellement pour diminuer le délai entre la préparation du contenu et l’affichage de celui-ci sur un terminal de restitution. En divisant les segments en sous-segments, le terminal de lecture peut demander au serveur contenus (ou de diffusion) de transmettre les sous-segments et les afficher sur la terminal de restitution sans attendre que le segment entier soit totalement disponible. Cette technique permet une réduction significative du délai entre la préparation du contenu et l’affichage de celui-ci.

En outre, un besoin actuel est de personnaliser les contenus transmis à destination du terminal. Une personnalisation de contenu a un intérêt en particulier dans le domaine de la publicité. Par exemple, lorsque le terminal de restitution est mobile, il peut y avoir un intérêt à localiser le terminal et à transmettre une publicité en fonction du lieu où est localisé le terminal.

La personnalisation du contenu peut être réalisée par des équipements dédiés puisque le terminal de lecture est capable de réactualiser régulièrement le fichier de description de contenu vidéo. Cependant, ces réactualisations successives du ficher de description peuvent poser problème, en particulier lorsque le mode de transport est par exemple de type Low latency (ex : CMAF-LL), et qu’une faible latence est requise. En effet, les réactualisations régulières du fichier de description empiètent sur la bande passante disponible sur le réseau pour la réception des segments vidéo. De plus, cela augmente les traitements à faire par le terminal de lecture; ceux-ci sont générateurs de retard. Dans ce mode de transport Low latency, le fichier de description d’un programme télévisé, en mode appelé DASH ‘segmentNumber’, n’est demandé qu’une fois ; dans cette configuration, tout au long de la lecture du contenu, le terminal de lecture se base sur ce fichier de description pour déterminer, de façon autonome, les prochains segments à récupérer.

Avec le mode CMAF-LL et les fichiers de description en mode DASH ‘segmentNumber’, une personnalisation de la lecture n’est plus possible pendant la lecture d’un programme télévisé car aucun fichier de description n’est mis à jour après envoi du fichier de description initial. Or, il est souhaitable dans certains cas de mettre à jour le fichier de description du programme télévisé pour pourvoir accéder à des contenus personnalisés lors de la lecture du programme télévisé par exemple en fonction d’un profil utilisateur ou du lieu où se trouve le terminal de lecture si ce dernier est mobile.

L’invention vient améliorer la situation.

A cet effet, l’invention se rapporte à un procédé de gestion de l’accès à un contenu par un terminal de lecture de flux multimédia, le contenu étant reçu sous forme de segments vidéo disponibles selon plusieurs formats possibles définis dans un fichier de description, le fichier de description du contenu étant renouvelable sur requête émise depuis le terminal de lecture, caractérisé en ce que l’émission de la requête de renouvellement est déclenchée dès réception d’une donnée d’événement incluse dans le contenu en cours de téléchargement et en ce que, suite à la réception du fichier de description renouvelé, le procédé comprend une étape d’accès aux segments définis dans le fichier de description renouvelé.

Selon l’invention, une demande de renouvellement du fichier de description n’est émise que suite à la réception d’une donnée d’événement caractéristique reçue en liaison avec le contenu en cours de restitution. La requête de renouvellement du fichier de description s’effectue ainsi au moment opportun c’est-à-dire, par exemple, au moment ou un évènement caractéristique apparait dans le flux reçu, comme par exemple un évènement indiquant qu’une séquence d’une ou plusieurs publicités va avoir lieu. La demande de renouvellement est ainsi suivie d’une réception d’un nouveau fichier de description permettant un accès à un contenu autre que le contenu téléchargé, par exemple un contenu personnalisé tel qu’une publicité personnalisée.

La solution proposée permet au terminal de lecture de déléguer la personnalisation d’un contenu, par exemple un contenu LIVE, hors du terminal tout en profitant d’un mode de transport tel que le mode CMAF-LL introduit ci-dessus requérant le moins possible de requêtes de renouvellement de fichiers de description.

Précisons ici qu’une donnée d’événement, aussi appelée marqueur par l’homme du métier, vise une donnée qui délimite des points d’ancrage temporels dans un programme. En plus de signaler la disponibilité d’un contenu tel qu’un contenu publicitaire, les marqueurs peuvent délimiter des séquences de contenus (séquence de vidéos, tunnel de publicités, spots de pub par exemple) en indiquant un début de séquence ou une fin de séquence.

Un fichier de description inclut des adresses d’accès aux segments d’un contenu.

Selon un premier mode de réalisation, des adresses d’accès incluses dans le fichier de description renouvelé reçu sont relatives à un contenu autre que le contenu téléchargé. La lecture du contenu téléchargé, dit contenu principal, est suivi d’u téléchargement d’un contenu secondaire. Ce premier mode permet de recevoir un contenu secondaire distinct du contenu principal sans nécessiter de requêtes successives et périodiques de mises à jour de manifeste comme dans l’art antérieur. Seule une requête de renouvellement est nécessaire pour accéder à un nouveau manifeste et donc à un autre contenu.

Selon un deuxième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode, la donnée d’événement est une donnée représentative d’une possibilité d’accès audit autre contenu. La donnée d’événement est choisie judicieusement parmi celles ayant un lien avec une restitution future d’un autre contenu que le contenu en cours de téléchargement comme par exemple une donnée d’événement indiquant qu’une séquence d’une ou plusieurs publicités va ou peut démarrer.

Selon un troisième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents modes, ledit autre contenu est un contenu personnalisé fonction d’un profil associé au terminal. Dans ce troisième mode, des adresses d’accès incluses dans le fichier de description renouvelé sont relatives à un contenu personnalisé pouvant être fonction d’un profil associé au terminal. L’invention facilite ainsi un accès à des contenus personnalisés sans nécessiter d’accès réguliers de demandes de mise à jour de manifeste qui seraient néfastes en terme de bande passante disponible sur le réseau et en terme de traitements informatiques réalisés par le terminal de lecture.

Selon un quatrième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents modes, le profil associé au terminal prend en compte une donnée caractéristique associée au terminal.

Une donnée caractéristique peut être l’une des données suivantes :

- Une localisation du terminal ;

- une donnée liée à un historique de recherche faite par un utilisateur du terminal de lecture ; on se base ici sur l’hypothèse que l’historique de recherche peut montrer un intérêt d’un utilisateur pour un domaine particulier (viticulture, etc.)

• ou toute autre donnée caractéristique du terminal (ex : petit consommateur TV, nombre de personnes du foyer, …)

A noter qu’une donnée de profil comme donnée d’événement n’est qu’un mode de réalisation. Le choix du contenu personnalisé peut être décidé par le serveur émetteur du contenu en prenant en compte d’autres considérations que des données liées au terminal de lecture. Par exemple une chaîne de télévision peut avoir, au moment de la réception d’une demande de renouvellement du fichier de description, à écouler un certain nombre de publicités.

Selon un aspect matériel, l’invention se rapporte à une entité de gestion de gestion de l’accès à un contenu par un terminal de lecture de flux multimédia, le contenu étant reçu sous forme de segments vidéo disponibles selon plusieurs formats possibles définis dans un fichier de description, le fichier de description du contenu étant renouvelable sur requête émise depuis le terminal de lecture, caractérisé en ce qu’il comprend, caractérisé en ce qu’il comprend

a. Un module d’émission apte à déclencher l’émission de la requête de renouvellement dès réception d’une donnée d’événement incluse dans le contenu en cours de téléchargement ;

b. Un module d’accès apte à accéder, suite à la réception du fichier de description renouvelé, aux segments définis dans le fichier de description renouvelé.

Selon un autre aspect matériel, l’invention a trait à un terminal caractérisé en ce qu’il comprend une entité de gestion telle que définie ci-dessus.

Selon un autre aspect matériel, l’invention a trait à un programme d’ordinateur apte à être mis en œuvre dans une entité de gestion tel que définie ci-dessus, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté réalise les étapes définies dans le procédé défini ci-dessus.

Selon un autre aspect matériel, l’invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini ci-dessus.

Précisions ici que le support de données 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, ou un disque dur. D'autre part, le support d'informations 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. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations 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é en question.

L’invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés sur lesquels :

représente un système informatique sur lequel est illustré un mode de réalisation du procédé de l’invention.

est une vue schématique des circuits présents dans le terminal de lecture.

est une vue schématique des segments qui composent le contenu principal.

est une vue schématique des échanges de messages selon un mode de réalisation du procédé de l’invention.

Description détaillée d'un exemple de réalisation illustrant l'invention :

On présente désormais, en relation avec la , une architecture de téléchargement progressif basée sur l’utilisation du streaming adaptatif HAS selon un mode de réalisation de l’invention. Précisons à nouveau ici que l’invention ne se limite pas à la technologie HAS mais s’étend à toutes autres technologies de téléchargement de données.

Le système informatique SYS comprend un terminal de lecture de flux multimédia DEC, par exemple un décodeur connecté à un terminal de restitution TV tel qu’un dispositif de restitution.

Dans notre exemple, le terminal de lecture DEC peut être connecté sur un port du dispositif de restitution TV ou intégré au terminal de lecture. Dans notre exemple, à des fins d’illustration, on a choisi un système dans lequel le terminal de lecture décodeur DEC est connecté via un port au dispositif de restitution TV.

Dans notre exemple, le terminal de lecture DEC est situé dans un réseau local LAN piloté par une passerelle domestique GTW. Le contexte du réseau local est donné à titre d’exemple et pourrait être transposé aisément à un réseau Internet de type « best effort », un réseau d’entreprise, etc.

La passerelle GTW est apte à communiquer via un réseau de télécommunication tel qu’un réseau étendu WAN connu de l’homme du métier.

Un/des serveurs de contenus numériques SRV se trouve(nt) selon cet exemple dans le réseau étendu WAN. Le serveur de contenus SRV 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, ici le terminal de lecture DEC.

Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre le terminal client DEC et le serveur de contenus SRV, à 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 DEC et la passerelle de services GTW, et/ou entre cette dernière et le serveur de contenus SRV.

Le mode de transport est par exemple le mode CMAF_LL introduit ci-dessus. Dans ce mode, des segments sont découpés en « sous-segments ». Pour simplifier l’explosé, on parlera de segments à la place de « sous-segments ».

La représente une architecture d’un terminal de lecture DEC, par exemple un décodeur.

Le décodeur DEC comprend, classiquement, des mémoires MEM 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.

Le décodeur DEC comprend une mémoire tampon appelée aussi antémémoire ou buffer par l’homme du métier.

Le décodeur DECpeut transmettre un contenu à restituer au dispositif de restitution TV via un module de communication COM1. Ce module CO1 est par exemple une liaison HDMI.

Le décodeur DEC communique avec la passerelle GTW via un module Ethernet pour une communication locale avec fils ou via un module radio de type WiFi pour une communication locale sans fils avec la passerelle résidentielle GTW. Le mode en question est référencée CMO1 sur la .

Ces communications sont possibles via un module de communication COM1 et un module de communication COM2, respectivement.

Le décodeur DEC comprend 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. Ce fichier de description peut être téléchargé et enregistré par exemple dans les mémoires MEM du décodeur DEC ou se trouver à l’extérieur.

Le décodeur DEC comprend en outre un module de gestion MNG dont la fonction sera expliquée ci-après.

Le décodeur DEC peut aussi contenir d’autres modules comme un disque dur non représenté pour le stockage des segments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues du smartphone, etc.

Classiquement, comme on le verra en référence à la , différentes qualités peuvent être encodées pour le même contenu d’une chaîne, correspondant par exemple à différents débits d’encodage. 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 d’encodage. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (ou « segments » 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 segments de contenu, est accessible par le terminal client et mis à sa disposition via leurs adresses Internet. Les adresses Internet identifient des segments sur un réseau. Une telle adresse peut être un identifiant de type URI (sigle anglo saxon de « Universal Ressource Identifier ») connu de l’homme du métier. L’ensemble de ces paramètres (qualités, adresses des segments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description ou « manifeste MNF ». 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.

Dans un contexte de téléchargement adaptatif progressif, le terminal DEC peut adapter ses requêtes pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui lui correspond au mieux. Par exemple, si on considère un contenu disponible aux trois qualités suivantes 416 kb/s (kilobits par seconde), 680 kb/s (N2), et 1200 kb/s (N3). Supposons aussi que le terminal de lecture DEC dispose d’une bande passante de 5000 kb/s. dans cette configuration, le terminal de lecture DEC peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 1200 kb/s.

De manière générale, en référence à la , on note « Ci@Nj » le contenu numéro i avec la qualité Nj (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description).

Le nombre de débits d’encodage disponibles par segment varie selon le terminal de lecture utilité. Sur la , par exemple un contenu principal C1 comprend cinq débits d’encodage disponibles N1-N5.

Dans notre exemple, le système comprend en outre un encodeur ENC et un générateur de manifeste GMF. L’encodeur ENC a pour rôle d’encoder un contenu numérique afin d’obtenir plusieurs segments et plusieurs représentations pour chaque segment. Dans notre exemple, l’encodeur ENC ajoute aussi des données d’événements EVT à des segments.

Le contenu encodé et les données d’événement EVT sont transmis au générateur de manifeste GMF qui génère des adresses URI pour chaque segment créé.

Dans l’exemple illustré, l’encodeur ENC et le générateur de manifeste GMF forment un fournisseur de contenus référencé FCNT.

Les segments, les données d’événement et les manifestes sont transmis par le fournisseur de contenus FCNT à un équipement EQ. Cet équipement EQ est un serveur dans notre exemple.

A noter que l’équipement EQ et le serveur SRV auraient pu former un seul et unique serveur.

Dans notre exemple, le terminal de lecture DEC est un terminal client et peut à ce titre entrer en communication avec le serveur de contenus SRV pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.). Le terminal de lecture DEC peut aussi entrer en communication avec l’équipement EQ comme cela sera expliqué ci-dessous.

Dans notre exemple, pour visualiser un contenu, le terminal DEC obtient une adresse du fichier de description MNF d’un contenu principal (par exemple, C1) souhaité. Dans la suite, on supposera que ce fichier est un fichier de type manifeste selon la norme MPEG-DASH et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifeste».

Une fois que le terminal de lecture DEC dispose des adresses de segments correspondant au contenu souhaité, le terminal DEC procède à l’obtention des segments 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).

Lorsque le décodeur DEC reçoit les segments, les segments sont ensuite restitués sur l’écran du dispositif de restitution TV.

Dans notre exemple, du fait que le mode de transport utilisé est le CMAF-LL, les contenus numériques visés sont des contenus Live ; cependant, l’invention s’applique à d’autres modes de transports et à d’autres type de contenus ; le contenu principal C1 peut être un programme télévisuel diffusé en différé, ou une vidéo à la demande, ou une vidéo personnelle de l’utilisateur, ou tout autre contenu multimédia équivalent.

On verra ci-dessous que l’invention a pour but d’insérer une lecture d’un contenu secondaire au cours de la lecture d’un contenu principal. Le contenu secondaire est du même type que le contenu principal en ce qu’il est formé de segments HAS.

Dans le mode de réalisation décrit ci-dessous, le contenu principal est par exemple une émission de télévision, et le contenu secondaire est par exemple un contenu publicitaire. Le but dans notre exemple est d’insérer le contenu publicitaire lorsque cela est possible, lors de la lecture du contenu principal C1. Plus particulièrement, le but est d’insérer dans le contenu principal C1 un contenu publicitaire C2 personnalisé. On entend par contenu publicitaire personnalisé un contenu publicitaire adapté au profil du terminal de lecture.

Le serveur de contenus SRV stocke le contenu C1 sous forme de segments. Plus précisément, le serveur de contenu HAS expose une vidéo C1 sous forme de segments ou « 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 comme expliqué ci-dessus.

Le module de téléchargement HAS du décodeur DEC est chargé de venir récupérer des « chunks » auprès du serveur de contenu HAS 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 de téléchargement HAS choisit le débit d’encodage du prochain segment vidéo à télécharger : il existe en effet de nombreux algorithmes permettant d’opérer ce choix. On rappelle cependant que, le plus souvent, le principe général de tels algorithmes repose sur le téléchargement d’un premier segment au débit d’encodage le plus faible proposé dans le fichier manifeste, et sur l’évaluation du temps de récupération de ce premier segment. Sur cette base, le module de téléchargement HAS évalue si, en fonction de la taille du segment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le segment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des segments 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 segments successifs.

Dans le cas classique, si un « chunk » vidéo dure « n » secondes, la récupération du « chunk » par le module de téléchargement HAS ne doit pas excéder « n secondes », afin de permettre une restitution sans interruption du contenu par le décodeur DEC. Il convient donc pour le module de téléchargement 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 segment, qui doit être suffisamment faible pour permettre une restitution en continu sur le dispositif de restitution TV.

Dans l’exemple illustré, le mode de transport utilisé est le mode CMAF-LL dans lequel les segments sont divisés en sous-segments. Ce mode permet de télécharger des sous-segments avant même d’avoir reçu la totalité du segment. Ce mode permet une réduction significative de la latence de bout en bout.

Comme indiqué ci-dessus, à des fins de simplification de l’exposé de l’invention, le terme segment sera utilisé pour désigner un « sous-segment ».

Le module de téléchargement HAS présent sur le terminal de lecture DEC commande le téléchargement d’un segment au débit d’encodage optimal comme décrit plus en détail par la suite.

Dans un premier temps, le module HAS récupère le fichier manifeste MNF1 qui correspond au contenu vidéo C1 afin de découvrir les segments disponibles du contenu vidéo C1, et les différentes qualités vidéo Nj associées. Dans l’exemple de la , le contenu principal C1 est par exemple proposé sous forme de segments de durée 2s, avec un premier débit d’encodage N1 = 416kb/s, un deuxième débit d’encodage N2 = 680 kb/s, un troisième débit d’encodage N3 = 1200 kb/s, etc.

Dans un mode de fonctionnement normal, le module HAS opère le téléchargement par exemple, des segments successifs C11@N1 (soit le premier segment temporel à un débit d’encodage de 416 kb/s), puis C12@N2 (soit le deuxième segment temporel à un débit d’encodage de 680 kb/s), puis C13@N3 (soit le troisième segment temporel à un débit d’encodage de 1200 kb/s), etc.

Selon l’invention, l’instant de demande d’accès à un nouveau fichier de description est déclenché suite à la réception d’une donnée d’événement transmise avec des segments du contenu en cours de téléchargement.

En d’autres mots, à réception d’une donnée d’événement particulière, le module de gestion MNG déclenche la transmission d’une requête de renouvellement du manifeste du contenu en cours de téléchargement.

En réponse à la demande de renouvellement, le terminal de lecture DEC reçoit soit un manifeste personnalisé s’il y en a un ; à défaut, le terminal de lecture reçoit un manifeste renouvelé mais non personnalisé. La réception d’un manifeste personnalisé permet alors un accès à un contenu personnalisé.

Un manifeste personnalisé associé au contenu en cours de téléchargement consiste par exemple à inclure dans ce manifeste des adresses URI d’un contenu donné, dit contenu secondaire, tel qu’une publicité par exemple en fonction du profil associé au terminal de restitution.

On voit bien que l’accès au contenu et au contenu personnalisé ne nécessite au mieux qu’un manifeste initial et un renouvellement de manifeste.

Plus généralement, en considérant un contenu principal C1 et plusieurs contenus secondaires C2n disjoints à insérer dans le contenu principal (n est un entier désignant un contenu secondaire particulier), « n » demandes de renouvellement de manifeste seront effectuées sur détection de données d’événement respectives. Précisons que des contenus disjoints sont des contenus qui ne se lisent pas successivement.

On considère dans la suite un seul contenu personnalisé C21 ; cependant l’invention s’applique de la même façon à un nombre quelconque de contenus personnalisés à insérer dans le contenu principal.

On notera ici qu’un contenu personnalisé peut inclure plusieurs « sous-contenus ». Les « sous-contenus » sont par exemple des publicités à lire successivement.

La représente une suite d’étapes illustrant un premier mode de réalisation du procédé de l’invention. Ce mode concerne l’insertion de contenus publicitaires au cours de la restitution d’un contenu.

On considère par exemple que l’utilisateur du terminal DEC est un amateur de vin.

Dans le mode décrit ci-dessous, le contenu principal est une vidéo et le contenu secondaire à insérer dans le contenu principal est une publicité. Selon une variante possible, le contenu secondaire pourrait aussi être plusieurs publicités consécutives.

Le mode de réalisation comprend deux phases PH1 et PH2.

Lors d’une première phase PH1, dans notre exemple, un contenu dit secondaire C2 est transmis, par un fournisseur se contenus FCNT, au serveur de contenus SRV et stocké sur le serveur de contenus sous forme de segments C2i@Nj. Ce contenu secondaire concerne par exemple une publicité sur un thème donné par exemple les vins de Bordeaux.

Dans notre exemple le manifeste MF2 associé au contenu secondaire C2 est transmis, par un fournisseur se contenus FCNT, vers l’équipement EQ et stocké sur l’équipement.

A ce stade, le manifeste MF2 est connu de l’équipement EQ et les segments du contenu secondaire C2 sont stockés sur le serveur de contenus SRV.

Lors d’une deuxième phase PH2, le fournisseur de contenus FCNT transmet un contenu dit « live » C1 à destination du serveur de contenus SRV, des données temporelles EVT associés au contenu C1.

Le fournisseur de contenus FCNT transmet aussi le manifeste MF1 associé au contenu C1 à l’équipement EQ qui stocke le manifeste MF1.

A ce stade, les deux manifestes MF1 et MF2 sont créés sont stockés sur l’équipement EQ. Dans la suite, le but pour l’équipement EQ est d’inclure les donnes du manifeste MF2 dans le manifeste M1. On verra que l’insertion des données du manifeste MF2 dans le manifeste MF1 s’effectue selon le profil du terminal de restitution. Cette étape d’insertion peut s’effectuer au cours de la première phase PH1 ou au cours de la deuxième phase PH2.

On suppose maintenant qu’un utilisateur souhaite accéder au contenu principal C1.

L’utilisateur sélectionne le contenu principal C1 via une interface graphique (non représentée) affichée sur le dispositif de restitution TV ou via un équipement associé au terminal de lecture (ex : télécommande).

Suite à la sélection, le terminal de lecture DEC requiert un accès au contenu principal C1. Ce contenu principal est par exemple une émission télévisée transmise en mode « live ». La requête d’accès REQ(C1) au contenu principal C1 est transmise depuis le terminal de lecture DEC à destination de l’équipement EQ pour obtenir le manifeste MF1 associé au contenu principal C1.

Suite à la requête, dans notre exemple, le terminal de lecture DEC reçoit depuis l’équipement EQ un manifeste MF1 lié au contenu principal C1. Le terminal de lecture DEC peut accéder aux différents segments du contenu principal C1 grâce aux adresses stockées dans le manifeste MF1 ; le terminal de lecture DEC transmet pour cela des requêtes GET(C1i@Nj) successivement au serveur de contenus SRV.

Suite à la réception du premier segment C11@Nj, le dispositif de lecture DEC accède aux différents segments C1i@Nj en sélectionnant des qualités d’image Nj respectives en fonction de la bande passante courante disponible comme expliqué ci-dessus en liaison avec le mode de téléchargement adaptatif.

Lors de la transmission des différents segments du contenu principal C1 qui fait suite à la réception des requêtes d’accès, le serveur SRV transmet à destination du terminal de lecture DEC des données d’événements EVT qui accompagnent tout ou partie des segments.

Dans notre exemple, on s’intéressera à une donnée d’évènement nommée « AdSrvCall ». L’invention ne se limite pas à cette donnée d’événement mais s’étend à toutes autres données d’événement propice à un renouvellement de manifeste et donc à une éventuelle personnalisation du contenu à restituer.

On suppose qu’à un instant donné, au cours du téléchargement des segments de données, le terminal de lecture reçoit la donnée d’événement « AdSerCall ».

Dans notre exemple, à réception de cette donnée d’événement AdServCall, le terminal de lecture DEC, sous–entendu le module de gestion MNG présent dans le terminal de lecture, déclenche la transmission d’une demande de renouvellement R-MF1 du MF1 manifeste à destination de l’équipement EQ. Cette demande d’accès vise un renouvellement R-MF du manifeste MF1. A noter ici que la demande d’accès ne spécifie pas de contenu en particulier.

A réception de la requête d’accès au manifeste, plus précisément à une mise à jour du manifeste associé au contenu principal, l’équipement EQ vérifie si un contenu secondaire personnalisé est disponible pour le terminal de lecture DEC. Par exemple, l’équipement EQ peut avoir accès à une table de correspondance dans laquelle est stockée pour des identifiants de terminaux de lecture, un profil utilisateur ou déléguer ce traitement à un autre équipement (ex : AdServer). Un profil utilisateur fournit des informations sur des préférences utilisateurs, un profil familial (âge des membres d’une famille). Grâce à cette table, il suffit pour l’équipement EQ de récupérer un identifiant du terminal de lecture DEC et de vérifier si un contenu secondaire correspond à cet identifiant et donc au profil utilisateur.

En reprenant l’exemple ci-dessus, l’équipement EQ vérifie si des contenus secondaires, des publicités dans notre exemple, ont traits au domaine viticole. Dans l’affirmative, l’équipement EQ transmet, en réponse à la demande de renouvellement de manifeste MF1, un nouveau manifeste MF1(MF2) incluant des données extraites du manifeste MF2 associé au contenu secondaire C2 chargé lors la première phase PH1, une publicité dans notre exemple, en rapport avec les vins. Dans la négative, l’équipement transmet en réponse à la demande de renouvellement le Manifeste MF1 sans modification.

Suite à la réception du nouveau manifeste MF1 associé au contenu C1, en supposant que le nouveau manifeste a été personnalisé et qu’il inclut donc des données relatives au deuxième manifeste MF2, le terminal de lecture DEC requiert des accès successifs aux différents segments C2i@Nj du contenu secondaire. Sans le cas où le manifeste renouvelé n’inclut pas de données relatives au contenu secondaire C2, dans ce cas il accède à un contenu principal non personnalisé et télécharge les segments en mode de streaming adaptatif comme expliqué ci-dessus.

Signalons enfin ici que, dans le présent texte, le terme « module » ou « entité » 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.).

Claims (9)

1. Procédé de gestion de l’accès à un contenu (C1) par un terminal de lecture de flux multimédia (DEC), le contenu étant reçu sous forme de segments vidéo disponibles selon plusieurs formats possibles définis dans un fichier de description (MF1), le fichier de description (MF1) du contenu (C1) étant renouvelable sur requête émise depuis le terminal de lecture (DEC), caractérisé en ce que l’émission de la requête de renouvellement est déclenchée dès réception d’une donnée d’événement incluse dans le contenu (C1) en cours de téléchargement et en ce que, suite à la réception du fichier de description renouvelé MF1(MF2), le procédé comprend une étape d’accès aux segments définis dans le fichier de description renouvelé.
2. Procédé de gestion selon la revendication 1, caractérisé en ce qu’un fichier de description inclut des adresses d’accès aux segments d’un contenu, et en ce que des adresses d’accès incluses dans le fichier de description renouvelé reçu sont relatives à un contenu autre que le contenu téléchargé.
3. Procédé de gestion selon la revendication 2, caractérisé en ce que la donnée d’événement est une donnée représentative d’une possibilité d’accès audit autre contenu.
4. Procédé de gestion selon la revendication 2 ou 3, caractérisé en ce que ledit autre contenu est un contenu personnalisé fonction d’un profil associé au terminal.
5. Procédé de gestion selon la revendication 4, caractérisé en ce que le profil associé au terminal prend en compte une donnée caractéristique associée au terminal.
6. Entité de gestion (MNG) de gestion de l’accès à un contenu (C1) par un terminal de lecture de flux multimédia (DEC), le contenu étant reçu sous forme de segments vidéo disponibles selon plusieurs formats possibles définis dans un fichier de description (MF1), le fichier de description (MF1) du contenu (C1) étant renouvelable sur requête émise depuis le terminal de lecture (DEC), caractérisé en ce qu’il comprend

   1. Un module d’émission apte à déclencher l’émission de la requête de renouvellement dès réception d’une donnée d’événement incluse dans le contenu en cours de téléchargement ;
   2. Un module d’accès apte à accéder, suite à la réception du fichier de description renouvelé, aux segments définis dans le fichier de description renouvelé.
7. Terminal (DEC) caractérisé en ce qu’il comprend une entité de gestion (MNG) telle que définie dans la revendication 5.
8. Programme d’ordinateur apte à être mis en œuvre dans une entité de gestion tel que définie dans la revendication 6, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté réalise l’étape définie dans la revendication 1.
9. Support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini dans l’une des revendications 1 à 5.