Brevet FR3102904A1 — publié le 20210507

L’invention répond à ce besoin en proposant un procédé de gestion de zapping d’un premier à un second contenu numérique. Ces premier et second contenus numériques sont obtenus par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia, et sont respectivement associés à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage du contenu. Ce procédé de gestion de zapping comprend : - une réception d’une requête de zapping du premier contenu numérique vers le second contenu numérique, - une obtention du fichier de description dudit second contenu numérique. Selon l’invention, un tel procédé comprend également : - une sélection d’un débit d’encodage d’un premier segment temporel dudit second contenu numérique à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par ledit terminal lecteur de flux multimédia, et d’autre part d’un temps de zapping cible, - un téléchargement dudit premier segment temporel dudit second contenu numérique audit débit sélectionné. Figure pour l’abrégé : FIGURE 3 Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (HAS), dispositif de gestion, lecteur de flux multimédia et programme d’ordinateur correspondants. Domaine technique de l'invention. Le domaine de l’invention est celui des contenus multimédias numériques, à savoir les contenus audio et/ou vidéo numériques, et plus particulièrement les contenus multimédias numériques obtenus selon une technique dite de téléchargement progressif adaptatif (HAS) au sein d’un réseau de communication local, tel qu’un réseau domestique. Plus précisément, l’invention concerne l’optimisation du zapping d’un contenu multimédia numérique à un autre, c’est-à-dire de l’abandon de la consommation d’un premier contenu multimédia numérique pour basculer sur un second contenu multimédia numérique, au sein d’un terminal lecteur de flux multimédia. Art antérieur. L’accès à un contenu multimédia numérique, 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 client, notamment lorsqu’ils appartiennent à un réseau de communication local, tel qu’un réseau domestique. Le terminal émet généralement une requête à destination d’un serveur, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu. Dans le cadre d’un réseau de communication local, une telle requête transite par la passerelle d’accès au réseau, par exemple la passerelle résidentielle. Le terminal est adapté pour recevoir ces contenus numériques sous forme de données multimédia et pour en faire une restitution. Cette restitution consiste à fournir au niveau du terminal le contenu numérique sous une forme accessible à l’utilisateur. Par exemple, des données reçues correspondant à une vidéo sont généralement décodées, puis restituées au niveau du terminal sous la forme d’un affichage de la vidéo correspondante avec sa bande-son associée. Dans la suite, par souci de simplification, on assimilera le contenu numérique à une vidéo et la restitution par le terminal, ou consommation par l’utilisateur du terminal, à une visualisation ou lecture 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 Transfer Protocol », pour « protocole de transfert hypertexte »). En particulier, le téléchargement en mode progressif des contenus numériques, aussi appelé streaming, permet de transporter et consommer les données en temps réel, c'est-à-dire que les données numériques sont transmises sur le réseau et restituées par le terminal au fur et à mesure de leur arrivée. Le terminal reçoit et stocke une partie des données numériques dans une mémoire tampon avant de les restituer. Ce mode de distribution est particulièrement utile quand le débit dont dispose l’utilisateur n’est pas garanti pour le transfert en temps réel de la vidéo. Le téléchargement progressif adaptatif, en anglais HTTP Adaptative Streaming, d’abréviation HAS, permet de surcroît de diffuser et recevoir des données suivant différentes qualités correspondant par exemple à différents débits. Ces différentes qualités sont décrites dans un fichier de paramètres disponible en téléchargement sur un serveur de données, par exemple un serveur de contenus. Quand le terminal client souhaite accéder à un contenu, ce fichier de description permet de sélectionner le bon format pour le contenu à consommer en fonction de la bande passante disponible ou des capacités de stockage et de décodage du terminal client. Ce type de technique permet notamment de tenir compte des variations de bande passante sur la liaison entre le terminal client et le serveur de contenus. Il existe plusieurs solutions techniques pour faciliter la distribution d’un tel contenu en streaming, comme par exemple les solutions propriétaires Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming ou encore la norme MPEG-DASH de l’organisme ISO/IEC qui sera décrite ci-après. Ces méthodes proposent d’adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents ou manifestes, contenant les adresses des différents segments aux différentes qualités du contenu multimédia. Ainsi, la norme MPEG-DASH (pour l’anglais “Dynamic Adaptive Streaming over HTTP”, en français « diffusion en flux adaptatif dynamique sur HTTP ») est un standard de format de diffusion audiovisuelle sur Internet. Il se base sur la préparation du contenu en différentes présentations de qualité et débit variables, découpées en segments de courte durée (de l’ordre de quelques secondes), également appelés « chunks ». Chacun de ces segments est rendu disponible individuellement au moyen d'un protocole d'échange. Le protocole principalement ciblé est le protocole HTTP, mais d'autres protocoles (par exemple FTP) peuvent également être utilisés. L'organisation des segments et les paramètres associés sont publiés dans un manifeste au format XML. Le principe sous-jacent à cette norme est que le client MPEG-DASH effectue une estimation de la bande passante disponible pour la réception des segments, et, en fonction du remplissage de son tampon de réception, choisit, pour le prochain segment à charger, une représentation dont le débit : - assure la meilleure qualité possible, - et permet un délai de réception compatible avec le rendu ininterrompu du contenu. Ainsi, pour s’adapter à la variation des conditions réseau, notamment en termes de bande passante, les solutions existantes de téléchargement adaptatif permettent au terminal client de passer d’une version du contenu encodée à un certain débit, à une autre encodée à un autre débit, au cours du téléchargement. En effet, chaque version du contenu est divisée en segments de même durée. Pour permettre une restitution en continu du contenu sur le terminal, chaque segment doit atteindre le terminal avant son instant programmé de restitution. La qualité perçue associée à un segment augmente avec la taille du segment, exprimée en bits, mais dans le même temps, des segments plus gros requièrent un temps de transmission plus important, et donc présentent un risque accru de ne pas être reçus à temps pour une restitution en continu du contenu. Le terminal client 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. En d’autres termes, afin d’assurer une certaine fluidité lors de la lecture, si la bande passante disponible ne permet pas d’accéder à la meilleure qualité diffusée, le terminal client va utiliser des flux de données de moins bonne qualité. Cette technique permet ainsi de proposer la meilleure qualité vidéo possible tout en garantissant une lecture ou visualisation du contenu numérique fluide. La consommation de contenus numériques en téléchargement progressif adaptatif (HAS) tend à se démocratiser. Elle est notamment utilisée par de nombreux services de streaming (en français, diffusion en mode continu, ou lecture en continu), mais également par certains décodeurs TV, ou set-top-box, qui l’utilisent pour accéder à des contenus délinéarisés, tels que la vidéo à la demande (VOD), la diffusion en différé de programmes télévisuels (Replay), ou encore les offres de type Network PVR (pour « Network Personal Video Recorder », i.e. un service d’enregistrement des contenus numériques, effectué par le fournisseur de contenus lui-même plutôt qu’au domicile de l’utilisateur final). En outre, d’autres dispositifs tels que des appareils lecteurs de flux multimédia en temps réel accèdent également aux contenus numériques en mode de téléchargement adaptatif progressif pour des contenus télévisuels en temps réel (ou LIVE). C’est le cas par exemple de l’appareil Chromecast® développé par Google®, ou de la Clé TV® d’Orange®. De tels appareils se branchent classiquement sur le port HDMI d’un téléviseur et 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 téléviseur, le contenu multimédia reçu par une application logicielle compatible. On désignera par la suite ces appareils sous la désignation générique de Clef HDMI. Dans la suite, par souci de simplification, on assimilera le terme « terminal client » à l’association d’un terminal lecteur de flux multimédia (par exemple Clef HDMI) et d’un terminal de restitution (par exemple un téléviseur) permettant de visualiser le contenu. On notera que le terminal de restitution peut être le terminal lecteur de flux multimédia lui-même (par exemple un téléphone mobile intelligent, une tablette), ou être distinct de celui-ci (par exemple un téléviseur connecté à une Clef HDMI, ou à une set-top box (STB)). Lorsqu’un utilisateur utilise les services de tels serveurs de contenus numériques, il peut souhaiter passer rapidement d’un contenu numérique à un autre : on parle alors de « zapping ». En effet, on entend par « zapping » (en français « saut de chaîne ») le fait que l’utilisateur abandonne la consommation d’un contenu multimédia numérique (par exemple un premier programme, ou une première chaîne télévisuelle) pour basculer sur un autre contenu multimédia numérique (par exemple un autre programme ou une autre chaîne) de manière rapide. Dans la présente demande, on étend le terme « zapping » à tout changement de contenu multimédia numérique obtenu en HAS vers un autre. Dans un premier exemple, cela peut être d’un contenu multimédia numérique diffusé en LIVE (en français en « temps réel ») à un autre, comme par exemple d’une chaîne télévisuelle à une autre. Dans un second exemple, cela peut être d’un contenu multimédia numérique de type VOD à un autre, comme par exemple d’un épisode d’une série à un autre épisode de cette même série. Il peut également d’agir du passage d’un contenu temps réel à un contenu différé, par exemple d’un programme télévisuel LIVE vers un programme en différé de type replay, ou vers une vidéo à la demande. Dans ce contexte de téléchargement progressif adaptatif HAS, le temps de zapping d’un contenu multimédia numérique à un autre, sur les terminaux lecteur de flux multimédia, comme par exemple une Clef HDMI, varie beaucoup en fonction de l’environnement réseau, c’est-à-dire du type d’accès au réseau de communication de l’utilisateur (par exemple ADSL (de l'anglais « Asymmetric Digital Subscriber Line ») ; VDSL (de l’anglais « Very high bit rate digital subscriber line ») ; ou fibre), de la bande passante au moment du zapping, de la disponibilité du serveur de contenu, mais également en fonction du contenu multimédia numérique auquel l’utilisateur souhaite accéder. Classiquement, lors du basculement de la restitution d’un premier vers un second contenu numérique lors d’un zapping en HAS, les fragments du second contenu sont téléchargés au même débit d’encodage que l’étaient ceux du premier contenu. Pour certains utilisateurs dont l’environnement réseau est bon (par exemple s’il dispose de la fibre), le temps nécessaire pour basculer de la restitution d’un contenu numérique à un autre, ou temps de zapping, peut être acceptable, mais pour d’autres, il peut être très long (plus de 5 secondes dans certains cas). Or, il est important que ce temps de zapping reste court pour ne pas gêner l’utilisateur et garantir une bonne qualité d’expérience. Il existe déjà une solution implémentée par les terminaux lecteurs de flux multimédia pour diminuer le temps de zapping de manière globale et indifférenciée à tous les utilisateurs. Cette solution se base sur la récupération de segments temporels de basse qualité lors des phases de zapping. Ainsi, les segments temporels du nouveau contenu multimédia numérique à télécharger le sont au débit le plus faible proposé dans le fichier de description de ce contenu numérique, et ceci quelles que soient les contraintes réseau, notamment en termes de bande passante. On assure ainsi un temps de zapping le plus court possible, car le téléchargement et le décodage des chunks du nouveau contenu à restituer s’opèrent en un temps réduit. Cependant, cette solution, même si elle offre un temps de zapping court, peut nuire à la qualité de la restitution du nouveau contenu. Notamment, les utilisateurs disposant d’une bande passante satisfaisante, qui aurait pu permettre de télécharger des segments temporels de meilleure qualité, se trouvent lésés. Ainsi, même si le temps de zapping est court, la qualité des contenus numériques n’est pas optimisée et la qualité d’expérience de l’utilisateur est potentiellement diminuée. Il existe donc un besoin d’une technique de gestion du zapping de contenus numériques, obtenus en téléchargement progressif adaptatif (HAS), qui ne présente pas ces différents inconvénients de l’art antérieur. Notamment, il existe un besoin d’une telle technique qui permette d’offrir un bon compromis entre, d’une part la rapidité de zapping, et d’autre part la qualité de restitution du contenu numérique lors du zapping et donc la qualité d’expérience pour l’utilisateur, en tirant notamment avantage des spécificités techniques du téléchargement adaptatif progressif (HAS). Présentation de l'invention L’invention répond à ce besoin en proposant un procédé de gestion de zapping d’un premier à un second contenu numérique. Ces premier et second contenus numériques sont obtenus par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia, et sont respectivement associés à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage du contenu. Ce procédé de gestion de zapping comprend : une réception d’une requête de zapping du premier contenu numérique vers le second contenu numérique, une obtention du fichier de description dudit second contenu numérique. Selon l’invention, un tel procédé comprend également : une sélection d’un débit d’encodage d’un premier segment temporel du second contenu numérique à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par le terminal lecteur de flux multimédia, et d’autre part d’un temps de zapping cible, un téléchargement du premier segment temporel du second contenu numérique au débit sélectionné. Ainsi, l’invention repose sur une approche tout à fait nouvelle et inventive de la gestion du zapping d’un contenu à un autre, dans un contexte de téléchargement progressif adaptatif. Plus particulièrement, l’invention propose de tenir compte, en plus des contraintes de ressource du terminal lecteur de flux multimédia, d’un temps de zapping cible, permettant d’optimiser la qualité d’expérience de l’utilisateur, pour choisir la qualité, ou débit d’encodage, du premier segment temporel du nouveau contenu (ou second contenu) à télécharger lors du zapping. Pour cela, lorsque l’utilisateur émet, au cours de la restitution d’un premier contenu numérique, une commande de changement de contenu, aussi appelée commande de zapping, le terminal lecteur de flux multimédia numérique la reçoit, et sélectionne alors le débit d’encodage du premier segment temporel du nouveau contenu numérique à télécharger, puis à restituer, en fonction de la bande passante disponible, de manière à ce que le temps de zapping cible soit respecté. En effet, le terminal lecteur de flux multimédia connaît les contraintes de bande passante courantes, selon la technique HAS classique. Ce temps de zapping cible définit ainsi un plafond de temps de zapping raisonnable à ne pas dépasser afin de proposer à l’utilisateur une expérience agréable. La prise en compte conjointe des conditions de ressource disponibles et de ce temps de zapping cible permet d’améliorer l’expérience utilisateur en optimisant conjointement, tant le temps nécessaire pour basculer de la restitution d’un contenu à un autre, que la qualité de restitution du nouveau contenu. Ainsi, l’utilisateur n’est pas gêné par un temps de zapping trop long entre le moment où il émet la commande de zapping et le moment où le nouveau contenu lui est restitué, et peut visualiser ce nouveau contenu à la meilleure qualité possible en fonction de sa bande passante. En d’autres termes, le procédé selon l’invention permet d’optimiser la qualité d’encodage du nouveau contenu à restituer, pour favoriser la meilleure qualité d’expérience possible, sans impact sur le temps de zapping, puisque celui-ci est limité par un temps de zapping cible à ne pas dépasser. Ainsi, le procédé selon l’invention permet de faire un compromis entre un temps de zapping cible qui n’est pas trop long et une qualité de restitution d’un nouveau contenu numérique, et offre à l’utilisateur une meilleure qualité d’expérience lors du zapping d’un contenu numérique à un autre. Selon un aspect particulier de l’invention, le débit d’encodage sélectionné correspond à un débit d’encodage pour lequel un temps de zapping du premier au second contenu est inférieur ou égal au temps de zapping cible. De manière avantageuse, l’invention se propose de ne pas chercher à minimiser le temps de zapping pour l’utilisateur, mais au contraire d’être au plus proche d’un temps de zapping cible prédéfini qui est identique quelles que soient les conditions de bande passante et de ressource du réseau de communication de l’utilisateur et du serveur de contenus. Ainsi, l’invention cherche à optimiser la qualité d’encodage du premier segment temporel à télécharger du nouveau contenu à restituer en respectant ce temps de zapping cible quelles que soient les contraintes de ressources. Ainsi, quelles que soient les circonstances, le temps de zapping expérimenté par l’utilisateur est toujours le même : cette reproductibilité est favorable à la qualité de l’expérience utilisateur. On notera que, par temps de zapping, on entend le temps qui s’écoule entre l’émission par l’utilisateur d’une commande de zapping, et la restitution sur le terminal de restitution du nouveau contenu numérique. Ce temps de zapping ne doit pas dépasser un temps de zapping cible, ou temps de zapping maximal. Dans un exemple, ce temps de zapping cible est de 2 secondes, valeur qui garantit une bonne expérience utilisateur au niveau du temps d’attente entre l’émission de la commande de changement de contenu numérique et la restitution sur le terminal de restitution du nouveau contenu numérique. Selon un autre aspect particulier de l’invention, la sélection d’un débit d’encodage prend en compte un temps de latence nécessaire à l’obtention du fichier de description du second contenu numérique. Ainsi, le temps de zapping entre le moment où l’utilisateur demande le changement du premier contenu numérique en cours de restitution vers le second contenu, prend en compte un temps de latence incompressible. Ce temps de latence correspond au temps qui s’écoule entre l’émission de de la commande de changement de contenu par l’utilisateur et l’obtention du fichier de description, ou fichier manifeste, du second contenu à télécharger puis à restituer. En effet, lors d’un zapping, le terminal lecteur de flux multimédia reçoit une requête de changement d’un premier contenu numérique pour un second contenu numérique. Ce terminal envoie donc une requête de récupération du fichier manifeste du second contenu au serveur de contenus numériques puis récupère ce fichier manifeste. On mesure ensuite le temps de latence correspondant. Plus particulièrement, ce temps de latence correspond au temps incompressible entre le moment où l’utilisateur demande un changement de contenu numérique, via une commande de zapping, et la récupération par le terminal des premiers octets du fichier manifeste du second contenu numérique. Ce temps de latence dépend donc d’une part de la bande passante au moment du zapping, mais également du temps que met le serveur de contenus à envoyer le fichier manifeste du second contenu au terminal lecteur de flux multimédia. Dans le fichier manifeste du second contenu, plusieurs qualités d’encodage sont exposées et on sélectionne alors la qualité d’encodage du premier segment temporel à télécharger telle que cette qualité correspond à une qualité dite cible, permettant de respecter au mieux le temps de zapping cible en fonction des conditions de bande passante et du temps de latence. Ainsi, la prise en compte de ce temps de latence permet de sélectionner la meilleure qualité d’encodage du premier segment temporel du second contenu numérique à télécharger permettant de respecter le temps de zapping cible. Selon une caractéristique de l’invention la requête de zapping appartient au groupe comprenant : - un déplacement dans un guide des programmes de contenu numérique ; - une saisie d’un identifiant du second contenu numérique sur un clavier numérique, l’identifiant comprenant au moins un caractère alphanumérique. Ainsi, l’utilisateur, pour zapper, émet une commande de zapping via par exemple un déplacement dans un programme de contenu numérique. Ce déplacement dans le guide des programmes de contenu numérique peut s’effectuer par exemple en appuyant sur les touches P+ ou P- d’une télécommande ou en balayant l’écran tactile d’une tablette ou d’un smartphone. Dans un autre exemple, la commande de zapping se fait plus directement via la sélection d’un contenu numérique par saisie de l’identifiant de ce second contenu sur un clavier numérique. Cet identifiant pouvant être une suite de caractère alphanumérique comme par exemple le numéro de la chaîne ou le numéro de l’épisode d’une série. Cette saisie se fait par exemple via la télécommande d’une télévision ou directement sur le l’écran tactile d’un smartphone ou d’une tablette. Selon une autre caractéristique de l’invention, le procédé comprend une étape de paramétrage du temps de zapping cible par un utilisateur via une interface d’un terminal de restitution. Ainsi, l’utilisateur peut sélectionner, par exemple via une interface d’un terminal de restitution, un temps de zapping cible correspondant à un temps de zapping maximal prédéfini par le constructeur par exemple, ou bien le modifier en fonction de ses préférences. L’utilisateur peut donc préférer un temps de zapping cible plus court et le téléchargement de segments temporels du nouveau contenu de moins bonne qualité ou bien préférer un temps de zapping cible plus long, pour favoriser la sélection de segments temporels à la meilleure qualité permise par les contraintes de bande passante. Selon un autre aspect de l’invention, le temps de zapping cible dépend d’une nature du second contenu numérique. Ainsi, il est possible de paramétrer plusieurs temps de zapping cibles, en fonction de la nature du contenu numérique (par exemple film, documentaire, sport…). En d’autres termes, lorsque l’utilisateur a un intérêt particulier pour un contenu de nature particulière, comme par exemple un film, il peut choisir un temps de zapping cible plus long afin de s’assurer que la meilleure qualité de contenu est téléchargée. Au contraire, lorsque la qualité du contenu n’a que peu d’intérêt pour l’utilisateur (par exemple journal télévisuel), il peut choisir un temps de zapping plus court pour favoriser le téléchargement du contenu à un débit d’encodage faible. Ce paramétrage peut être laissé à la discrétion de l’utilisateur, ou être opéré par le constructeur du terminal lecteur de flux multimédia mettant en œuvre ce procédé de zapping. L’invention concerne également un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de gestion de zapping d’un premier à un second contenu numérique, tel que décrit précédemment, lorsqu’il est exécuté par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion de zapping d’un premier à un second contenu numérique selon l’invention tel que décrit ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit micro- électronique, ou encore un moyen d'enregistrement magnétique, par exemple une clef USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d’affichage précité. L’invention concerne encore un dispositif de gestion de zapping d’un premier à un second contenu numérique. Ces premier et second contenus numériques sont obtenus par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia et sont respectivement associés à un fichier de description, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage du contenu. Ce dispositif comprend : un module de réception d’une requête de zapping du premier contenu numérique vers le second contenu numérique, un module d’obtention du fichier de description du second contenu numérique. Ce dispositif comprend en outre : un module de sélection d’un débit d’encodage d’un premier segment temporel du second contenu numérique à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par le terminal lecteur de flux multimédia, et d’autre part d’un temps de zapping cible, un module de téléchargement du premier segment temporel du second contenu numérique au débit sélectionné. Enfin, l’invention concerne également un terminal lecteur de flux multimédia, comprenant un dispositif de gestion de zapping d’un premier à un second contenu numérique tel que décrit précédemment. Le dispositif de gestion, le terminal lecteur de flux multimédia et le programme d’ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion de zapping d’un premier à un second contenu numérique selon les différents modes de réalisation de la présente invention. Brève description des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : : présente une architecture de téléchargement progressif sur un réseau domestique basée sur l’utilisation du streaming adaptatif selon un mode de réalisation de l’invention ; : illustre de façon schématique la structure matérielle d’un terminal lecteur de flux multimédia intégrant un dispositif de gestion de zapping selon un mode de réalisation de l’invention ; : illustre un exemple sous une forme de chronogramme de mise en œuvre d’un procédé de gestion de gestion de zapping d’un premier à un second contenu numérique par un terminal lecteur de flux multimédia selon la figure 2, associé à un terminal de restitution. Description détaillée de l’invention Le principe général de l’invention repose sur la possibilité, lors d’un zapping d’un contenu numérique à un autre, obtenus en téléchargement HAS, de sélectionner le débit d’encodage du premier segment temporel du nouveau contenu à télécharger (également désigné par la suite comme le second contenu numérique à télécharger) en tenant compte, d’un part des contraintes de ressource du terminal lecteur de flux multimédia, et d’autre part d’un temps de zapping cible. Ainsi, la prise en compte conjointe des conditions de ressource disponibles et de ce temps de zapping cible permet d’améliorer l’expérience utilisateur en optimisant conjointement, tant le temps nécessaire pour basculer de la restitution d’un contenu à un autre, que la qualité de restitution du nouveau contenu. On présente désormais, en relation avec la figure 1 , une architecture de téléchargement progressif dans un réseau domestique basée sur l’utilisation du streaming adaptatif selon l’invention. Le terminal 3, par exemple un téléphone intelligent de type « smartphone », le terminal 4, par exemple une tablette, et le terminal 8, par exemple une clef HDMI connectée à un téléviseur 5, se trouvent, dans cet exemple, situés dans un réseau local (LAN, 10) piloté par une passerelle domestique 6. 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. Un serveur de contenus numériques « HAS » 2, ou serveur de contenus 2, se trouve selon cet exemple dans le réseau étendu (WAN, 1) mais il pourrait indifféremment être situé dans le réseau local (LAN, 10), par exemple dans la passerelle domestique 6 ou tout autre équipement capable d’héberger un tel serveur de contenus. Le serveur de contenus 2 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 des terminaux clients. Les terminaux clients 3, 4 et la clef HDMI 8 en association avec le téléviseur 5, peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.). Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre les terminaux 3, 4 et 8 et le serveur de contenus 2, à une technique de téléchargement progressif adaptatif, en anglais « adaptive streaming », abrégé en HAS basée sur le protocole HTTP. Ce type de technique permet notamment d'offrir une bonne qualité de contenus à l’utilisateur en tenant compte des variations de bande passante qui peuvent se produire sur la liaison entre les terminaux clients 3, 4 et 8 et la passerelle de services 6, ou entre cette dernière et le serveur de contenus 2. Classiquement, différentes qualités peuvent être encodées pour le même contenu numérique, correspondant par exemple à différents débits. Plus généralement, on parlera de qualité pour se référer à une certaine résolution du contenu numérique (résolution spatiale, temporelle, niveau de qualité associée à la compression vidéo et/ou audio) avec un certain débit. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (ou « fragments » de contenu, en anglais « chunks », ces trois mots étant utilisés indifféremment dans l’ensemble de ce document). La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les fragments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L’ensemble de ces paramètres (qualités, adresses des fragments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description ou manifeste. On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d’informations descriptives du contenu, accessible à une certaine adresse. Les terminaux 3, 4 et 8 possèdent leurs propres caractéristiques en termes de capacité de décodage, d’affichage, etc. Dans un contexte de téléchargement adaptatif progressif, ils peuvent adapter leurs requêtes pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui leur correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits 400 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté D1), 800 kb/s (D2), 1200 kb/s (D3), 2100 kb/s (D4) et que le terminal client dispose d’une bande passante de 3000 kb/s, il peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 2100 kb/s. De manière générale, on note « CXi@Dj » le segment numéro i avec la qualité j (par exemple le j-ième niveau Dj de qualité décrit dans le fichier de description) du contenu numéro X. La passerelle de services 6 est dans cet exemple une passerelle domestique qui assure le routage des données entre le réseau étendu 1 et le réseau local 10 et gère les contenus numériques en assurant notamment leur réception en provenance du réseau étendu 1. Les terminaux 3, 4 et 8 reçoivent les données en provenance du réseau étendu 1, via la passerelle domestique 6, et assurent leur décodage, et éventuellement leur restitution sur leur écran, ou dans l’exemple de la clef HDMI 8 sur le téléviseur 5 associé. Dans une variante, les terminaux 3 et 4 transmettent ces données à la clef HDMI 8 pour restitution sur l’écran du téléviseur 5. Dans une autre variante, le décodeur peut se trouver ailleurs dans le réseau étendu 1 ou local 10, notamment au niveau d’un élément de type STB (de l’anglais Set-Top-Box) (non représenté) associé à un téléviseur 5. Dans cet exemple, pour visualiser un contenu, les terminaux 3, 4 ou 8 interrogent tout d’abord la passerelle de service 6 pour obtenir une adresse du document de description 7 d’un premier contenu numérique C1 souhaité. La passerelle de service 6 répond en fournissant au terminal l’adresse du fichier de description 7. Dans la suite, on supposera que ce fichier est un fichier de type manifeste 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 « manifeste ». 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 manifeste (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 manifeste simplifié décrit des contenus numériques dans une syntaxe XML (de l'Anglais « eXtended Markup Language »), comprenant une liste de contenus sous forme de fragments classiquement décrits entre une balise ouvrante ( ) et une balise fermante ( ). La découpe en fragments permet notamment de s’adapter finement aux fluctuations de la bande passante. Chaque fragment correspond à une certaine durée (champ « duration ») avec plusieurs niveaux de qualité et permet de générer leurs adresses (URL – Uniform Resource Locator). Cette génération est faite dans cet exemple à l’aide des éléments « BaseURL » (« HTTP://server.com») qui indique l’adresse du serveur de contenus et « SegmentURL » qui liste les parties complémentaires des adresses des différents fragments : « C1_512kb_1.mp4 » pour le premier fragment du contenu « C1 » à 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »), « C1_512kb_2.mp4 » pour le second fragment, etc. Une fois qu’elle dispose des adresses de fragments correspondant au contenu souhaité, la passerelle de service 6 procède à l’obtention des fragments via un téléchargement à ces adresses. On notera que ce téléchargement s’opère ici, traditionnellement, au travers d’une URL HTTP, mais pourrait également s’opérer au travers d’une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple). On suppose ici que la clef HDMI 8 est connectée au téléviseur 5 par branchement sur le port HDMI de ce dernier, et est utilisée pour restituer, sur l’écran du téléviseur 5, un contenu CX (X étant un entier représentant le X-ième contenu visualisé), décrit dans un fichier manifeste 7. On notera que le contenu CX peut être un programme télévisuel diffusé en direct ou en différé (comme par exemple un film, une série, une émission télévisuelle, une séquence publicitaire etc.…), ou une vidéo à la demande, ou tout autre contenu numérique multimédia. Dans un exemple, un utilisateur souhaite visualiser un contenu numérique multimédia, tel qu’un film, sur son téléviseur 5 connecté à une clef HDMI 8. La clef HDMI 8 est connectée en WiFi® directement à la passerelle résidentielle 6. En variante, la clef HDMI 8 pourrait également être connectée en WiFi® à un autre périphérique nomade du réseau domestique, par exemple à la tablette 4 ou au téléphone intelligent 3, par l’intermédiaire duquel elle pourrait accéder au réseau de communication étendu 1. La clef HDMI 8 peut également être pilotée par l’utilisateur au moyen du téléphone intelligent 3, sur lequel est installée une application logicielle de commande de la clef HDMI 8. Les fragments de contenu obtenus par la passerelle résidentielle 6 sont par exemple transmis en WiFi® à la clef HDMI 8, qui pilote leur affichage sur l’écran du téléviseur 5, pour restitution à l’utilisateur. La figure 2 représente une architecture d’un terminal lecteur de flux multimédia 9, ou lecteur de flux 9, selon un mode de réalisation de l’invention. Ce terminal lecteur de flux 9 peut être par exemple la clef HDMI 8, ou le téléphone intelligent 3 de la figure 1 . En variante, ce lecteur de flux 9 est intégré au niveau d’un élément de type STB associé à un téléviseur (non représenté). On décrit plus spécifiquement dans la suite l’exemple de la clef HDMI 8. Le terminal lecteur de flux 9 comprend, classiquement, des mémoires MEM associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l’anglais « Read Only Memory ») ou RAM (de l’anglais « Random Access Memory ») ou encore Flash. Le lecteur de flux multimédia 9 comprend un module de téléchargement progressif adaptatif HAS, ou module client HAS, apte à demander un téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description 7. Ce fichier de description 7 peut être enregistré par exemple dans les mémoires MEM du lecteur de flux multimédia 9 ou se trouver à l’extérieur. L’obtention de ce fichier manifeste 7, depuis le serveur de contenu, est également pilotée par le module de téléchargement HAS. Le lecteur de flux multimédia 9 comprend en outre un module de zapping ZAP permettant à un utilisateur de zapper, c’est-à-dire d’abandonner la consommation d’un contenu numérique pour basculer sur un autre de manière rapide. Un tel module de zapping ZAP est apte à recevoir une requête de zapping d’un premier à un second contenu numérique lorsque l’utilisateur émet une commande de zapping, par exemple au moyen d’une télécommande associée au téléviseur 5, ou par action sur une interface du téléphone intelligent 3 ou de la tablette 4. Le lecteur de flux multimédia 9 comprend également un module de sélection d’un débit d’encodage d’un premier segment temporel d’un nouveau contenu à télécharger SEL, ou module de sélection SEL. Lors de la mise en œuvre d’un zapping par le module de zapping ZAP, le module de sélection SEL pilote le module client HAS, afin de forcer ce dernier à demander le téléchargement du premier segment temporel du nouveau contenu en fonction, d’une part d’une contrainte de ressource obtenue par le terminal lecteur de flux multimédia 9, et d’autre part d’un temps de zapping cible. Le lecteur de flux multimédia 9 selon un mode de réalisation de l’invention peut aussi contenir d’autres modules (non représentés) comme un disque dur pour le stockage des fragments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues d’une télécommande, ou d’une tablette, d’un smartphone sur lesquels est installée l’application de pilotage du lecteur de flux 9, grâce à laquelle l’utilisateur peut en contrôler le fonctionnement, etc. Dans l’exemple où le terminal lecteur de flux 9 est la clef HDMI 8, celle-ci ne contient généralement pas de module d’interface E/S, et c’est le module d’interface E/S du smartphone 3 de l’utilisateur ou de sa tablette 4, ou du téléviseur 5, qui est utilisée par ce dernier pour choisir par exemple son contenu. On notera que le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Plus généralement, un tel lecteur de flux 9 comprend une mémoire vive MEM (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur CPU, et pilotée par un programme d'ordinateur, et comportant des instructions de code représentatives des modules de zapping ZAP, de sélection SEL, et du module de gestion du téléchargement progressif adaptatif HAS, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur CPU de l'unité de traitement. La mémoire vive contient notamment le fichier de description manifeste 7. Le processeur de l’unité de traitement pilote la sélection d’un débit d’encodage d’un premier segment temporel du nouveau contenu à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par le terminal lecteur de flux multimédia 9, et d’autre part du temps de zapping cible et l’émission de commandes correspondantes vers le module client HAS. La figure 2 illustre seulement une manière particulière, parmi plusieurs possibilités, de réaliser le terminal lecteur de flux 9, afin qu’il effectue les étapes du procédé détaillé ci-après, en relation avec la figure 3 (dans l’un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). On présente désormais, en relation avec la figure 3 , sous une forme de chronogramme, un exemple de mise en œuvre d’un procédé de zapping d’un premier à un second contenu numérique obtenu en téléchargement HAS, selon un mode de réalisation de l’invention. Dans cet exemple, le terminal lecteur de flux 9 selon la figure 2 est la clef HDMI 8, qui pilote la restitution du contenu numérique multimédia sur le téléviseur 5 associé. La clef HDMI 8 comprend donc un module de sélection SEL, un module client HAS et un module de zapping ZAP. La clef HDMI 8 peut être pilotée via une télécommande du téléviseur 5 ou via une application logicielle de commande d’un téléphone intelligent 3 ou de la tablette 4. Selon la méthode classique de téléchargement en HAS, préalablement à la restitution d’un premier contenu numérique C1, l’utilisateur, via l’association du téléviseur 5 et de la clef HDMI 8, envoie une requête, qui transite par la passerelle domestique 6 (non représentée), indiquant le contenu choisi au serveur de contenu « HAS » 2. Le serveur de contenu « HAS » 2 envoie alors en réponse à cette requête un flux de données représentatif du contenu choisi via la passerelle domestique 6 (non représentée). Le serveur de contenu « HAS » 2 expose un contenu numérique C1 sous forme de fragments, ou « chunks » C1i@Dj encodés à différents débits d’encodage Dj, où l’indice i désigne un identifiant temporel, ou position, du « chunk » C1i@Dj. Selon l’art antérieur, le module client HAS est chargé de venir récupérer les « chunks » auprès du serveur de contenu « HAS » 2 en choisissant la qualité vidéo Dj en fonction de la ressource réseau disponible. On ne décrit pas ici plus en détail la façon dont le module client HAS choisit le débit d’encodage du prochain fragment 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 fragment au débit d’encodage le plus faible proposé dans le manifeste, et sur l’évaluation du temps de récupération de ce premier fragment. Sur cette base, le module client HAS évalue si, en fonction de la taille du fragment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le fragment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des fragments de contenu téléchargés ; d’autres proposent des approches plus risquées, avec des sauts dans les niveaux des débits d’encodage des fragments successifs. Dans un cas classique, si un « chunk » vidéo dure 4 secondes, la récupération du « chunk » par le module HAS ne doit pas excéder 4 secondes, afin de permettre une restitution sans interruption du contenu. Il convient donc pour le module HAS d’opérer le meilleur compromis entre une qualité de restitution, et donc un débit d’encodage, aussi élevés que possible, et le temps de téléchargement du fragment, qui doit être suffisamment faible pour permettre une restitution en continu sur le téléviseur 5 par exemple. Au cours d’une étape E1, le module client HAS récupère le fichier manifeste 71 afin de découvrir les fragments disponibles du contenu numérique C1, et les différentes qualités vidéo Dj associées. Dans cet exemple, le contenu numérique C1 est par exemple proposé sous forme de fragments de durée 4s, avec un premier débit d’encodage D1 = 400 kb/s, un deuxième débit d’encodage D2 = 800 kb/s, un troisième débit d’encodage D3 = 1200 kb/s, un quatrième débit d’encodage D4 = 2100 kb/s et un cinquième débit d’encodage D5 = 3000 kb/s. Dans un mode de fonctionnement classique, le module client HAS opère le téléchargement par exemple, des fragments successifs C1 1 @D1 (soit le premier fragment temporel à un débit d’encodage de 400 kb/s), puis C1 2 @D5 (soit le deuxième fragment temporel à un débit d’encodage de 3000 kb/s), jusqu’à une lecture en mode normale en haute qualité d’une vidéo C1i@D5 (soit le i-ième fragment temporel à un débit d’encodage de 3000kb/s). L’algorithme mis en œuvre par le module client HAS pour déterminer quel fragment à quel débit d’encodage doit être téléchargé en mode de fonctionnement normal (c’est-à-dire en dehors des périodes où il est piloté par le module de sélection SEL) 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. Les différents fragments téléchargés par le module client HAS sont ensuite transmis dans une étape E2 au téléviseur 5 via la clef HDMI 8 par exemple pour leur restitution à l’utilisateur. Au cours de la visualisation du premier contenu numérique C1, comme par exemple un film, sur son téléviseur 5 associé à la clef HDMI 8, l’utilisateur peut décider à tout moment d’arrêter sa visualisation pour basculer sur un nouveau contenu numérique, ou second contenu numérique C2. C’est le cas par exemple lorsque l’utilisateur est en train de visionner un film et qu’une coupure publicitaire interrompt son film. Il peut alors décider de zapper la publicité et de regarder un autre contenu numérique, par exemple sur une autre chaîne télévisuelle, en attendant de reprendre son film. Ainsi, dans une étape E3, l’utilisateur émet une commande de zapping d’un premier contenu numérique C1 à un second contenu numérique C2. L’émission de cette commande peut se faire soit par un déplacement dans un guide des programmes de contenu numérique, soit par une saisie d’un identifiant du second contenu numérique C2 sur un clavier numérique, cet identifiant comprenant au moins un caractère alphanumérique. Le déplacement dans le guide des programmes de contenu numérique peut s’effectuer par exemple en appuyant sur les touches prévues à cet effet sur une télécommande du téléviseur 5 (comme par exemple les touches P+ ou P-) ou en balayant l’écran tactile de la tablette 4 ou du smartphone 3. Dans un autre exemple, la commande de zapping se fait plus directement via la sélection d’un contenu numérique par saisie de l’identifiant du second contenu C2 sur un clavier numérique. Cet identifiant peut être une suite de caractères alphanumériques comme par exemple le numéro de la chaîne ou le numéro de l’épisode d’une série. Cette saisie se fait par exemple via la télécommande du téléviseur 5 ou directement sur l’écran tactile du smartphone 3 ou de la tablette 4. À l’issue de cette étape E3, le module de zapping ZAP reçoit une requête de zapping REQ_ZAP du premier contenu numérique C1 à un second contenu numérique C2. Dans une étape E4, le module de zapping ZAP, via le module client HAS, envoie une requête REQ_Manifest_C2, contenant une demande de récupération du fichier manifeste 72 du second contenu numérique C2 au serveur de contenus « HAS » 2. Dans une étape E5, en réponse à cette requête, le serveur de contenu « HAS » 2 envoie un flux de données représentatif du second contenu numérique C2 choisi au module client HAS, qui récupère alors le fichier manifeste 72. Le serveur de contenu « HAS » 2 expose le second contenu numérique C2 sous forme de fragments, C2i@Dj encodés à différents débits d’encodage Dj, où l’indice i désigne un identifiant temporel, ou position, du « chunk » C2i@Dj. À l’issue de cette étape E5, un temps de latence TLat correspondant au temps qui s’est écoulé entre l’émission de la commande de zapping par l’utilisateur et l’obtention des premiers octets du fichier manifeste 72 par le module client HAS, du second contenu C2 à télécharger est mesuré. Par souci de simplification, on assimilera l’instant d’émission de la commande de zapping par l’utilisateur à l’instant de réception de la requête de zapping REQ_ZAP par le module de zapping ZAP. Ainsi, le temps de latence TLat correspond au temps qui s’écoule entre la réception de la requête REQ_ZAP par le module de zapping ZAP et l’obtention des premiers octets du fichier manifeste 72 par le module client HAS. Ce temps de latence TLat est incompressible et dépend d’une part de la bande passante au moment du zapping, mais également du temps que met le serveur de contenus « HAS » 2 à envoyer le fichier manifeste 72 du second contenu C2 au module client HAS. Au cours d’une étape E6, le module client HAS identifie les fragments disponibles du contenu numérique C2, et les différentes qualités vidéo Dj associées. Dans cet exemple, le contenu numérique C2 est par exemple proposé sous forme de fragments de durée 4s, avec un premier débit d’encodage D1 = 400 kb/s, un deuxième débit d’encodage D2 = 800 kb/s, un troisième débit d’encodage D3 = 1200 kb/s, un quatrième débit d’encodage D4 = 2100 kb/s et un cinquième débit d’encodage D5 = 3000 kb/s. Dans une étape E7, le module de sélection SEL sélectionne un débit d’encodage du premier segment temporel du second contenu numérique C2 (C2 1 @Dj) à télécharger, en fonction : - de la bande passante disponible au moment du zapping, - d’un temps de zapping cible définissant un plafond de temps de zapping raisonnable à ne pas dépasser afin de proposer à l’utilisateur une expérience agréable. Ce temps de zapping cible prédéfini est identique quelles que soient les conditions de bande passante et de ressource du réseau de communication de l’utilisateur et du serveur de contenus 2. Dans un exemple, ce temps de zapping cible est de 2 secondes, valeur qui garantit une bonne expérience utilisateur au niveau du temps d’attente entre l’émission de la commande de zapping et la restitution sur le téléviseur 5 du nouveau contenu numérique. Ainsi, le débit d’encodage du premier segment temporel C2 1 @Dj du second contenu numérique C2 est sélectionné de manière à ce que le temps de zapping TZap, c’est-à-dire le temps qui s’écoule entre la réception de la requête RAQ_ZAP par le module de zapping ZAP, et le début de la restitution sur le téléviseur 5 du second contenu numérique C2, ne dépasse pas le temps de zapping cible, ou temps de zapping maximal. Le temps de zapping TZap prend également en compte le temps de latence TLat mesuré à l’issue de l’étape E5. Dans un exemple de sélection de la qualité d’encodage du premier segment C2 1 @Dj du second contenu C2, le temps de zapping cible est fixé à 2 secondes. Ainsi, le temps de zapping Tzap doit être inférieur ou égal au temps de zapping cible, c’est-à-dire 2 secondes, pour garantir une bonne expérience utilisateur. Le temps de latence TLat mesuré à l’issue de l’étape E5 est de 300 ms. La bande passante de l’utilisateur est mesurée en continu par le module client HAS. En effet, le module client HAS connaît les contraintes de bande passante courantes, selon la technique HAS classique. Dans cet exemple, la bande passante est mesurée à 4Mbs/s. Dans le fichier manifeste 72, il existe 5 qualités différentes (D1 à D5) et les segments temporels ont une durée de 4 secondes. Le module de sélection SEL va alors piloter le module client HAS pour l’obliger à télécharger le premier segment temporel C2 1 @Dj du second contenu numérique C2 à la qualité Dj permettant de ne pas dépasser le temps de zapping cible prédéfini. Ainsi, dans notre exemple, la qualité d’encodage Dj à sélection pour le segment C2 1 correspond à : Le module de sélection SEL va donc sélectionner la qualité D3 de 1200 kbs/s de manière à ce que le temps de zapping TZap soit inférieur ou égal au temps de zapping cible de 2 secondes. Dans un mode de réalisation de l’invention, le temps de zapping cible résulte d’un choix exprimé par un utilisateur via une interface E/S d’un terminal de restitution, comme par exemple le téléviseur 5. Dans un exemple, l’utilisateur peut, via l’interface E/S du téléviseur 5, sélectionner soit le temps de zapping cible prédéfini par le constructeur (par exemple 2 secondes), soit le modifier en fonction de ses préférences. Dans un premier exemple, l’utilisateur peut sélectionner un temps de zapping cible plus court (par exemple 1 seconde) et donc favoriser le téléchargement du premier segment temporel du second contenu numérique C2 à une moins bonne qualité (par exemple 400 kbs/s C2 1 @D1). Dans un second exemple, l’utilisateur peut choisir un temps de zapping cible plus long (par exemple 4 secondes), afin de favoriser la sélection du premier segment temporel du second contenu numérique C2 à une meilleure qualité (par exemple le segment à 3000 kbs/s C2 1 @D5). Dans un autre mode de réalisation, le choix exprimé par l’utilisateur dépend d’une nature d’un contenu numérique. Dans un exemple, l’utilisateur peut choisir en fonction de la nature du contenu numérique (par exemple film, documentaire, sport…) le temps de zapping cible. En d’autres termes, lorsque l’utilisateur a un intérêt particulier pour un contenu d’une certaine nature, comme par exemple un film, il peut choisir un temps de zapping cible plus long afin de s’assurer que la meilleure qualité de contenu est téléchargée. Au contraire, lorsque la qualité du contenu n’a que peu d’intérêt pour l’utilisateur (par exemple journal télévisuel), il peut alors préférer un temps de zapping plus court et donc télécharger le nouveau contenu à un débit d’encodage faible. Dans une autre variante de réalisation, le temps de zapping cible est fixé par le constructeur du terminal lecteur de flux multimédia en fonction de la nature du contenu numérique (par exemple 2 secondes pour un contenu numérique en temps réel, et 4 secondes pour un contenu numérique en différé, par exemple une vidéo à la demande). Dans une étape E8, le module client HAS, piloté par le module SEL, est chargé de venir récupérer les segments temporels auprès du serveur de contenu « HAS » 2 en choisissant la qualité vidéo D3 imposée en fonction de la ressource réseau disponible et du temps de zapping cible. Dans une étape E9, le module client HAS, resitue le premier fragment C2 1 @D3 au niveau du téléviseur 5. Les prochains fragments sont ensuite téléchargés et restitués selon la technique classique de téléchargement HAS. Le procédé selon l’invention permet ainsi d’optimiser la qualité d’encodage du second contenu numérique C2 à restituer, pour favoriser la meilleure qualité d’expérience possible, sans impact sur le temps de zapping, puisque celui-ci est limité par un temps de zapping cible à ne pas dépasser. ANNEXE 1 : exemple de fichier manifeste Procédé de gestion de zapping d’un premier (C1) à un second (C2) contenu numérique, lesdits premier et second contenus numériques étant obtenus par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia (3, 4, 8 ; 9), lesdits premier et second contenus numériques étant respectivement associés à un fichier de description (7), comprenant une liste de segments temporels (CX i @D j ) dudit contenu associés chacun à plusieurs débits d’encodage dudit contenu, ledit procédé comprenant : - une réception (E3) d’une requête de zapping (REQ_ZAP) dudit premier contenu numérique (C1) vers ledit second contenu numérique (C2), - une obtention (E4) dudit fichier de description (72) dudit second contenu numérique, caractérisé en ce qu ’il comprend également : - une sélection (E7) d’un débit d’encodage d’un premier segment temporel dudit second contenu numérique à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par ledit terminal lecteur de flux multimédia, et d’autre part d’un temps de zapping cible, - un téléchargement (E8) dudit premier segment temporel dudit second contenu numérique audit débit sélectionné. Procédé de gestion de zapping selon la revendication 1, caractérisé en ce que ledit débit d’encodage sélectionné correspond à un débit d’encodage pour lequel un temps de zapping (TZap) dudit premier audit second contenu est inférieur ou égal audit temps de zapping cible. Procédé de gestion de zapping selon la revendication 2, caractérisé en ce que ladite sélection (E7) d’un débit d’encodage prend en compte un temps de latence (TLat) nécessaire à ladite obtention dudit fichier de description (72) dudit second contenu numérique (C2). Procédé de gestion de zapping selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ladite requête de zapping (REQ_ZAP) appartient au groupe comprenant : - un déplacement dans un guide des programmes de contenu numérique ; - une saisie d’un identifiant dudit second contenu numérique sur un clavier numérique, ledit identifiant comprenant au moins un caractère alphanumérique. Procédé de gestion de zapping selon l’une quelconque des revendications 1 à 4, caractérisé en ce qu’ il comprend une étape de paramétrage dudit temps de zapping cible par un utilisateur via une interface d’un terminal de restitution. Procédé de gestion de zapping selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit temps de zapping cible dépend d’une nature dudit second contenu numérique. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé d’un changement de contenu numérique obtenu par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia selon l'une quelconque des revendications 1 à 6, lorsqu’il est exécuté par un processeur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 7. Dispositif de gestion de zapping d’un premier à un second contenu numérique, lesdits premier et second contenus numériques étant obtenus par téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia, lesdits premier et second contenus numériques étant respectivement associés à un fichier de description, comprenant une liste de segments temporels dudit contenu associés chacun à plusieurs débits d’encodage dudit contenu, ledit dispositif comprenant : - un module (ZAP) de réception d’une requête de zapping dudit premier contenu numérique vers ledit second contenu numérique, - un module d’obtention dudit fichier de description dudit second contenu numérique, caractérisé en ce qu ’il comprend également : - un module de sélection (SEL) d’un débit d’encodage d’un premier segment temporel dudit second contenu numérique à télécharger, en fonction, d’une part d’une contrainte de ressource obtenue par ledit terminal lecteur de flux multimédia (9), et d’autre part d’un temps de zapping cible, - un module de téléchargement (HAS) dudit premier segment temporel dudit second contenu numérique audit débit sélectionné. Terminal lecteur de flux multimédia (9), caractérisé en ce qu ’il comprend un dispositif de gestion de zapping selon la revendication 9.