TITRE : Gestion de gestion de la fourniture d'adresses de segments d'un contenu multimédia

Domaine technique

Le domaine de l'invention est celui de la gestion de la fourniture d'adresses de segments d'un contenu multimédia à un dispositif de lecture de contenus.

L'invention vise tout particulièrement des contenus segmentés, les segments étant accessibles selon plusieurs formats associés à des tailles respectives en octets ayant plus ou moins d'impact sur la bande passante du réseau sur lequel le contenu est téléchargé. L'invention vise tout particulièrement les contenus téléchargés selon une technique dite de téléchargement progressif adaptatif, ou HAS, ou toutes autres techniques de téléchargement utilisant le même principe.

Etat de la technique

Lors d'un accès à un contenu, un dispositif de lecture émet généralement une requête à destination d'un serveur, en indiquant le contenu choisi ; le dispositif de lecture reçoit en retour un flux de données numériques relatives à ce contenu. Dans le cadre d'un réseau de communication local, une telle requête transite par la passerelle d'accès au réseau, par exemple la passerelle résidentielle.

Le dispositif de lecture est adapté pour recevoir un contenu numérique sous forme de données multimédia et pour requérir une restitution de ce contenu sur un dispositif de restitution. Les données reçues correspondant à une vidéo sont généralement décodées, puis restituées 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 dispositif de lecture, ou consommation par l'utilisateur du dispositif de lecture, à une visualisation sur l'écran du dispositif de lecture.

