FR 3156001 A1 20250530 FR 2313226 A 20231129 TITRE : procédé de gestion de la relecture d’un contenu ayant été diffusé en temps réel. L’invention se rapporte à un procédé de gestion de l’accès, par un dispositif de lecture (STB), à des fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés hors du dispositif de lecture (STB), à être téléchargés via une liaison de communication et à être lus par le dispositif de lecture (STB), la lecture en temps réel requérant une réception, depuis la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’il comprend suite à une demande d’accès à un contenu, une réception à la fois des adresses de segments temps réel, et au moins une adresse réseau de fichier de description (ad-MNF(i),ad-MNF(i+1),…), dit fichier de rattrapage, décrivant d’autres segments que les segments temps réel. Figure pour l'abrégé : Figure 5 procédé de gestion de la relecture d’un contenu ayant été diffusé en temps réel. Le domaine de l'invention est celui de la gestion de la relecture d’un contenu ayant été diffusé en temps réel. L’invention se rapporte tout particulièrement à la gestion de l’accès aux fichiers de description lors d’une lecture en différée du contenu multimédia. 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 depuis 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. Précisions que les adresses de segments sont incluses dans un fichier de description. Un fichier de description dans le contexte d’un téléchargement progressif adaptatif est un fichier comprenant entre autres des adresses réseaux (adresse IP ou URL) des segments à télécharger et à lire par un dispositif de lecture. Autrement dit, un fichier de description décrit des segments sous forme d’adresses réseaux, à charge au dispositif de lecture d’accéder à ces segments via un réseau par exemple le réseau Internet. Le dispositif de lecture vise tous les dispositifs de traitement de données équipés de processeurs et capables d’accéder à des segments de contenus au travers d’un réseau, de recevoir les segments depuis un réseau, de décoder les segments reçus et de requérir une restitution des segments décodés par exemple sur un écran intégré au dispositif de lecture ou externe au dispositif de lecture. Etat de la technique Lors d’un accès à un contenu multimédia, un dispositif de lecture émet une requête à destination d’un serveur de contenus en indiquant le contenu multimédia (vidéo et/ou audio) choisi. Le dispositif de lecture reçoit en retour un flux de données numériques relatif à ce contenu. Dans le cadre d’un réseau de communication local, une telle requête peut transiter par une passerelle d’accès au réseau, par exemple une passerelle résidentielle. Les données reçues sont ensuite décodées par le dispositif de lecture, puis restituées sous la forme d’un affichage de la vidéo correspondante. 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 (en anglais HTTP Adaptative Streaming, d’abréviation HAS), des contenus numériques, aussi appelé « Streaming Adaptatif », permet de transporter et lire 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. Suite à la réception du flux, le dispositif de lecture stocke des données reçues 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 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 respectifs. Ces différentes qualités sont décrites dans un fichier de description, également appelé « Manifest » par l’homme du métier. Quand un utilisateur accède au flux Live diffusé en http Adaptative Streaming (HAS), le dispositif de lecture reçoit à intervalle régulier, en général toutes les deux secondes, des fichiers de description successivement, appelés ci-après fichiers de description temps réels, qui décrivent chacun généralement les soixante dernières secondes du flux (30 segments de 2 secondes) en fournissant des adresses IP (sigle anglosaxon de « Internet Protocol ») de segments correspondant à ces soixante dernières secondes. En général, les segments vidéo sont choisis de courte durée car on souhaite être au plus proche du flux diffusé en temps réel que l’homme du métier appelle aussi flux Live. A noter qu’un débit d’encodage est sélectionné parmi les débits disponibles en fonction de la bande passante disponible ou des capacités de stockage et de décodage du dispositif de lecture. Ce type de technique permet de tenir compte des variations de bande passante sur la liaison entre le dispositif de lecture client et le serveur de contenus. Outre la lecture de contenus, certains dispositifs de lecture offrent une fonction appelée « Start Over » par l’homme du métier (ou « rattrapage » ou « retour au début ») qui permet à un utilisateur qui regarde un contenu diffusé en temps réel (chaine Live) de relire une partie du contenu qui a été diffusé en Live ; cette fonction permet notamment de relire un contenu depuis son début. Par exemple, si un film diffusé en temps réal débute à 21h00 et si l’utilisateur accès au flux Live correspondant en zappant sur la chaine à 21h40, l’utilisateur peut demander, en sélectionnant une commande liée à la fonction dite de rattrapage, à ce que la lecture du contenu reprenne par exemple depuis le début du film. Dans ce cas, on passe d’un mode de lecture en temps réel à un mode de rattrapage. Dans ce mode de rattrapage, une interface de commandes offre la possibilité de sélectionner une voire plusieurs commandes qui modifient la lecture en cours du contenu diffusé en temps réel. Ces commandes permettent par exemple d’interrompre la lecture, ou de réaliser un saut temporel pour relire le contenu depuis un instant de lecture antérieur et donc de lire le contenu en différé. Lorsqu’un contenu est lu et que la fonction dite de rattrapage n’est pas proposée, dans ce cas les fichiers de description reçus successivement, appelés ci-après « fichiers de description temps réel », sont ceux décrits ci-dessus. Par contre, lorsque la fonction dite de rattrapage est disponible, le dispositif de lecture reçoit dès le début de la lecture du contenu des fichiers de description spécifiques successivement, appelés ci-dessous « fichiers de description de rattrapage », qui décrivent non pas les soixante dernières secondes mais une plage temporelle plus importante très souvent de plusieurs heures, par exemple les quatre dernières heures, de manière à pouvoir relire le contenu depuis un instant situé dans la fenêtre temporelle de quatre heures. En résumé, un fichier de description temps réel vise des segments à lire en temps réel ; un fichier de description de rattrapage vise des segments ayant été créés mais plus anciens, leur lecture transformant la lecture en temps réelle en lecture en différé. Un tel fichier de description de rattrapage décrivant par exemple les quatre dernières heures est deux cent quarante (240) fois plus volumineux qu’un fichier de description classique car il comprend toutes les adresses réseau de tous les segments créés depuis quatre heures. Concrètement, un fichier de description temps réel a une taille de l’ordre de 12ko (description de 30 segments de 2 secondes) et un fichier de description de rattrapage a une taille de l’ordre de 2.8Mo (description de 7200 segments de 2 secondes). Tout comme le fichier de description temps réel, le fichier de description de rattrapage est téléchargé de manière périodique par exemple toutes les deux secondes. Du fait de sa taille énorme, la transmission périodique du fichier de description de rattrapage requiert une bande passante énorme sur le réseau qui peut altérer la qualité de service lors de la restitution du contenu surtout pour des foyers équipés d’une ligne internet avec peu de débit tel qu’une ligne ADSL. En outre de tels fichiers de description de rattrapage requièrent des temps de traitement (que l’homme du métier appelle temps de parsing) trop importants pouvant altérer la lecture normale du contenu si la capacité de traitement du dispositif de lecture est peu performante. Il en résulte alors des gels d’image insupportables pour un utilisateur. Ces problèmes altèrent l’expérience utilisateur alors même que cet utilisateur n’a pas sélectionné de commande entraînant une relecture et qu’il n’a peut pas non plus l’intention de relire le contenu diffusé. L'invention vient améliorer la situation. L’invention A cet effet, selon un premier aspect fonctionnel, l’invention se rapporte à un procédé de gestion de l’accès, par un dispositif de lecture, à des fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés hors du dispositif de lecture, à être téléchargés via une liaison de communication et à être lus par le dispositif de lecture, la lecture en temps réel requérant une réception, depuis la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’il comprend suite à une demande d’accès à un contenu, une réception à la fois des adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments temps réel. Selon l’invention, suite à une demande d’accès au contenu en mode rattrapage, le dispositif de lecture reçoit un fichier de description comprenant des adresses réseau de fichier de description de rattrapage. L’utilisation d’adresses réseaux de fichier de description à la place des fichiers de description diminue la taille des données à transmette diminuant ainsi la bande passante occupée lors de la transmission de données relatives aux segments à lire en mode de rattrapage. De plus, la lecture d’une adresse est beaucoup plus rapide qu’un fichier de description ; le dispositif de lecture n’est donc pas ralenti lorsqu’il lit les fichiers de description reçu lors de la lecture du contenu en temps réel. Selon un mode de mise en œuvre particulier de l'invention, suite à la réception de plusieurs fichiers de rattrapage, le dispositif de lecture accède à un fichier de rattrapage dès qu’une commande d’accès à un segment concerne un segment décrit dans un fichier de rattrapage reçu. Le dispositif de lecture recevant un fichier de description incluant les adresses réseau des fichiers de rattrapage peut ainsi accéder à tout moment à un segment en mode différé. Selon encore un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, les segments temps réels et ladite au moins une adresse de fichier de rattrapage sont inclus dans un même fichier de description. Ce mode permet à l’entité chargée de créer les fichiers de description de simplifier la création en ne créant qu’un seul fichier incluant les segments associés à des fichiers de rattrapage et les segments temps réel. Selon un premier aspect matériel, l’invention se rapporte à une entité de gestion de l’accès, par un dispositif de lecture, à des fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés hors du dispositif de lecture, à être téléchargés via une liaison de communication et à être lus par le dispositif de lecture, la lecture en temps réel requérant une réception, depuis un réseau de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’elle comprend un processeur configuré pour réaliser, suite à une demande d’accès à un contenu, une réception à la fois d’adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. Selon un autre aspect matériel, l’invention se rapporte à un dispositif de lecture 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. Selon un deuxième aspect fonctionnel, l’invention se rapporte à un procédé de gestion de la transmission de fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés et à être transmis via une liaison de communication à destination d’un dispositif de lecture, la lecture en temps réel sur le dispositif de lecture requérant une transmission, via la liaison de communication, d’adresses réseau des derniers segments créés dits segments temps réels, caractérisé ce qu’il comprend suite à une demande d’accès à un contenu, une transmission à la fois des adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. On verra dans la suite qu’un fichier de description de rattrapage peut être transmis seul ou simultanément avec un fichier de description temps réel. Selon un mode de réalisation particulier de la deuxième entité, le fichier de description de rattrapage est transmis après une durée donnée. Selon un mode de réalisation particulier de la deuxième entité, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le fichier de description de rattrapage est transmis après un nombre donné de transmission de fichiers de description temps réel. Les deux modes qui précèdent couvrent le fait que le fichier de description de rattrapage n’est pas forcément le premier fichier de description transmis suite à la réception de la requête d’accès au contenu en cours de diffusion ; au contraire, le fichier de description de rattrapage est transmis plus tard, soit après une durée donnée, soit après un nombre donné de fichier de description temps réel transmis. Ces deux modes partent du principe qu’un utilisateur accédant au contenu ne requiert pas en général une relecture dans les premières minutes. La durée donnée ou le nombre donné visés ci-dessus seront d’ailleurs choisis judicieusement pour prendre en compte ce temps qu’un utilisateur prend avant de relire un contenu. Selon un autre aspect matériel, l’invention se rapporte à une entité de gestion de la transmission de fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés et à être transmis via une liaison de communication à destination d’un dispositif de lecture, la lecture en temps réel sur le dispositif de lecture requérant une transmission, via la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’elle comprend un processeur configuré pour réaliser, suite à une demande d’accès à un contenu, une transmission à la fois d’adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. Selon un autre aspect matériel, l’invention se rapporte à un serveur de contenus comprenant une deuxième entité telle que définie ci-dessus. Selon un autre aspect matériel, l’invention se rapporte à un programme d'ordinateur apte à être mis en œuvre sur une deuxième 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é définies en liaison avec le deuxième aspect fonctionnel. Enfin, selon un autre aspect matériel, l’invention se rapporte à 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 de la transmission de fichiers de description. Les supports visés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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, un 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 un mode de réalisation du procédé de l’invention ; cette figure illustre la communication entre le dispositif de lecture et le serveur de contenus ; cette figure fait apparaître une transmission d’adresses de fichiers de rattrapage. Description détaillée de modes de réalisation de l'invention La FIG. 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 SYS 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 tel qu’un décodeur. 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 dits Live c’est-à-dire diffusés en temps réel. Dans notre exemple, 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. On verra dans la suite que le dispositif de lecture STB comprend une première entité de gestion ENT1. La passerelle GTW est apte à communiquer via une liaison de communication LI1 qui peut être un réseau de télécommunication 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 FIG. 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 C1 sont mis à disposition en mode unicast dans un format donné. Un tel contenu C1 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. Un exemple de fichier de description ou « 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é en Annexe 1. Ce fichier de description 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 segments classiquement décrits entre une balise ouvrante ( ) et une balise fermante ( ). La découpe en segments permet notamment de s’adapter finement aux fluctuations de la bande passante. Chaque segment 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 segments : - « 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. La FIG. 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 deuxième entité de gestion, apte à gérer la transmission d’un contenu et du fichier de description associés au contenu depuis le serveur SRV à destination d’un ou plusieurs dispositifs de lecture, ici vers le dispositif de lecture STB. 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 FIG. 3 . On s’intéressera essentiellement dans la suite à la transmission du fichier de description plutôt que de la transmission des segments. La FIG. 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é COM11 sur la FIG. 2 . Le dispositif de lecture STB comprend un module de téléchargement en mode streaming HAS (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. Le module de téléchargement HAS et la première entité ENT1 peuvent ne former qu’une seule entité auquel cas le module HAS est intégré à la première entité ENT1 ou être séparées l’une de l’autre. On présente désormais, en relation avec la FIG. 4 , une vue schématique d’un contenu principal C1 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 C1 sous forme de segments C1i@Nj encodés à différents débits d’encodage Nj, où l’indice i désigne un identifiant temporel du segment C1i@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. On rappelle 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 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 FIG. 4 , le contenu C1 est par exemple proposé sous forme de segments de durée 3s, avec un premier débit d’encodage N1 = 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 FIG. 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 apte à requérir un affichage sur le 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.) diffusé en temps réel. 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 à un mode de lecture en différé. Quand cet utilisateur accède à un flux Live diffusé en temps réel (contenu Live) 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, ci-après appelé fichier de description temps réel, qui décrit généralement les soixante dernières secondes du flux (30 segments de 2 secondes). On peut alors décider de stocker en mémoire (buffer) une certaine partie du flux (jusqu’à 60 secondes au maximum donc) ; les segments vidéo sont de courte durée car on souhaite être au plus proche du vrai Live c’est-à-dire de l’événement filmé, par exemple un match de Football. 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 afin de ne pas engendrer un décalage trop important entre le match de Football et sa restitution sur un écran. Une interface de commandes (les symboles le plus souvent présents sur une télécommande sont « > » pour l’avance rapide et « II » pour la commande Pause) permet d’agir sur la lecture courante du contenu Live. Des commandes en particulier permettent d’activer le mode rattrapage (ou start over). De manière à assurer une exécution d’une commande de l’interface de commandes, par exemple la commande de retour en arrière Dans la suite, on appellera « Fichier temps réel » le fichier de description, décrivant les derniers segments produits sur le serveur en liaison avec la lecture en temps réel du contenu. On appellera aussi « fichier de rattrapage » les fichiers de description décrivant des segments ayant déjà été diffusés et permettant de relire des segments en différé. Selon l’invention, lorsqu’un accès est demandé au contenu, le serveur transmet en retour un fichier de description courant incluant à la fois les adresses réseau des segments à lire liés à la diffusion en temps réel du contenu et des adresses réseau de fichiers de description de rattrapage décrivant des segments ayant été créés avant la demande d’accès permettant de lire le contenu en différé. Les adresses réseau des segments liés au rattrapage ne sont pas incluses dans le fichier de description courant ; Le fichier de description transmis au dispositif de lecture STB inclut des adresses de fichiers de description de rattrapage. Charge à la première entité ENT1 de télécharger ces fichiers de rattrapage par la suite et d’accéder aux segments grâce aux adresses réseau incluses dans les fichiers de description de rattrapage lorsqu’une lecture en mode rattrapage est souhaitée par la suite. La FIG. 5 illustre un mode de réalisation du procédé de l’invention. Sur cette FIG. 5 , sont représentés deux axes verticaux correspondants respectivement à deux entités à savoir la première entité ENT1 présente sur le dispositif de lecture STB et la deuxième entité ENT2 présente sur le serveur SRV. La FIG. 5 illustre les échanges de données qui ont lieu entre le dispositif de lecture STB et le serveur de contenu SRV. Précisons ici que des commandes sont disponibles via une interface de commandes (non représentée sur les figures) tout au long de la lecture. On y trouve des commandes telles que une commande de retour « une commande Pause « II » une commande d’avance rapide « >> « (cette commande ne peut être utilisée que lorsque la lecture est déjà en différée) A noter que sur cette FIG. 5 , seule une partie des messages utiles à la compréhension de l’invention sont illustrés. Par exemple, après réception d’un fichier de description par le dispositif de lecture STB, ce dernier requiert en principe un accès aux segments décrits dans ce fichier de description reçu ; nous avons choisi de ne pas faire apparaître ces messages d’accès car sans intérêt pour l’exposé de l’invention. L’exécution des commandes données à titre d’exemple ci-dessus entraîne une lecture différée du contenu Live en cours de diffusion. L’interface peut bien sûr comprendre d’autres commandes n’ayant pas un tel impact sur la lecture courante ; une telle commande est par exemple une commande d’affichage d’informations sur le contenu en cours de lecture. Les commandes dont l’exécution entraîne une relecture en différé du contenu depuis un instant de lecture choisi nécessitent une description de segments ayant été diffusés dans le passé ; un fichier de description temps réel qui ne décrit que les derniers segments produits liés à la diffusion en temps réel n’est donc pas suffisant ; la première entité ENT1 va donc se charger de récupérer au moins un fichier de description de rattrapage pour pouvoir exécuter une commande correctement. Pour ce faire, la première entité ENT1, lorsqu’elle reçoit un fichier de description incluant des adresses réseau de fichier de description de rattrapage, réalise les étapes suivantes : - la première entité ENT1 parcourt le dernier fichier de description courant reçu MNFtr, - la première entité ENT1 identifie l’adresse du fichier de description de rattrapage qui inclut une description des segments qui correspond à l’instant de la lecture choisie pour la lecture en différé, - la première entité ENT1 requiert, grâce aux adresses réseaux des fichiers de rattrapage, un téléchargement du ou des fichiers de description de rattrapage - la première entité ENT1 reçoit en retour le ou les fichiers de rattrapage, - et la première entité ENT1 télécharge ensuite les segments de contenu concernés à la base des fichiers de rattrapage décrivant les adresses réseau des segments. Les étapes d’un mode de réalisation sont les suivantes ; on suppose ici que l’interface de commandes comprend au moins une commande entraînant une lecture différée et requérant donc des fichiers de description de rattrapage ; on suppose également que l’utilisateur accède à une chaîne « Live » à 10h et que le programme en question à commencer à 9h donc depuis une heure. Jusqu’à réception de la demande d’accès ACC par le serveur SRV émise depuis le dispositif de lecture STB à un instant tc, en référence à la FIG. 5 , plusieurs fichiers de description à savoir dans notre les exemple : MNF1,MNF2, …, MNF(i), MNF(i+1),…, MNFtr (l’indice « tr » faisant référence à un fichier de description temps réel) sont créés en liaison avec des segments de contenus et accessibles depuis des adresses réseau ad-MNF1,ad-MNF2, …, ad-MNF(i), ad-MNF(i+1),…, respectivement ; les fichiers de description visant des segments ayant déjà été créés dans la plage temporelle de quatre heures T précédant l’instant courant tc seront référencés MNFT sur la figure. Lors d’une première étape, à l’instant tc, la première entité ENT1 requiert un accès R-ACC à un contenu multimédia. Lors d’une deuxième étape, le serveur SRV et donc la deuxième entité ENT2 reçoit la requête d’accès R-ACC. Lors d’une troisième étape, selon un mode de réalisation, la deuxième entité ENT2 requiert la transmission d’un fichier de description incluant à la fois des adresses réseaux ad-MNF(i), ad-MNF(i+1),…, de fichiers de description MNFi, MNF(i+1), etc. respectifs incluant une description des segments diffusés dans la fenêtre temporelle T précédant l’instant tc, soit depuis quatre heures ; ces fichiers sont appelés fichiers de description de rattrapage dans la suite ; ainsi que le descriptif des derniers segments MNFtr, dits segments temps réels, produits par le serveur voués à être lus par le dispositif de lecture STB en liaison avec le contenu. Selon l’invention, la description de segments des fichiers de rattrapage créés depuis une durée T, quatre heures dans notre exemple, sont donc fournis sous forme d’adresses réseau (Par exemple des URLs) afin de diminuer la taille des fichiers de description transmis successivement. Selon une variante possible de l’invention, deux fichiers de description pourraient être transmis séparément ; un premier comprenant les fichiers de rattrapage à savoir les adresses de fichiers de description de rattrapage (MNF(i),MNF(i+1), …) jusqu’au dernier fichier de rattrapage créé qui précède le fichier temps réel MNFtr ; et un second comprenant le dernier fichier de description MNFtr incluant les derniers segments créés liés à la lecture en temps réel. Le serveur SRV crée, dans notre exemple toutes les 2 secondes, un fichier de description à savoir MNF(i) à l’instant ti MNF(i+1) à l’instant ti + 2 sec. Etc. Supposons qu’à un instant donné tacc, l’utilisateur accède au contenu. Le dispositif de lecture STB reçoit en retour des fichiers de description tels que définis ci-dessus à savoir un fichier de description incluant des adresses de fichiers de description de rattrape et des segments temps réels. En supposant que l’instant ti correspond à quatre heures précédant l’instant tacc, le dispositif de lecture STB reçoit successivement les fichiers de description suivants : Ad-MNF(i),…,MNFtr à l’instant t(i) Ad-MNF(i+1),…,MNFtr à l’instant t(i+1) soit deux secondes plus tard dans notre exemple Ad-MNF(i+2),…,MNFtr à l’instant t(i+2) soit quatre secondes plus tard dans notre exemple Et ainsi de suite. A ce stade, le dispositif de lecture STB peut requérir une relecture grâce aux adresses de fichiers de rattrapage inclusent dans le fichier de description reçu. A noter que les fichiers de description temps réel MNFtr reçus successivement sont différents. Cependant, pour des raisons de simplification de l’exposé, ces derniers sont toujours référencés MNFtr dans le présent texte. En référence à la FIG. 5 , on suppose qu’à un instant « tr », un utilisateur sélectionne la commande retour en arrière « La première entité ENT1 reçoit la commande et requiert son exécution par le processeur. A ce stade, la première entité ENT1 a connaissance de l’instant lié à la relecture et détermine l’adresse Ad-MNF(j) du fichier de description de rattrapage concerné MNF(j) parmi les adresses de fichiers de description de rattrapage reçues qui sont nécessaires à la relecture du contenu depuis cet instant. Une fois l’adresse du fichier de rattrapage identifié, la première entité ENT1 requiert auprès du serveur SRV un téléchargement du fichier de rattrapage MNF(j) ; pour cela la première entité ENT1 inclut l’adresse ad-MNF(j) dans la requête. Le serveur reçoit l’adresse ad-MNF(j), et télécharge le fichier de rattrapage MNF(j) correspondant. Dans notre exemple, le serveur transmet aussi tout ou partie de fichiers de rattrapage suivants MNF(j+1), etc. La transmission peut être réalisée indifféremment fichier de rattrapage par fichier de rattrapage les uns après les autres, ou par groupe de fichiers de rattrapage. Suite à la réception du fichier de rattrapage MNF(j), la première entité peut accéder aux segments grâce aux adresses réseau incluses dans le fichier. A ce stade, la première entité ENT reçoit les segments et gère la restitution de ces segments ; la première entité ENT1 requiert au module de téléchargement HAS un téléchargement des fichiers de description successivement et accède aux segments. La lecture s’effectue à ce stade en différé par rapport à la diffusion en temps réel qui se poursuit. Le téléchargement des fichiers de rattrapage se poursuit ensuite de la même manière tant qu’une commande d’arrêt de la lecture en différé n’est pas reçue. 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.). Procédé de gestion de l’accès, par un dispositif de lecture (STB), à des fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés hors du dispositif de lecture (STB), à être téléchargés via une liaison de communication (LI1) et à être lus par le dispositif de lecture (STB), la lecture en temps réel requérant une réception, depuis la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’il comprend suite à une demande d’accès à un contenu, une réception à la fois des adresses de segments temps réel, et au moins une adresse réseau de fichier de description (ad-MNF(i),ad-MNF(i+1),…), dit fichier de rattrapage, décrivant d’autres segments que les segments temps réel. Procédé de gestion selon la revendication 1, caractérisé en ce que, suite à la réception de plusieurs fichiers de rattrapage, le dispositif de lecture accède à un fichier de rattrapage dès qu’une commande d’accès à un segments concerne un segment décrit dans un fichier de rattrapage reçu. Procédé de gestion selon la revendication 1, caractérisé en ce que les segments temps réels et ladite au moins une adresse de fichier de rattrapage sont inclus dans un même fichier de description. Entité de gestion (ENT1) de l’accès, par un dispositif de lecture (STB), à des fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés hors du dispositif de lecture (STB), à être téléchargés via une liaison de communication et à être lus par le dispositif de lecture (STB), la lecture en temps réel requérant une réception, depuis la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’elle comprend un processeur configuré pour réaliser, suite à une demande d’accès à un contenu, une réception à la fois d’adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. Dispositif de lecture (STB) comprenant une entité de gestion (ENT1) telle que définie dans la revendication 4. Programme d'ordinateur apte à être mis en œuvre sur une entité de gestion (ENT1) telle que définie dans la revendication 4, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé définies dans la revendication 1. 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é selon la revendication 1. Procédé de gestion de la transmission de fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés et à être transmis via une liaison de communication à destination d’un dispositif de lecture (STB), la lecture en temps réel sur le dispositif de lecture requérant une transmission, via la liaison de communication, d’adresses réseau des derniers segments créés dits segments temps réels, caractérisé ce qu’il comprend suite à une demande d’accès à un contenu, une transmission à la fois des adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. Entité de gestion (ENT2) de la transmission de fichiers de description associés à un contenu diffusé en temps réel, les fichiers de description comprenant des adresses d’accès à des segments aptes à être créés et à être transmis via une liaison de communication à destination d’un dispositif de lecture (STB), la lecture en temps réel sur le dispositif de lecture requérant une transmission, via la liaison de communication, d’adresses réseau des derniers segments créés, dits segments temps réels, caractérisé ce qu’elle comprend un processeur configuré pour réaliser, suite à une demande d’accès à un contenu, une transmission à la fois d’adresses de segments temps réel, et au moins une adresse réseau de fichier de description, dit fichier de rattrapage, décrivant d’autres segments que les segments dits temps réel. Serveur de contenus (SRV) caractérisé en ce qu’il comprend une entité (ENT2) telle que définie dans la revendication 9. Programme d'ordinateur apte à être mis en œuvre sur une entité de gestion (ENT) telle que définie dans la revendication 9, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé définies dans la revendication 8. 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é selon la revendication 8.