FR 3114719 A1 20220401 FR 2009874 A 20200929 Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution L’invention se rapporte à un procédé de gestion de la lecture d’un contenu numérique (C1) téléchargé depuis un serveur de contenu (SRV) via un réseau de communication, le contenu comprenant plusieurs segments, caractérisé en ce qu’il comprend les étapes suivantes : Une étape préalable d’obtention d’un historique de la variation de la bande passante qui a été disponible sur le réseau sur une période de temps passée; Une étape de réception de segments du contenu téléchargé et de stockage des segments reçus dans une mémoire tampon ; Une étape de détermination d’un instant de démarrage de la lecture des données reçues basée sur l’historique de la variation de la bande passante obtenu lors de l’étape préalable. Figure 1 Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution Le domaine de l'invention est celui des contenus multimédias numériques, à savoir les contenus audio et/ou vidéo numériques. Plus précisément, l'invention se rapporte à un procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution. Le dispositif de restitution est un dispositif capable de restituer des contenus multimédias. Ce dispositif de restitution dispose d’au moins deux sources de données. Une source de données vise un dispositif capable de fournir un contenu pour être restituer sur le terminal de restitution. Le terminal lecteur de contenus est une source de données. D’autres sources de données sont par exemple une console de jeu, un disque dur, un ordinateur, etc. Une source de données peut être connectée au dispositif de restitution via un port tel qu’un port connexion HDMI, un port USB, etc. On verra dans un exemple de réalisation décrit ci-dessous que le terminal lecteur de contenus multimédias choisi pour illustrer l’invention est un décodeur de télévision numérique (set top box en anglais) ; Le décodeur visé ici est capable de requérir un accès à un contenu ayant plusieurs qualités disponibles. De tels contenus sont par exemple des contenus utilisés dans un contexte de téléchargement adaptatif progressif (HAS) dans lesquels les contenus sont découpés en segments, chaque segment étant disponible selon plusieurs débits d’encodage associés à des qualités de restitution respectives. Etat de la technique L’accès à un contenu multimédia, tel que la télévision ou la vidéo à la demande, depuis un réseau de type Internet, est possible aujourd’hui, pour la plupart des terminaux de lecture de contenus multimédias. Le terminal de lecture, par exemple un décodeur, émet généralement une requête à destination d’un serveur en indiquant un contenu multimédia choisi. Le décodeur reçoit en retour le contenu multimédia demandé. Dans le cadre d’un réseau de communication local, une telle requête transite par une passerelle d’accès au réseau, par exemple une passerelle résidentielle/domestique. Le terminal de lecture est adapté pour recevoir ces contenus numériques sous forme de données multimédia et pour requérir une restitution sur un dispositif de restitution. Cette restitution consiste à fournir au niveau du terminal de lecture le contenu numérique au terminal de restitution sous une forme accessible à l’utilisateur. Par exemple, des données reçues correspondant à une vidéo sont généralement décodées par le dispositif de lecture de contenus, puis restituées au niveau du terminal de restitution sous la forme d’un affichage de la vidéo correspondante avec sa bande-son associée. Dans la suite, par souci de simplification, on assimilera le contenu numérique à une vidéo et la restitution par le terminal, ou consommation par l’utilisateur du terminal, à une visualisation sur l’écran du terminal. La diffusion de contenus numériques 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 décodées par le terminal de lecture 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 commander la restitution au terminal de restitution. 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 d’images 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, par exemple un serveur de contenus. Quand le terminal de lecture de contenus souhaite accéder à un contenu, ce fichier de description permet de sélectionner une qualité d’image 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 de lecture 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 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 contenus 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 présentations de qualité et débits d’encodage 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 au moyen d'un protocole d'échange. Le protocole principalement ciblé est le protocole HTTP, mais d'autres protocoles (par exemple FTP) peuvent également être utilisés. L'organisation des segments et les paramètres associés sont publiés dans un manifeste au format XML. Le principe sous-jacent à cette norme est que le client MPEG-DASH effectue une estimation de la bande passante disponible pour la réception des segments, et, en fonction du remplissage de son tampon de réception, choisit, pour le prochain segment à charger, une représentation dont le débit d’encodage assure la meilleure qualité d’image possible, et permet un délai de réception compatible avec la restitution ininterrompue du contenu sur un dispositif de restitution. Ainsi, pour s’adapter à la variation des conditions réseau, notamment en termes de bande passante, les solutions existantes de téléchargement adaptatif permettent au terminal de lecture de passer d’une version du contenu encodée à un certain débit, à une autre encodée à un autre débit, au cours du téléchargement. En effet, chaque version du contenu est divisée en segments de même durée. Pour permettre une restitution en continu du contenu sur le terminal, chaque segment doit atteindre le terminal de lecture avant son instant programmé de restitution. La qualité perçue associée à un segment augmente avec la taille du segment, exprimée en bits, mais dans le même temps, des segments plus gros requièrent un temps de transmission plus important, et donc présentent un risque accru de ne pas être reçus à temps pour une restitution en continu du contenu. Le terminal de lecture doit donc trouver un compromis entre la qualité globale du contenu, et sa restitution ininterrompue, en sélectionnant avec soin le prochain segment à télécharger, parmi les différents débits d’encodage proposés. Il existe pour ce faire différents algorithmes de sélection de la qualité du contenu en fonction de la bande passante disponible, qui peuvent présenter des stratégies plus ou moins agressives, ou plus ou moins sécuritaires. La consommation de contenus numériques en téléchargement progressif adaptatif (HAS) tend à se démocratiser. Elle est notamment utilisée par de nombreux services de streaming (en français, diffusion en mode continu, ou lecture en continu), mais également par certains décodeurs TV, ou set-top-box, qui l’utilisent pour accéder à des contenus délinéarisés, tels que la vidéo à la demande (VOD), la diffusion en différé de programmes télévisuels (Replay), ou encore les offres de type Network PVR (pour « Network Personal Video Recorder », i.e. un service d’enregistrement des contenus numériques, effectué par le fournisseur de contenus lui-même plutôt qu’au domicile de l’utilisateur final). En outre, d’autres dispositifs tels que des appareils lecteurs de contenus multimédias en temps réel accèdent également aux contenus numériques en mode de téléchargement adaptatif progressif pour des contenus télévisuels en temps réel (ou Live). C’est le cas par exemple de l’appareil Chromecast® développé par Google®, ou de la CléTV® d’Orange®. De tels appareils se branchent classiquement sur le port HDMI d’un téléviseur et constitue une source de données pour le téléviseur. Ces appareils communiquent, par connexion Wi-Fi®, avec un autre appareil du réseau de communication domestique connecté à un réseau de communication étendu de type Internet (passerelle résidentielle, ordinateur, téléphone intelligent de type smartphone, tablette…), afin de restituer, sur le dispositif de restitution, en l’espèce un téléviseur, le contenu multimédia reçu par une application logicielle compatible. On désignera par la suite ces appareils sous la désignation générique de Clef HDMI. De tels appareils peuvent également être utilisés pour accéder à des contenus de type vidéo à la demande, ou pour restituer sur le téléviseur des contenus personnels stockés dans le réseau domestique, tels qu’une vidéo des dernières vacances ou du dernier événement familial. Dans un réseau local, plusieurs dispositifs se partagent la bande passante disponible de manière plus ou moins équitable. Il en résulte une part importante d’utilisateurs (environ 10 à 15%) qui ont régulièrement des problèmes de lecture de contenu sur des flux Live car la bande passante dont ils disposent est limitée et est utilisée par d’autres services (Youtube, Netflix, IPTV, téléchargement, …). En conséquence, lors de la lecture d’un contenu, si la bande passante diminue fortement, le terminal client n’a pas le temps de s’adapter et la lecture du contenu se dégrade quelques secondes avant de pouvoir basculer sur des segments de moindre qualité. Une dégradation est une pixellisation de l’image ou une image noire sur l’écran. L’invention vient améliorer la situation. A cet effet, selon un aspect fonctionnel, l'invention a trait à un procédé de gestion de la lecture d’un contenu numérique téléchargé depuis un serveur de contenu via un réseau de communication le contenu comprenant plusieurs segments, caractérisé en ce qu’il comprend les étapes suivantes Une étape préalable d’obtention d’un historique de la variation de la bande passante qui a été disponible sur le réseau sur une période de temps passée ; Une étape de réception de segments du contenu téléchargé et de stockage des segments reçus dans une mémoire tampon ; Une étape de détermination d’un instant de démarrage de la lecture des données reçues basée sur l’historique de la variation de la bande passante obtenu lors de l’étape préalable. La solution s’applique à tout type de contenus téléchargeables, notamment des contenus téléchargeables sous forme de segments associés à différents débits d’encodage respectifs comme cela sera expliqué ci-dessous. La connaissance de l’historique de la bande passante qui a été disponible sur une période passée permet d’estimer la bande passante future. En effet, on constate qu’au sein d’un même foyer, des habitudes d’accès à des contenus se répètent périodiquement et ces habitudes rendent pertinents l’accès à l’historique du foyer. L’invention permet de télécharger une partie suffisante du contenu dans la mémoire tampon de telle manière à assurer une restitution du contenu en continu sans dégradation de la qualité de la restitution. L’invention évite en particulier une pixellisation des images voire une restitution d’un écran noir quelques secondes. La solution intéresse particulièrement les contenus « live ». En effet, à la différence des contenus à la demande (replay, NPVR (sigle anglo-saxon de « Network Personnal Video Recorder » ou VOD (sigle anglo-saxon de « video on Demand »), les contenus « live » ou « flux Live » imposent de ne pas stocker trop de segments dans la mémoire tampon du terminal client afin de ne pas introduire trop d’écarts de temps entre le flux live, par exemple une émission en directe (ex : compétition sportive), et ce qui est restitué à l’écran. L’invention offre ainsi un bon équilibre entre la profondeur de stockage de la mémoire tampon tout en assurant le plus faible possible le décalage temporel entre le contenu Live, par exemple une émission diffusée en direct et ce qui est restitué à l’écran. Selon un premier mode de mise en œuvre particulier de l'invention, le contenu comprend plusieurs segments associés à plusieurs débits d’encodage respectifs. Dans cette configuration, le procédé comprend une réception de données de segments et de stockage des segments reçus dans la mémoire tampon ; suivie d’une étape de calcul d’une durée de téléchargement estimée du contenu restant à télécharger en prenant compte une bande passante issue de l’historique, une durée de lecture du contenu et un débit d’encodage choisi parmi les débits d’encodage disponibles, l’instant de démarrage étant choisi de telle sorte que la durée de téléchargement estimée du contenu restant à télécharger est inférieure ou égale à la durée du contenu à lire. Ce premier mode vise les contenus accessibles sous forme de segments, chaque segment étant disponible à différents débits d’encodage. Le débit d’encodage choisi peut être l’un des débits disponible. 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, le débit d’encodage choisi parmi les débits d’encodage disponibles est le débit d’encodage maximum disponible. Dans ce deuxième mode, le débit d’encodage choisi est le débit le plus important en kb/s. De cette manière, comme le débit d’encodage sectionné réellement par le terminal de lecture varie, et qu’il plafonne rarement sur la valeur maximum du débit d’encodage, le calcul de la durée de téléchargement du contenu restant calculé sur la base d’un débit d’encodage maximum représente une durée maximum. Cette durée maximum est ensuite comparée à la durée de lecture du contenu. Il résulte de ces calculs un instant de démarra qui garantit un téléchargement de la partie restante à télécharger avant la fin de la lecture du contenu. La lecture s’effectue dans ce cas assurément sans dégradation. 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 modes, le débit réseau estimé est le débit réseau moyen calculé sur la période passée donnée. Ce troisième mode offre un calcul simple de débit ; Il requiert donc peu de ressources physiques et/ou logicielles dans le terminal de lecture de flux. Une variation de la bande passante vise une augmentation ou une diminution de la bande passante. 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 modes, des instants de démarrage distincts sont prédéfinis respectivement. Ce quatrième mode se base uniquement sur l’historique pour déterminer l’instant de démarrage et ne nécessite pas d’obtenir la durée de lecture du contenu et la sélection d’un débit d’encodage. Ce mode requiert donc, comme le précédent mode, peu de ressources physiques et/ou logicielles dans le terminal de lecture de flux. Selon un aspect matériel, l’invention se rapporte à une entité de gestion de la lecture d’un contenu numérique téléchargé depuis un serveur de contenu via un réseau de communication, le contenu comprenant plusieurs segments accessibles depuis un serveur de contenus, caractérisé en ce qu’il comprend Un module d’obtention apte à obtenir un historique de la variation de la bande passante qui a été disponible sur le réseau sur une période de temps passée ; Un module de réception apte à recevoir les segments du contenu téléchargé et de stockage des segments reçus dans une mémoire tampon ; Un module de détermination apte à déterminer un instant de démarrage de la lecture des données reçues basée sur l’historique de la variation de la bande passante obtenu lors de l’étape préalable. Selon un autre aspect matériel, l’invention se rapporte à un terminal lecteur de contenus multimédias comprenant une 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 un terminal lecteur de contenus multimédias, 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 le procédé défini ci-dessus. 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é tel que défini ci-dessus. 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 mémoire RAM, une mémoire ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique tel qu’un 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. Enfin, signalons 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.). 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 : La figure 1 représente une architecture de téléchargement progressif sur Internet basée sur l’utilisation du streaming adaptatif selon l’invention ; La figure 2 illustre de façon schématique la structure matérielle d’un terminal lecteur de flux multimédia en temps réel intégrant une entité de gestion selon un mode de réalisation de l’invention; La figure 3 présente les principaux éléments du terminal lecteur ainsi qu’une vue schématique des différents segments d’un contenu principal ; La figure 4 présente un historique de la bande passante sur une période passée donnée sur lequel le calcul de l’instant de lecture du contenu se basera. La figure 5 présente une vue des échanges de données entre le serveur de contenus et la clé selon un mode de réalisation de l’invention. Description détaillée de modes de réalisation de l'invention. On présente désormais, en relation avec la figure 1, 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 lecteur de flux multimédia CLTV, par exemple une clé HDMI connectée à un terminal de restitution TV tel qu’un téléviseur. Dans notre exemple, le terminal CLTV est connecté sur un port du téléviseur TV et est donc une source de données pour le téléviseur TV. Dans notre exemple, le terminal CLTV 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 RES tel qu’un réseau étendu WAN connu de l’homme du métier. Un serveur de contenus numériques SRV se trouve selon cet exemple dans le réseau étendu WAN mais il pourrait indifféremment être situé dans le réseau local LAN, par exemple dans la passerelle domestique GTW ou tout autre équipement capable d’héberger un tel serveur de contenus. 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. Dans notre exemple, le terminal de lecture CLTV 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.). Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre le terminal client CLTV et le serveur 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 CLTV et la passerelle de services GTW, et/ou entre cette dernière et le serveur de contenus SRV. Classiquement, comme on le verra en référence à la figure 3, 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 (URI : Universal Ressource Identifier). 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 « manifest 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 CLTV peut adapter ses requêtes pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui lui correspond au mieux. Dans notre exemple, les contenus sont disponibles, du plus faible au plus fort, aux débits 416 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté (N1), 680 kb/s (N2), 1200 kb/s (N3) ; dans cette configuration, si le terminal client CLTV dispose d’une bande passante de 5000 kb/s, il peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 1200 kb/s. De manière générale, on note « Ci@Nj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description). Le nombre de débits d’encodage disponibles par segment varie selon le terminal de lecture utilité. Sur la figure 3, le contenu C1 comprend six débits d’encodage par segment à savoir, du plus faible au plus fort, 416 kb/s, 680 kb/s, 1200 kb/s, 1600 kb/s, 2100 kb/s et 5000 kb/s. La passerelle de service GTW est dans cet exemple une passerelle domestique qui assure le routage des données entre le réseau étendu WAN et le réseau local LAN, gère les contenus numériques en assurant notamment leur réception en provenance du réseau et la transmission au terminal lecteur CLTV. Dans cet exemple, pour visualiser un contenu, le terminal CLTV interroge tout d’abord la passerelle de service GTW pour obtenir une adresse du fichier de description MNF du contenu (par exemple, C1) souhaité. La passerelle de service GTW répond en fournissant au terminal CLTV l’adresse du fichier de description MNF. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH (noté « C.mpd ») et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifest». Alternativement, ce fichier peut être récupéré directement auprès d’un serveur Internet local ou externe au réseau local, ou se trouver déjà sur la passerelle de service ou sur le terminal au moment de la requête. Un exemple de fichier manifest (MPD) conforme à la norme MPEG-DASH et comportant la description de contenus disponibles dans trois qualités différentes (512 kb/s,1024 kb/s,2048 kb/s) des contenus segmentés est présenté en annexe 1. Ce fichier manifest simplifié décrit des contenus numériques dans une syntaxe XML (de l'Anglais « eXtended Markup Language»), comprenant une liste de contenus sous forme de 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 segment du contenu « C1 » à 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »), - « C1_512kb_2.mp4 » pour le second segment, - etc. Une fois qu’elle dispose des adresses de segments correspondant au contenu souhaité, la passerelle de service GTW 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). La clef CLTV est utilisée pour restituer, sur l’écran du téléviseur TV, un programme télévisuel. Par la suite, on désigne ce programme télévisuel sous le nom de contenu C1. Un tel contenu C1 est décrit dans un fichier manifest MNF. En variante, on notera que le contenu 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 de durée déterminée, pour laquelle l’invention s’applique également. Les segments de contenu obtenus par la passerelle résidentielle GTW sont par exemple transmis en WiFi® à la clef CLTV, qui pilote leur affichage sur l’écran du téléviseur TV, pour restitution à l’utilisateur. La figure 2 représente une architecture d’un terminal de lecture, dans notre exemple une clé CLTV selon un mode de réalisation de l’invention. La clé CLTV comprend, classiquement, des mémoires M associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l’anglais « Read Only Memory ») ou RAM (de l’anglais « Random Access Memory ») ou encore Flash. La clé CLTV comprend une mémoire tampon appelée aussi antémémoire ou buffer par l’homme du métier La clef CLTV communique avec le réseau local LAN et le réseau Internet étendu WAN via le module WIFI pour une communication locale sans fils avec la passerelle résidentielle GTW ou un autre terminal de communication du réseau local LAN, par exemple le téléphone intelligent 3. La clef CLTV 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 MNF. Ce fichier de description MNF peut être enregistré par exemple dans les mémoires M de la clef CLTV ou se trouver à l’extérieur. La clé CLTV comprend en outre un mode de gestion MNG dont la fonction sera expliquée ci-après. La clef CLTV 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. La clé CLTV est connectée à un téléviseur TV, par l’intermédiaire d’une liaison HDMI 1. On présente désormais, en relation avec la figure 3, les éléments principaux d’une clé CLTV et une vue schématique d’un contenu principal C1 stocké dans le serveur de contenus SRV 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. Selon l’art antérieur, le module de téléchargement HAS de la clé CLTV 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, 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 manifest, 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 3 secondes, la récupération du « chunk » 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 la clé CLTV. 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 le mode de réalisation illustré en figure 3, le module de téléchargement HAS 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 manifest MNF 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 figure 3, le contenu C1 est par exemple proposé sous forme de segments de durée 3s, 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, non illustré sur la figure 3, 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@N3 (soit le deuxième segment temporel à un débit d’encodage de 1600 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 transmis à un module d’interface INT pour leur restitution à l’utilisateur sur l’écran du téléviseur TV. Le module INT gère de l’interface avec le téléviseur TV, par lequel elle obtient par exemple des informations sur les éventuelles interactions de l’utilisateur avec le téléviseur TV (action sur la télécommande du téléviseur par exemple par appui sur la touche volume ou une touche de changement de canal), et par lequel elle peut piloter l’affichage sur l’écran du téléviseur TV d’un contenu demandé, par exemple une chaîne de télévision ou une interface de navigation concomitamment. 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. Selon l’invention, l’instant de démarrage de la lecture du contenu est déterminé en se basant sur un historique des débits réseaux qui ont été disponibles sur une période de temps passée. Le module de gestion MNG va déterminer la quantité de donnée à stocker dans la mémoire tampon avant de déclencher la lecture du contenu. En effet, afin d’assurer une lecture en continu du contenu LIVE, lorsque l’utilisateur souhaite le visualiser à la meilleure qualité possible, le lecteur de flux numérique va dans un premier temps mettre en pause la restitution du contenu et remplir sa mémoire tampon (ou « buffer » en anglais) avec les segments temporels du contenu LIVE à un débit d’encodage supérieur au débit d’encodage déterminé en fonction de la disponibilité en bande passante. Cette phase de remplissage de la mémoire tampon se fait tant que le lecteur de flux n’a pas stocké en mémoire suffisamment de contenu, ou segments temporels, pour assurer ensuite une lecture fluide. Une fois que le lecteur de flux a mis en mémoire tampon, ou stocké, suffisamment de segments temporels du contenu, le lecteur de flux passe alors dans une phase de restitution différée, c’est-à-dire, en mode lecture du contenu. Cette restitution différée s’opère conjointement avec le stockage en mémoire tampon des segments temporels suivants du contenu. Ainsi, pendant la lecture, on consomme la vidéo mise en mémoire tampon et on continue à télécharger des segments temporels représentatifs de la vidéo diffusée, de façon à continuer à remplir la mémoire tampon jusqu’à l’instant de démarrage basé sur l’historique comme cela est expliqué ci-dessous. La figure 4 illustre un historique faisant apparaître la variation de la bande passante disponible sur une période passée donnée, notamment le jeudi 10 septembre 2020 et le vendredi 11 septembre 2020. Cet historique est illustré sous forme de graphique ayant en abscisse le temps t et en ordonnée la valeur de la bande passante BP. Un premier mode de réalisation peut consister à définir l’instant de démarrage, ou le taux d’occupation de la mémoire tampon, en se basant sur la variation de la bande passante passée sur une période passée donnée. Une variation de la bande passante peut consister en une augmentation ou une diminution de la bande passante. Dans notre exemple, pour les deux types de variation, deux instants de démarrage de lecture respectifs sont prédéfinis. Un instant de démarrage est défini lorsque la bande passante va probablement augmenter ; de même, un instant de démarrage est défini lorsque la bande passante va probablement diminuer. Dans notre exemple, le démarrage a lieu lorsque la mémoire tampon atteint un taux d’occupation donné par les segments téléchargés. Ces deux pourcentages sont par exemple 20% et 60%, respectivement. A noter que la variation peut être obtenue de plusieurs manières connues de l’homme du métier, par exemple en calculant une pente d’une droite sur une durée donnée ou la pente d’une tangente obtenue par calcul de dérivée. Plus précisément, dans le cas où la bande passante probable baisse, il est nécessaire de stocker dans la mémoire tampon une partie importante du contenu vidéo à restituer. En référence à la figure 4, ce cas se présente par exemple si l’accès au contenu s’effectue le jeudi à 21h. En effet, le graphique illustré sur la figure 4 montre que la bande passante chute après 21h (une flèche F1 indique la diminution de la bande passante). Dans ce cas, le module de gestion MNG télécharge par exemple 60% du contenu vidéo avant de déclencher la lecture du contenu. Dans le cas où la bande passante probable va croître, il n’est pas nécessaire de stocker une partie importante du contenu vidéo à restituer. En référence à la figure 4, ce cas se présente par exemple si l’accès au contenu s’effectue le vendredi à 21h. En effet, le graphique illustré sur la figure 4 montre que la bande passante a augmenté après 21h le vendredi à la même heure (une flèche F2 indique l’augmentation de la bande passante). Le module de gestion télécharge 20% du contenu vidéo avant de déclencher sa lecture le vendredi à 21h. La figure 5 illustre un deuxième mode de réalisation de calcul de l’instant de démarrage de la lecture du contenu C1 basé sur l’historique illustré sur la figure 4. Ce deuxième mode pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode de réalisation. Sur la figure 5 sont représentés deux axes associés au serveur de contenu d’où est téléchargé C1 et la clé CLTV ainsi que les échanges de données s’effectuant entre ces deux dispositifs. Lors d’une première étape ET1, la clé CLTV requiert un accès au contenu C1 auprès du serveur SRV. A l’instant T0, lors d’une deuxième étape ET2, après réception de la requête, le serveur SRV télécharge successivement des segments (C11@N1,C12@N5,C13@N6,C14@N6,...) du contenu C1 selon la technique décrite ci-dessus du téléchargement adaptatif. Les segments sont reçus successivement par la clé CLTV et sont stockés dans la mémoire tampon de la clé CLTV. L’entité de gestion MNG détermine, pendant le téléchargement du contenu C1, l’instant T1 de démarrage de la lecture du contenu téléchargé. Selon l’invention, le démarrage de la lecture du contenu a lieu lorsque la durée de téléchargement prévue du contenu restant à télécharger est inférieure ou égale à la durée du contenu à lire. Le système va donc déterminer à partir de l’historique quelle sera la bande passante disponible probable dans les minutes ou heures à venir. Dans ce deuxième mode, l’instant de téléchargement est calculé en prenant en compte - la bande passante passée Dmoy, par exemple une moyenne comme expliqué ci-dessus, - la durée Dlct.C1 de lecture du contenu, - et également un débit d’encodage des segments à télécharger choisi parmi les débits d’encodage disponibles dans le manifest. Dans ce mode, le module de gestion MNG calcule une valeur estimée du débit réseau Dmoy qui a été disponible sur une période passée. La période passé est, de préférence, choisie judicieusement, par exemple la semaine précédente à la même heure. La durée de cette période passée est aussi choisie judicieusement. Par exemple, cette durée démarre à l’heure d’accès au contenu jusque par exemple la mise hors tension du téléviseur TV le même jour en particulier lorsque la durée du contenu ne peut être connue à l’avance. Si le durée du contenu à restituer est connue à l’avance ; c’est le cas par exemple des contenus à la demande tels que des contenus VOD (sigle anglo-saxon de Video On Demand) la durée de la période passé peut être la durée du contenu à lire. Par exemple, si l’utilisateur accède à un contenu VOD d’une durée de 2 heures un vendredi à 21h ; dans notre exemple, la période passée correspond au vendredi de la semaine précédente et la durée de la période passée correspond à la durée du contenu VOD restituer à savoir deux heures. Dans notre exemple, la valeur estimée est une valeur moyenne des débits réseaux qui ont été disponibles sur cette période passée. L’utilisation d’une moyenne n’est qu’un exemple de mise en œuvre de l’invention ; un autre débit aurait pu être calculé en lieu et place du débit moyen, par exemple en se basant un calcul de médiane, d’une étendue ou de quartiles, ou toutes formules statistiques équivalentes. Ne connaissant pas le débit réseau future et à fortiori les débits d’encodage futurs sélectionnés par la clé CLTV, le débit d’encodage maximum du manifest peut être sélectionné pour le calcul de l’instant de démarrage; en effet, le débit d’encodage maximum est celui qui consommera le plus de bande passante. Le calcul de cet instant de démarrage de la lecture du contenu peut être le suivant, sans se limiter à celui-ci : A l’instant T1, on considère qu’une partie C1a du contenu a été reçue et stockée en mémoire tampon. La partie complémentaire C1b de C1 (C1= C1a+C1b) est la partie restante à télécharger. La quantité de segments restants à télécharger C1b est donnée par la formule : C1b = Dmoy X Dtch.C1b, Dtch.C1b étant la durée disponible pour télécharger C1b Lorsque le démarrage de la lecture aura lieu à T1, il restera toute la durée Dlct.C1 de lecture du contenu C1 pour télécharger la partie restante C1b. Il faut donc que la condition suivante soit remplie pour être assurée que la lecture du contenu s’effectuera sans dégradation : Dtch.C1b ≤ Dlct.C1 soit : C1b / Dmoy ≤ Dlct.C1 DlctC1 correspondant à la durée totale de lecture du contenu C1. Dans notre exemple, on souhaite que la lecture s’effectue sans interruption. Un mode de réalisation sera décrit ci-après avec interruption. La quantité de segments restants à télécharger C1b correspond à la quantité de segments total de C1 moins la quantité de segments déjà téléchargée C1a. Comme une quantité de donnée reçue correspond à la durée de téléchargement multiplié par le débit d’encodage utilisé, on peut écrire que C1b = (Dtch.C1 – Dtch.C1a) X De Soit C1b = (Dtch.C1b) X De Avec De = débit d’encodage du contenu choisi dans la liste des débits inclus dans le manifest. et Dtch.C1 = durée de téléchargement totale du contenu C1 Plusieurs débits d’encodage sont définis dans le manifest. Le débit d’encodage nécessitant un temps de transmission plus important est celui de meilleure qualité à savoir le débit d’encodage maximum Demax 5000 kb/s dans notre exemple. Dans notre exemple, on choisit donc cette valeur maximum pour le calcul de l’instant de démarrage de la lecture, soit : De = Demax. On aboutit alors à la condition suivante pour le démarrage de la lecture de C1 Dlct.C1 La lecture de C1 peut donc débuter à T1 quand la durée Dtch.C1a aura atteint la condition suivante est vérifiée : Dtch.C1a (1- ) X Dlct.C1 Dans notre exemple, on choisit T1=(1- ) X Dlct.C1 Une fois la lecture du contenu C1 démarrée à l’instant T1, T1 vérifiant la condition précédente, le téléchargement des segments du contenu complémentaire C2a s’effectue classiquement comme expliqué ci-dessus selon la technique HAS. Prenons deux exemples. On considère : - un contenu d’une durée de 2h28 (148 min), - associé à un manifest incluant un débit d’encodage vidéo maximum Demax égal à 5000 kb/s, - et un débit réseau estimé à 4Mb/s sur une période passée calculée judicieusement. Dans cette configuration, la lecture débutera à T1= (1-4000/5000)*148 = 29,6 minutes Le téléchargement de C1a aura alors pris 29,6 minutes. Si le débit réseau estimé est de 2Mb/s : La lecture ne pourra commencer que (1-2000/5000)*148 = 88,8 minutes après le démarrage du téléchargement. Le téléchargement de C1a aura alors pris 88,8 minutes. Le mode de réalisation décrit ci-dessus à l’avantage d’assurer une lecture sans dégradation. Une autre variante plus risquée peut consister à prendre non pas le débit d’encodage maximum mais un débit d’encodage intermédiaire. Par exemple, en reprenant l’exemple du manifest décrit ci-dessus, le débit d’encodage reçu aurait pu être 1600 kb/s ou 2100 kb/s. La figure 5 fait apparaître la durée Dtlc.C1a de téléchargement de C1a, la durée de téléchargement de C1b à savoir Dtcl.C1b. Sur cette figure, on s’aperçoit que la durée de téléchargement de C1b à savoir Dtcl.C1b est finalement inférieure à la durée de lecture Dlct.C1 du contenu C1. En effet, les segments téléchargés relatifs à C1b n’étaient pas tous associés au débit maximum Demax. Annexe 1 Procédé de gestion de la lecture d’un contenu numérique (C1) téléchargé depuis un serveur de contenu (SRV) via un réseau de communication (RES), le contenu comprenant plusieurs segments, caractérisé en ce qu’il comprend les étapes suivantes : Une étape préalable d’obtention d’un historique de la variation de la bande passante qui a été disponible sur le réseau (RES) sur une période de temps passée ; Une étape de réception de segments du contenu téléchargé et de stockage des segments reçus dans une mémoire tampon ; Une étape de détermination d’un instant de démarrage de la lecture des données reçues basée sur l’historique de la variation de la bande passante obtenu lors de l’étape préalable. Procédé de gestion selon la revendication 1, caractérisé en ce que le contenu comprend plusieurs segments associés à plusieurs débits d’encodage respectifs, et en ce que l’étape de réception est suivie d’une étape de calcul d’une durée de téléchargement estimée du contenu restant à télécharger en prenant compte une bande passante issue de l’historique, une durée de lecture du contenu et un débit d’encodage choisi parmi les débits d’encodage disponibles, l’instant de démarrage étant choisi de telle sorte que la durée de téléchargement estimée du contenu restant à télécharger est inférieure ou égale à la durée du contenu à lire. Procédé de gestion selon la revendication 2, caractérisé en ce que le débit d’encodage choisi parmi les débits d’encodage disponibles est le débit d’encodage maximum disponible. Procédé de gestion selon la revendication 2, caractérisé en ce que le débit réseau estimé est le débit réseau moyen calculé sur la période passée donnée. Procédé de gestion selon la revendication 1, caractérisé en ce que la variation de la bande passante comprend une augmentation ou une diminution de la bande passante, en ce que des instants de démarrage distincts sont prédéfinis respectivement. Entité de gestion (MNG) de la lecture d’un contenu numérique téléchargé depuis un serveur de contenu via un réseau de communication, le contenu comprenant plusieurs segments accessibles depuis un serveur de contenus, caractérisé en ce qu’il comprend Un module d’obtention apte à obtenir un historique de la variation de la bande passante qui a été disponible sur le réseau sur une période de temps passée ; Un module de réception apte à recevoir les segments du contenu téléchargé et de stockage des segments reçus dans une mémoire tampon; Un module de détermination apte à déterminer un instant de démarrage de la lecture des données reçues basée sur l’historique de la variation de la bande passante obtenu lors de l’étape préalable. Terminal lecteur de contenus multimédias (CLTV) comprenant une entité telle que définie dans la revendication 6. Programme d’ordinateur apte à être mis en œuvre sur un terminal lecteur de contenus multimédias tel que défini dans la revendication 7, 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 l’une des revendications 1 à 5.