La diffusion de contenus numériques sur Internet est souvent basée sur des protocoles client-serveur de la famille HTTP (de l'anglais « Hyper Text Transport Protocol »). En particulier, le téléchargement en mode progressif des contenus numériques, aussi appelé streaming, permet de transporter et consommer les données en temps réel, c'est-à-dire que les données numériques sont transmises sur le réseau et restituées par le dispositif de lecture au fur et à mesure de leur arrivée. Le dispositif de lecture reçoit et stocke une partie des données numériques dans une mémoire tampon (buffer en anglais) 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.

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 description, appelé « fichier de description » par l'homme du métier, disponible en téléchargement sur un serveur de données, par exemple un serveur de contenus. Quand le dispositif de lecture 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 dispositif de lecture client. Ce type de technique permet notamment de tenir compte des variations de bande passante sur la liaison entre le dispositif de lecture 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 « fichiers de description », contenant les adresses des différents segments aux différentes qualités du contenu multimédia.

Une fonction appelée Start Over (ou « rattrapage » ou « retour au début ») permet à un utilisateur qui regarde un contenu diffusé en temps réel (chaine Live) de sélectionner sur une fenêtre temporelle donnée un instant de lecture ; cette fonction permet notamment de relire un contenu depuis son début. Une fenêtre temporelle est utile en particulier pour les contenus numériques dits « live », i.e. qui correspondent à des programmes télévisuels en temps réel, qui n'ont, par nature, pas de durée prédéfinie, ou de date de fin. Dans ce cas de figure, le dispositif de lecture reçoit une commande de réalisation d'un saut temporel dans le contenu pour lire le contenu, par exemple une émission de télévision, à partir d'un instant antérieur à l'instant courant de lecture. Par exemple, si un film débute à 21h00 et si l'utilisateur zappe sur la chaine à 21h40, il peut demander à ce que la lecture du contenu reprenne depuis le début du film en activant le mode dit de rattrapage. Dans ce cas, on passe d'un mode de lecture en temps réel à un mode de rattrapage.

Quand cet utilisateur accède au flux Live diffusé en http Adaptative Streaming (HAS), le dispositif de lecture récupère à intervalle régulier, en général toutes les deux secondes, un fichier de description qui décrit généralement les soixante dernières secondes du flux (30 segments de 2 secondes) en fournissant des adresses de segments correspondant à ces soixante dernières secondes. On peut alors décider de stocker dans une mémoire tampon une certaine partie du flux (ici jusqu'à 60 secondes au maximum). Les segments vidéos sont de courte durée car on souhaite être au plus proche du vrai Live. C'est également pour cette raison qu'on récupère le fichier de description toutes les deux secondes et qu'on limite la profondeur de buffer en général autour de quinze secondes.

Lorsqu'on bascule sur le mode dit de rattrapage, donc en mode de lecture à la demande, le fichier de description qui est récupéré ne décrit plus les soixante dernières secondes mais une fenêtre temporelle de plusieurs heures, par exemple les quatre dernières heures (dans le cas où on souhaite pouvoir accéder aux 4 dernières heures de la chaine Live). La taille du fichier de description est donc multipliée par deux cent quarante (240) et le temps de lecture (ou temps de parsing pour l'homme du métier) du fichier de description, la plupart du temps au format XML, devient un réel problème. En effet, il faut récupérer, comme lors de la lecture du flux en temps réel, le fichier de description de manière périodique toutes les deux secondes et à chaque récupération parcourir l'ensemble du fichier de description qui comprend un nombre très important d'adresses de segments vidéo et audio.

Une solution pourrait consister à diminuer la fenêtre temporelle par exemple à deux heures au lieu de quatre heures. Dans ce cas, le service rendu à l'utilisateur est fortement dégradé car il n'est pas garanti de pouvoir revenir par exemple au début du film qu'il regarde.

L'invention vient améliorer la situation.

L'invention L'invention se rapporte à un procédé de gestion de la fourniture de fichiers de description associés à des segments d'un contenu segmenté, les fichier de description, dits premiers fichier de descriptions, comprenant des adresses de segments du contenu et étant transmis successivement les uns après les autres en vue d'une lecture par un dispositif de lecture, caractérisé en ce qu'il comprend, au cours de la transmission du contenu en temps réel, une étape de réception d'une commande de réalisation d'un saut temporel dans le contenu pour lire le contenu à partir d'un instant antérieur à l'instant courant de lecture, l'étape de réception déclenchant une étape de transmission d'un deuxième fichier de description comprenant des adresses de segments à lire audit instant antérieur, complétées d'une partie des adresses de segments du contenu ayant déjà été transmises.

L'invention permet, lorsqu'une demande de saut temporel est demandée, de transmettre non pas un fichier de description complet comportant toutes les adresses de segments ayant été diffusés comme dans l'art antérieur mais un sous ensemble d'adresses de segment du fichier de description complet. En d'autres mots le fichier de description transmis est incomplet et ne comporte qu'une partie des adresses de segments qui seront judicieusement choisies comme on le verra dans la suite.

On comprend que le fichier de description créé est fortement réduit en taille par rapport à celui de l'état de la technique car il ne contient en définitive que des adresses de segments à lire, tout comme pour une lecture classique, et au mieux quelques autres adresses de segments comme on le verra dans la suite de la description. On verra en effet dans la description qui suit que le fichier de description créée selon l'invention décrit que quelques minutes (trois minutes par exemple) de description des segments alors qu'un fichier de description complet peut décrire des heures par exemple quatre heures.

Aussi, le temps de récupération d'un segment dans le fichier de description objet de l'invention est rapide du fait du nombre très réduit d'adresses de segments compris dans le deuxième fichier de description reçu ; le temps de transmission sur le réseau d'un tel fichier de description est aussi avantageux en termes de bande passante car de taille réduite.

Selon un premier mode de réalisation du procédé, la partie d'adresses inclut des adresses de segments transmises dans le dernier fichier de description, dit premier fichier de description, en liaison avec la lecture en temps réel. Ce mode permet un retour au direct sans délai car évite de requérir le premier fichier de description lié au retour au direct.

Selon encore 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, la partie d'adresses de segments inclut des segments choisis parmi les premiers segments du contenu. Tout comme le mode précédent, ce mode permet depuis l'instant de lecture en cours, en mode de rattrapage, de requérir une reprise depuis le début sans délai car les adresses de ces segments sont présentes dans le deuxième fichier de description. On verra dans la suite que les segments choisis parmi les premiers segments vise les segments les plus anciens accessibles dans la fenêtre temporelle proposée. Par exemple, si le mode rattrapage permet de revenir sur une fenêtre temporelle de quelques heures, par exemple quatre heures dans le passé, les segments les plus anciens sont les segments les plus anciens dans cette fenêtre temporelle de quatre heures.

Lorsque la partie d'adresses inclut à la fois les adresses visées dans le premier mode et des adresses visées dans le deuxième mode, une barre de progression (ou timeline) peut être restituée afin de situer dans le temps l'instant de lecture courant et permettre une sélection d'un instant de lecture antérieur ou postérieur dans cette barre de progression et de poursuivre la lecture depuis l'instant sélectionné.

Selon encore 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, le deuxième fichier de description est mis à jour au fil du temps ; en particulier, les dernières adresses de segments associé au flux transmis en temps réel sont mises à jour. Chaque mise à jour permet un retour au flux transmis en temps réel sans nécessiter de recevoir une requête d'accès au premier fichier de description pour l'accès au contenu diffusé en temps réel.

Selon encore 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, une sélection, dans le deuxième fichier de description, d'une des dernières adresses de segments entraîne une transmission d'un premier fichier de description, à la place du deuxième ficher de description. Ce quatrième mode permet un retour automatique au mode de lecture en temps réel. Ce mode permet un retour au mode normal et donc un retour aux premiers fichiers de description qui sont de taille plus réduite que le deuxième fichier de description.

Selon encore un cinquième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, l'instant antérieur est sélectionné dans une fenêtre temporel donnée, et la partie des autres adresses de segments du contenu ayant été transmis est issue de cette fenêtre temporelle.

Selon une variante de ce cinquième mode, la fenêtre temporelle a une durée fixe. Ce mode est intéressant lorsque le contenu n'a pas d'instant de début prédéfini ; c'est le cas pour la plupart des contenus transmis en temps réel comme cela est expliqué ci-dessous..

Lorsque le contenu a un instant de début qui est défini, on peut dans ce cas prévoir une fenêtre temporelle dont la durée varie dans le temps en fonction de l'instant de début du contenu considéré.

Selon un aspect matériel, l'invention se rapporte à une entité de gestion de la fourniture de fichiers de description associés à des segments d'un contenu segmenté, les fichiers de description, dits premiers fichiers de description, comprenant des adresses de segments du contenu et étant transmis successivement les uns après les autres en vue d'une lecture par un dispositif de lecture, caractérisé en ce qu'elle comprend un microprocesseur configuré pour, au cours de la transmission du contenu en temps réel, réaliser une étape de réception d'une commande de réalisation d'un saut temporel dans le contenu pour lire le contenu à partir d'un instant antérieur à l'instant courant de lecture, cette étape de réception déclenchant une étape de transmission d'un deuxième fichier de description comprenant des adresses de segments à lire audit instant antérieur, complétées d'une partie des adresses de segments du contenu ayant déjà été transmises.

Selon un autre aspect matériel, l'invention se rapporte à un terminal lecteur comprenant une entité de gestion telle que définie ci-dessus.

Selon un autre aspect matériel, l'invention a pour objet un programme d'ordinateur apte à être mis en œuvre sur une entité de gestion telle que définie ci-dessus, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur, réalise les étapes du procédé de gestion définies ci-dessus.

Selon un autre aspect matériel, l'invention a pour objet un support de données sur lequel a été mémorisée au moins une série d'instructions de code de programme pour l'exécution d'un procédé de gestion tel que défini ci-dessus.

Le support en question 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 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 :

[Fig 1] représente une architecture de téléchargement progressif sur Internet basée sur l'utilisation du streaming adaptatif selon un mode de réalisation du procédé de l'invention ;

[Fig 2] illustre de façon schématique la structure matérielle d'un serveur apte à transmettre des fichiers de description ;

[Fig 3] illustre de façon schématique la structure matérielle d'un dispositif de lecture apte à lire des flux multimédias en temps réel ;

[Fig 4] illustre un contenu et les segments disponibles pour ce contenu.

[Fig 5] illustre l'état de la lecture à un instant donné lorsque le mode rattrapage est exécuté ; on verra en particulier qu'au cours de ce mode, l'entité de gestion met en œuvre un algorithme pour générer un fichier de description spécifique au mode de lecture en rattrapage.

[Fig 6] illustre l'état de la lecture à un autre instant que celui décrit en référence à la figure 5 et toujours au cours de la lecture en mode rattrapage. [Fig 7] illustre schématiquement une fenêtre temporelle mise en œuvre dans depuis laquelle est issue ladite partie des autres adresses de segments du contenu ayant été transmis venant s'ajouter aux adresses de segments à lire audit instant antérieur pour former en définitive un deuxième fichier de description.

[Fig 8] illustre des étapes d'un mode de réalisation.

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

La figure 1 représente un système informatique SYS dans lequel est mis en œuvre un réseau de diffusion de contenus appelé CDN (Content Distribution Network) par l'homme du métier depuis lequel sont transmis des contenus à destination de dispositifs clients ou dispositifs de lecture de contenus et des fichiers de description associés aux contenus multimédias.

Dans notre exemple, le système comprend un seul dispositif de lecture STB. Cependant l'invention s'applique à un nombre quelconque de dispositifs de lecture.

Le dispositif de lecture est par exemple un dispositif de lecture numérique.

Le contenu multimédia visé ici est un contenu vidéo correspondant par exemple à une chaîne de télévision sur laquelle sont diffusés des programmes télévisés ayant une heure de début correspondant à une heure de diffusion programmée et une heure de fin. Le contenu en question en diffusé en mode multicast.

Le dispositif de lecture STB est connecté à un terminal de restitution TV tel qu'une télévision.

Dans notre exemple, le dispositif de lecture STB est connecté sur un port du dispositif de restitution TV ; le dispositif de lecture STB et le dispositif de restitution TV pourrait aussi former un seul et unique dispositif.

Dans notre exemple, le dispositif de lecture STB est situé dans un réseau local LAN (sigle anglosaxon de « Local Area Network ») géré 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 LI1 tel qu'un réseau étendu WAN connu de l'homme du métier. Le système informatique SYS met en œuvre un réseau de diffusion de contenus appelé CDN (Content Distribution Network) par l'homme du métier depuis lequel des contenus sont transmis à destination de dispositifs clients ou dispositifs de lecture de contenus STB.

Le réseau CDN est constitué de serveurs reliés en réseau dans le réseau étendu ; ces serveurs coopèrent afin de mettre des contenus multimédias à disposition des utilisateurs en mode unicast. Afin de simplifier l'exposé de l'invention, un seul serveur de contenus SRV sera représenté sur la figure 1 pour représenter le CDN. Le serveur de contenus SRV se trouve, dans notre 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 les met à disposition en temps réel à des terminaux clients, ici le dispositif de lecture STB.

Les contenus CNT sont mis à disposition en mode unicast dans un format donné. Un tel contenu CNT est, par exemple, un contenu téléchargé en mode de streaming adaptatif. 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 ; ce standard se base sur la préparation du contenu en différentes repré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 » par l'homme du métier. Chacun de ces segments est rendu disponible individuellement au moyen d'un protocole d'échange entre le terminal de restitution et le serveur fournisseur de contenus multimédias. 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 fichier de description au format XML. Nous ne rentrerons pas plus dans les détails de ce mode de téléchargement car sans intérêt pour l'exposé de l'invention.

La figure 2 le serveur SRV est également équipé d'au moins un processeur CPU2 et de mémoires MEM2 pour la réalisation de traitement informatique. Le serveur est également équipé d'une entité de gestion ENT2, dite première entité, apte à gérer la transmission d'un contenu et du fichier de description associés au contenu du serveur SRV à destination d'un ou plusieurs dispositifs de lecture. Le serveur SRV communique avec la passerelle GTW via réseau WAN. Le serveur comporte, la communication avec le réseau WAN, un module de communication référencé COM2 sur la figure 3. On s'intéressera essentiellement dans la suite à la transmission du fichier de description plutôt que de la transmission des segments.

La figure 3 représente une architecture d'un dispositif de lecture STB. Ce dispositif STB comprend, classiquement, des mémoires MEM1 associées à un processeur CPU1. 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 dispositif de lecture STB peut transmettre un contenu à restituer au dispositif de restitution TV via un module de communication COM12. Ce module COM12 est par exemple une liaison HDMI.

Le dispositif de lecture STB communique avec la passerelle 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 module en question est référencé CMO11 sur la figure 2.

Le dispositif de lecture STB comprend une entité de téléchargement en mode streaming (non représentée) apte à gérer le téléchargement de segments du contenu. Le dispositif de lecture STB comprend également une entité de gestion ENT1, dite deuxième entité de gestion dans la suite apte à lire un fichier de description construit spécifiquement lors d'une lecture en mode rattrapage comme cela est expliqué ci-dessous.

On présente désormais, en relation avec la figure 4, une vue schématique d'un contenu principal Cl découpé en segments et stocké dans le serveur de contenus SRV. Plus précisément, le serveur de contenu HAS expose une vidéo Cl sous forme de segments Cli@Nj encodés à différents débits d'encodage Nj, où l'indice i désigne un identifiant temporel du segment Cli@Nj.

Le module de téléchargement HAS, appelé mode de téléchargement classique ci- dessous, du dispositif de lecture STB est chargé de venir récupérer les segments 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, 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 segment au débit d'encodage le plus faible proposé dans le fichier de description, 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 segment vidéo dure trois secondes, la récupération du segment par le module de téléchargement HAS ne doit pas excéder 3 secondes, afin de permettre une restitution sans interruption du contenu par le dispositif de lecture STB. 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 téléviseur TV.

Dans un premier temps, le module HAS récupère le fichier de description qui correspond au contenu vidéo Cl afin de découvrir les segments disponibles du contenu vidéo Cl, et les différentes qualités vidéo Nj associées. Dans l'exemple de la figure 4, le contenu Cl est par exemple proposé sous forme de segments de durée 3s, avec un premier débit d'encodage NI = 400 kb/s, un deuxième débit d'encodage N2 = 800 kb/s, un troisième débit d'encodage N3 = 1200 kb/s, etc.

Dans un mode de fonctionnement normal, non illustré sur la figure 4, 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 400 kb/s), puis C12@N3 (soit le deuxième segment temporel à un débit d'encodage de 1200 kb/s), puis C13@N3 (soit le troisième segment temporel à un débit d'encodage de 1200 kb/s), etc. Les différents segments téléchargés par le module de téléchargement HAS sont ensuite transmis à un module d'affichage AFF apte à requérir un affichage sur un écran du téléviseur TV.

L'algorithme mis en œuvre par le module de téléchargement HAS pour déterminer quel segment à quel débit d'encodage doit être téléchargé en mode de fonctionnement normal 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.

Il arrive parfois de manquer le début d'un programme télévisé (film, série, etc.). Une fonction appelée « lire du début » ou « rattrapage » (appelée également « Start Over » ou « Restart » par l'homme du métier) permet de reprendre, à tout moment, le programme en cours de diffusion un instant antérieur à l'instant courant ; par exemple la lecture du contenu peut être reprise depuis son commencement. Par exemple, si un film débute à 21h00 et si l'utilisateur zappe sur la chaine à 21h40, il peut demander à ce que la lecture du contenu reprenne depuis le début du film. Dans ce cas, on passe donc d'un mode de lecture à un contenu en temps réel (ou direct) à un mode de lecture à la demande.

Quand cet utilisateur accède à un flux Live diffusé en direct en http Adaptative Streaming (HAS), le dispositif de lecture STB, sous-entendu l'entité HAS installé sur ce dispositif, récupère en général toutes les 2 secondes un fichier de description qui décrit généralement les 60 dernières secondes du flux (30 segments de 2 secondes). On peut alors décider de bufferiser une certaine partie du flux (jusqu'à 60 secondes au maximum donc) ; les segments vidéos sont de courte durée car on souhaite être au plus proche du vrai Live. C'est également pour cette raison qu'on récupère le fichier de description toutes les 2 secondes et qu'on limite la profondeur de buffer en général autour de 15 secondes.

Dans l'état de la technique, quand on bascule en mode rattrapage (ou start over), le fichier de description qui est récupéré ne décrit plus les soixante dernières secondes mais une fenêtre temporelle bien supérieure aux soixante secondes. La fenêtre temporelle peut concerner les quatre dernières heures ; dans ce cas, si on peut relire le contenu depuis un instant situé dans la fenêtre temporelle. La taille du fichier de description est donc multipliée par deux cents quarante (240) et le temps de parsing du fichier XML devient un réel problème. En effet, il faut récupérer, comme lors de la lecture du flux Live, ce fichier de description de manière périodique toutes les 2 secondes et à chaque récupération parcourir (ou parser) l'ensemble du fichier de description qui comprend un nombre très important de balises décrivant des segments vidéo et audio.

Le procédé de l'invention comprend, au cours de la diffusion du contenu en temps réel, une étape de réception issue du dispositif de lecture d'une commande de réalisation d'un saut temporel dans le contenu pour lire le contenu à partir d'un instant antérieur à l'instant courant de lecture, l'étape de réception déclenchant une étape de transmission d'un deuxième fichier de description comprenant des adresses de segments à lire audit instant antérieur, complétées d'une partie des autres adresses de segments du contenu ayant été transmis.

On verra dans la suite que selon une variante, l'instant antérieur est sélectionné dans une fenêtre temporel donnée précédant l'instant courant. On verra aussi que la partie d'adresses est choisie dans cette fenêtre temporelle

En d'autres mots, lorsque la fonction de rattrapage est activée, l'entité de gestion ENT2 installée sur le serveur crée un fichier de description spécifique au mode de lecture en rattrapage comprenant non seulement des adresses de segments à lire correspondants à l'instant de lecture souhaité mais aussi une partie des autres adresses de segment du contenu ayant été transmis tout au long de la plage temporelle donnée par exemple les quatre dernières heures.

La taille du fichier de description ainsi créé est donc réduite car le fichier de description ne comprend pas toutes les adresses des segments de la plage temporelle considérée, c'est-à-dire des quatre heures passées, mais qu'une partie de ces adresses. Une fois le fichier de description reçu par le dispositif de lecture, la première entité ENT1 accède au fichier de description construit selon l'invention, et poursuit la lecture en mode rattrapage depuis l'instant de lecture spécifié au préalable à partir duquel une reprise de la lecture est souhaitée (par exemple 2hl7mn30sec dans le passé).

Selon un mode de réalisation, le serveur SRV va construire un fichier de description qui comprend

- Une première partie MNFm (m est un entier) incluant des adresses de segments à lire correspondants à l'instant de lecture souhaité ; cette parie décrit les 60 secondes de contenus correspondant à l'instant souhaité de lecture (entre 2hl8mn30sec et 2hl7mn30 sec) ; cette section est assimilable à un fichier de description reçu lors d'une lecture normale du contenu ;

- et au moins une deuxième partie (AD11/AD21 ; AD12/AD22).

La deuxième partie qui peut s'écrire ADli/AD2j (i et j étant des entiers) peut faire l'objet de variantes décrites ci-dessous.

Selon une première variante, la deuxième partie ADli inclut un ensemble d'adresses de segments associés aux soixante secondes de segments les plus anciens disponibles dans la fenêtre temporelle (ou plage temporelle) considérée ; dans notre exemple, cette partie ADli correspond aux segments qui ont été transmis il y a environ quatre heures environ. Cette variante permet de remonter dans le temps au maximum.

Selon une deuxième variante, la deuxième partie AD2j inclut un ensemble d'adresses de segments AD2 correspondant au flux diffusé en direct, soit dans notre exemple, les 60 secondes de segments vidéo les plus récents. La présence dans le deuxième fichier de description de cette deuxième partie AD2j est avantageuse car cette dernière permet un retour au direct sans délai.

Selon une troisième variante, la deuxième partie combine la première et la deuxième variante. Ici, le fichier de description créé spécifiquement pour le mode rattrapage comprend les adresses de segments à lire à l'instant sélectionné, et deux parties ADI et AD2 tels que décrits ci-dessus.

Comme la fenêtre temporelle permettant de lire le contenu en mode rattrapage est fixée dans notre exemple, chaque partie ADli/MNFn/AD2j est mise à jour lors de la lecture en mode rattrapage.

L'indice « n » désigne le fichier de description en cours de lecture ;

L'indice « i » désigne la i-ème mise à jour de la première partie ADI ;

L'indice « j » désigne le j-ième mise à jour de la partie AD2 ; m,i,j étant des entiers.

Un mode de réalisation du procédé de l'invention va maintenant être décrit en référence aux figures 5, 6 et 7.

Les figures 5 et 6 illustrent l'état de la lecture à deux instant distincts TA et TA' (TA'>TA), respectivement lors d'une phase de lecture en mode rattrapage. Sur les figures 5 et 6, le nombre de fichiers description utilisé est très limité de manière à exposer l'invention simplement.

Sur chaque figure 5 et 6, est représenté un premier axe temporel LIV correspondant à une lecture d'un contenu transmis en temps réel (ou direct) et un deuxième axe dédié au mode dit de rattrapage RTP.

Lors de la lecture du contenu en temps réel LIV, jusqu'à un instant courant TC, quatre fichiers de description MNF1-MNF4 sont reçus successivement par le dispositif de lecture STB.

En référence à la figure 5, on suppose qu'à l'instant courant TC, le mode « rattrapage » RTP, décrit ci-dessus, est activé et qu'un instant antérieur TA à l'instant courant (TA<TC) est sélectionné pour poursuivre la lecture en mode rattrapage. Un saut temporel (TC->TA), dans une fenêtre temporelle décrite en référence à la figure 7, est alors exécuté de manière à reprendre la lecture à cet instant antérieur TA.

Selon l'invention, suite à l'activation du mode rattrapage RTP décrit ci-dessus, à l'instant TC, la deuxième entité ENT2 présente sur le serveur crée un fichier de description AD11/MNF2/AD21, dit deuxième fichier de description, spécifique à ce mode de lecture dit de rattrapage qui comprend non seulement

- les adresses de segments à lire correspondant à l'instant TA comme pour la lecture du contenu en direct, soit 60 secondes de contenu,

- mais aussi au moins un autre ensemble d'adresses de segments, ici deux ensembles d'adresses AD11 et AD21 conformément à la troisième variante décrite ci-dessus.

Ce deuxième fichier de description spécifique au mode dit de rattrapage peut se noter ADli/MNFn/AD2j ; il est mis à jour au fil du temps avec un intervalle de temps similaire à celui qui est utilisé pour le flux transmis en direct.

La figure 6 illustre l'état de la lecture en mode rattrapage à un autre instant ultérieur TA' (TA'>TA). A cet instant TA', le serveur transmet un fichier de description AD12/MNF3/AD22.

Sur cette figure 6, on voit aussi que les fichiers de description liés au flux en direct continuent à être transmis en parallèle. Dans notre exemple, un fichier de description MNF5 a été transmis en liaison avec le direct. A chaque mise à jour, les adresses de segments à lire sont mis à jour ; les parties ADli et/ou AD2j selon la variante choisie sont également mis à jour pour respecter la fenêtre temporelle choisie de retour en arrière dans le contenu. Comme la fenêtre temporelle correspond à un intervalle de temps bornée, l'avancement de la lecture entraîne une modification des bornes de l'intervalle.

La figure 7 illustre la fenêtre temporelle FT liée au mode de lecture en rattrapage.

La fenêtre temporelle FT est très utile pour les contenus numériques dits « live », i.e. qui correspondent à des programmes télévisuels en temps réel ; en effet, ces contenus n'ont, par nature, pas de durée prédéfinie, ou de date de fin. Lorsque le mode de rattrapage est exécuté par exemple à l'instant TCI, un segment peut être sélectionné dans cette fenêtre FT ; de même, si le mode de rattrapage est exécuté par exemple à l'instant TC2, un segment peut être sélectionné dans cette fenêtre FT qui est décalée dans le temps d'une durée égale à TC2-TC1 (« - » est le signe mathématique correspondant à la soustraction).

La fenêtre temporelle est de préférence de durée fixe. Cependant, la durée de cette fenêtre temporelle peut varier selon le cas d'usage.

La figure 8 illustre un autre mode de réalisation illustrant la possibilité de revenir au direct après une phase en mode rattrapage.

Cette figure 8 comprend deux axes représentatifs d'un dispositif de lecture STB et du serveur de contenus CNT et des échanges de messages entre ces deux dispositifs.

Le procédé comprend une première phase LIV de lecture d'un contenu transmis en réel, une deuxième phase RTP de lecture du contenu en mode rattrapage et une troisième phase LIV de retour au temps réel.

Lors de la première phase LIV, le dispositif de lecture STB transmet une requête REQ1 d'accès à un contenu. En retour le serveur de contenu SRV transmet à intervalle régulier dans notre exemple des fichiers de description MNFl-MNFn par exemple toutes les 2 secondes.

A un instant donné, le mode rattrapage RTP est activé ACT. Un instant de lecture « TA » antérieur à l'instant courant « TC » (TA<TC) est sélectionné de manière à relire le contenu depuis l'instant de lecture sélectionné. On suppose que l'instant TA correspond à l'instant auquel a été transmis antérieurement le fichier de description MNF2 en liaison avec le contenu diffusé en temps réal.

Une donnée représentative de l'activation et l'instant de lecture TA sont transmis par le dispositif de lecture STB à destination du serveur et sont reçus par le serveur SRV. Ces données peuvent être véhiculées par le biais d'un même message ou deux messages distincts.

A réception de la donnée représentative d'une activation et de l'instant de lecture sélectionné TA qui correspond aux segments décrits dans le fichier de description MNF2, le serveur SRV créé un fichier de description spécifique AD11/MNF2/AD21 dit deuxième fichier de description. Le deuxième fichier de description est par exemple celui décrit en référence à la troisième variante décrite ci-dessus.

Pendant cette phase RTP, le serveur SRV transmet des mises à jour régulières des deuxièmes fichiers de description à savoir AD12/MNF2/AD22 et AD13/MNF2/AD23. Dans notre exemple, les mises à jour prennent en compte le déplacement temporel de la fenêtre temporelle fixée, quatre heures dans notre exemple ; par exemple la partie AD11 devient AD12 lors de la mise à jour puis AD22 et ainsi de suite.

Ensuite, on suppose qu'une adresse de segments est sélectionnée SEL(AD23) dans l'ensemble AD23 décrit ci-dessus inclut dans le deuxième fichier description. La sélection SEL est transmise par le dispositif de lecture STB au serveur SRV. Cette sélection entraîne une transmission automatique par le serveur SRV d'un premier fichier de description MNF10, à a place du deuxième ficher de description du type ADli/MNFn/AD2j, pour un retour au flux transmis en direct. Le serveur poursuit ensuite la transmission des premiers fichiers de description à savoir MNF11, etc. En d'autres mots, une sélection d'une adresse de segments dans le deuxième fichier de description correspondant à une adresse qui va être transmise par le serveur pour la lecture du flux diffusé en live est interprétée par le serveur comme une volonté de revenir au mode de lecture en temps réel à la place du mode de rattrapage.

On a vu précédemment en liaison avec la deuxième variante que le deuxième fichier de description peut comprendre deux parties d'adresses, l'une visant les segments les plus anciens, l'autre visant les plus récents à savoir les segments en cours de diffusion en temps réel. Ces deux parties et les instants des segments associés permettent de construire une barre de progression (ou timeline) afin de situer dans le temps l'instant de lecture courant et permettre une sélection d'un instant de lecture antérieur ou postérieur dans cette barre de progression et de poursuivre la lecture depuis l'instant sélectionné.

Précisons enfin ici aussi ici que le terme « 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.)