Brevet FR3002105A1 — publié le 20140815

Procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication. Domaine technique L'invention se rapporte à un procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication. On entend par contenu multimédia tout contenu audio ou vidéo, ou plus généralement tout autre contenu numérique. L'invention concerne plus spécifiquement la transmission et la réception de contenus multimédia sur un réseau, en particulier le téléchargement continu, aussi appelé streaming, de contenus multimédia sur un réseau. Elle concerne plus précisément une communication utilisant des adresses universelles de contenus. Elle s'applique notamment à tout terminal client (dans la suite appelé simplement terminal) capable de communiquer sur un réseau de télécommunications pour accéder à un contenu multimédia via une adresse universelle, aussi appelée URI (de l'anglais Uniform Ressource identifier). On entend ici par représentation d'un contenu, une façon particulière de créer un flux de données représentatif d'un contenu. Un flux de données créé avec un débit d'encodage est un exemple une représentation particulière du contenu. Etat de la technique Pour accéder à un contenu multimédia, un terminal client a généralement recours à une adresse universelle, ou URI. Une telle adresse fournit à la fois un accès au contenu et des indications sur le protocole associé pour le consommer (par consommer, on entend par exemple, dans le cas d'un contenu vidéo, télécharger/recevoir le contenu pour ensuite éventuellement le décoder, puis le visualiser). Une adresse URI est une chaîne de caractères identifiant une ressource physique ou abstraite. La syntaxe d'une adresse URI respecte un ensemble de normes édictées par l'IETF (Internet Engineering Task Force), et notamment la spécification RFC 3986 (spécification : Uniform Resource Identifier (URI); Generic Syntax). Une telle adresse universelle prendra par exemple la forme dvb://contenu1, rtsp://contenu2, HTTP://contenu3, ftp://contenu4, etc. L'accès au contenu multimédia est déclenché par une requête, au travers d'une adresse URI. Une illustration classique en est un service de vidéo à la demande : - une première étape consiste pour le terminal à télécharger un document décrivant les paramètres d'accès au service (SDP pour Session Description Protocol) via un protocole HTTP (de l'anglais Hyper Text Transport Protocol un protocole de communication client-serveur développé pour les réseaux Internet et en particulier le Web ; - lors d'une seconde étape, le service démarre effectivement, c'est-à-dire que le terminal client peut recevoir et afficher la vidéo, grâce aux informations fournies dans le document (dans cet exemple, le SDP). On notera que ce document peut être un fichier informatique ou un ensemble d'informations descriptives du contenu accessible à une certaine adresse. Dans la suite, on se réfèrera selon le contexte à l'expression « fichier de description » ou « document ». On notera que ce type d'accès au service peut nécessiter la présence d'un serveur (notamment dans le cas d'une communication point à point ou « unicast ») ou non (dans le cas d'une communication point vers multipoint de type « broadcast » ou « multicast »). Notamment, le protocole HTTP est de type point à point (« unicast »), et implique de ce fait la présence d'un serveur afin de traiter la requête d'un client dit client HTTP. Il est fréquent, dans ce contexte du protocole HTTP, de recourir, pour échanger les données entre le client et le serveur, à une technique de type « HTTP adaptive streaming ». Ce type de technique permet notamment d'offrir une bonne expérience utilisateur tout en tenant compte par exemple des variations de bande passante sur la liaison entre le terminal client et le serveur de contenu. Classiquement, différentes qualités peuvent être encodées pour la même vidéo, correspondant par exemple à différents débits. Chaque débit est lui-même découpé en segments temporels (ou « fragments » de contenu). La description de ces différents débits et de la segmentation, ainsi que les fragments de contenu, sont mis à disposition du terminal client sur une plateforme de service. Pour pouvoir accéder au contenu complet, il est donc nécessaire de connaître de nombreuses adresses (URI) correspondant à de multiples segments. Il existe plusieurs solutions pour faciliter la distribution d'un tel contenu en mode streaming. Ces méthodes proposent d'adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents, ou manifests, ou encore ressources, contenant les adresses des différents segments aux différentes qualités du contenu multimédia. Le principe de base de ces méthodes est de mettre à disposition des contenus avec différentes variantes de débit, chacune des variantes étant disponible sous forme de segments contigus de données média qui sont téléchargeables par les clients à l'aide du protocole HTTP. La lecture d'un contenu selon la technique « HTTP adaptative streaming » pour un terminal client donné consiste à : - télécharger et analyser le document de description qui donne la description du contenu, les variantes de débits disponibles, et les moyens d'accéder aux segments de données pour chaque variante de débit ; - télécharger les segments de données, et pour chaque segment sélectionner une représentation particulière, en particulier sélectionner un débit d'encodage du segment à télécharger ; - puis analyser et rassembler les segments de données afin de les décoder pour lire le contenu. Il existe deux modes de sélection (ou d'adaptation) de la représentation des segments. Selon un premier mode, la sélection est à la charge du terminal client. Dans ce mode, c'est au terminal client de sélectionner la représentation pour chaque segment de données média en fonction de paramètres internes au client (ex : bande passante mesurée, capacités du terminal, etc.) ; en particulier, le terminal client sélectionne pour chaque segment un débit d'encodage donné. Si la bande passante mesurée par le client est suffisante, le client sélectionnera le plus souvent un débit d'encodage élevé. Cependant, le fait de laisser la décision d'adaptation uniquement au client empêche le distributeur de contenu d'avoir une maîtrise de sa plate-forme (serveurs), de son réseau, et des services. Le risque majeur pour le distributeur est d'avoir à servir un nombre trop élevé de requêtes d'accès aux segments avec un débit d'encodage élevé. La conséquence serait une saturation de la bande passante réseau ou des serveurs HTTP. Il peut également en résulter une baisse de la qualité de restitution sur le terminal client se manifestant par exemple par des gels d'image. Selon un deuxième mode, la sélection est à la charge du serveur qui diffuse (ou distribue) le contenu sur le réseau. Dans cette configuration, une solution consiste en une insertion, dans les données d'un segment diffusé, d'une information relative à une demande de modification de la représentation, par exemple une demande de diminution du débit d'encodage. L'information peut être comprise dans un champ nommé « Event » décrite dans la norme MPEG DASH. MPEG DASH (pour Dynamic Adaptive Streaming over HTTP - norme ISO/IEC 23009-1:2012(E)) de l'organisme de normalisation ISO/IEC dédiée au streaming de contenus multimédia sur Internet ; Le problème lié à ce second mode est le temps de réaction pour mettre en oeuvre l'adaptation côté client. En effet, le client réceptionne entièrement un segment de données, l'analyse entièrement avant de prendre connaissance le nouveau manifest incluant une demande de modification de la représentation des segments. Le problème est que le manifest, qui inclut la demande de modification, n'est pas prise en compte pour le segment courant reçu dans le même flux que la demande de modification. En conséquence, cette solution implique non seulement une opération d'extraction du nouveau manifest dans le segment reçu, mais aussi une restitution du segment reçu avec une mauvaise qualité. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion de la représentation des segments de données d'un contenu reçu par un terminal depuis un serveur, le procédé comportant une étape d'obtention d'un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation du segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, le segment étant apte à être reçu depuis le serveur selon la représentation choisie, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une première étape de transmission d'une requête d'accès à un premier segment selon une première représentation choisie, - une première étape de réception d'une réponse à la requête incluant une demande de modification de la première représentation ; - une deuxième étape de transmission d'une requête d'accès au premier segment selon une deuxième représentation ; - une deuxième étape de réception depuis le serveur du premier segment selon la deuxième représentation. Ainsi, la représentation des segments transmis par le serveur est toujours une représentation souhaitée par le serveur. Si un segment est reçu avec une représentation qui n'est pas une représentation souhaitée par le serveur, ce dernier, au lieu de transmettre le segment concerné, requiert au terminal client, par le biais de la demande de modification, une retransmission depuis le terminal d'un segment avec une autre représentation. Le serveur reçoit l'adresse URI avec la nouvelle représentation souhaitée ; ce n'est qu'à ce moment-là que serveur transmet le segment concerné vers le terminal avec la nouvelle représentation. La demande de modification visée ci-dessus est transmise dans un message distinct du flux de données qui véhicule les segments. Il n'y a donc pas d'impact sur la qualité des segments reçus. Aussi, en référence à une solution employée dans l'état de la technique, l'invention évite l'analyse d'un flux de données contenant les segments de données pour y extraire un nouveau fichier de description. Selon un premier mode de réalisation, la représentation inclut une valeur de débit d'encodage du segment et en ce que la première et la deuxième représentation incluent des valeurs différentes. Selon un second mode de réalisation, la demande de modification de la première représentation est prise en compte par le terminal pendant une durée donnée. Le fait, pour le terminal, de prendre en compte la demande modification pendant un intervalle de temps donné, évite au serveur de contenus d'émettre une demande de modification plusieurs fois de suite. Selon un troisième mode de réalisation, la demande de modification est transmise selon le protocole HTTP. Cette caractéristique évite une mise à jour complète du fichier de description. L'utilisation du protocole HTTP permet une écriture rapide de la demande de modification. Les segments étant transmis par exemple toutes les 2 secondes par le serveur, cette caractéristique évite une attente d'un nouveau manifest dont la fréquence de transmission depuis le serveur est plus importante, généralement de 30 secondes. Plus particulièrement, la demande est un message http comprenant un code numérique du type défini dans la norme RFC 2616. Le code numérique est reçu par le terminal client qui en déduit grâce à une table de correspondance une information, dans notre exemple une consigne liée à la représentation d'un segment. Selon un aspect matériel, l'invention a trait à un terminal apte à recevoir des segments d'un contenu, le terminal ayant accès à un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation d'un segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, caractérisé en ce qu'il comprend - un premier module de transmission d'une requête d'accès à un premier segment selon une première représentation choisie, - une premier module de réception d'une réponse à la requête incluant une demande de modification de la première représentation, - un deuxième module de transmission d'une requête d'accès au premier segment selon une deuxième représentation ; - un deuxième module de réception depuis le serveur du premier segment selon la deuxième représentation. Selon un autre aspect matériel, l'invention a trait à un programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies ci-dessus. L'invention a aussi trait au support d'enregistrement lisible par un terminal sur lequel est enregistré ce programme Selon un autre aspect fonctionnel, l'invention a trait à un procédé d'émission de segments d'un contenu selon une représentation respective donnée, caractérisé en ce qu'il comprend - une première étape de réception d'une requête d'accès à un premier segment selon une première représentation choisie, - une première étape de transmission d'une réponse à la requête incluant une demande de modification de la première représentation ; - une deuxième étape de réception d'une requête d'accès au premier segment selon une deuxième représentation ; - une deuxième étape d'émission depuis le serveur du premier segment selon la deuxième représentation. Selon un autre aspect fonctionnel, l'invention a trait à un programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans le procédé d'émission décrit ci-dessus. L'invention a aussi trait au support d'enregistrement lisible par un serveur sur lequel est enregistré ce programme. Selon un autre aspect matériel, l'invention a trait à un serveur apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un premier module de réception d'une requête d'accès à un premier segment selon une première représentation choisie, - un premier module de transmission d'une réponse à la requête incluant une demande de modification de la première représentation ; - un deuxième module de réception d'une requête d'accès au premier segment selon une deuxième représentation ; - un module de transmission depuis le serveur du premier segment selon la deuxième représentation. 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. Les figures: La figure 1 représente une architecture de streaming basée sur l'utilisation du protocole HTTP sur Internet selon un mode de réalisation de l'invention. Les figures 2 et 3 représentent les circuits des équipements impliqués dans le procédé de l'invention. La figure 4 représente un chronogramme selon un mode de réalisation de l'invention. La figure 5 représente également un chronogramme illustrant une variante du mode de réalisation décrit en référence à la figure 4. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système informatique SYS incluant un terminal client 1, une plateforme de service 3, et un serveur de contenus 8, apte à fournir un contenu sur requête du terminal client 1. Dans notre exemple de réalisation, le terminal, la plateforme et le serveur communique via un réseau Internet 2. En référence à la figure 2, le terminal 1 comprend des ressources physiques et/ou logicielles, en particulier : - un processeur CPU1, - un premier module de stockage MEM1, - un module de restitution tel qu'un écran ECR, - un premier module de communication COM1 pour communiquer avec le réseau 2. Les modules décrits ci-dessus ainsi que le premier microprocesseur CPU1 sont reliés entre eux par l'intermédiaire d'un premier bus BUS1. En référence à la figure 3, le serveur 8 comprend - un second processeur CPU2, - un second module de stockage MEM2, stockant notamment un ou plusieurs contenus CNT, - un second module de communication COM2 pour communiquer avec le réseau 2. Le second module, inclus dans le serveur, est relié au second processeur CPU2 par l'intermédiaire d'un second bus BUS2. A noter que les bus décrits ci-dessus ont pour fonction d'assurer le 25 transfert de données numériques entre les différents circuits reliés au microprocesseur par un bus. Dans notre exemple, le bus en question inclut un bus de données et un bus de contrôle. A noter aussi que, dans notre exemple, les mémoires décrites ci-dessus sont des mémoires permanentes accessibles en écriture et lecture, par exemple 30 de type flash. Les terminaux incluent également une mémoire vive (non représentée) respective pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon des modes de réalisation. Ces mémoires ne sont pas représentées sur les dessins car inutiles pour l'exposé de l'invention. Dans notre exemple, l'architecture choisie pour illustrer l'invention est une architecture dite streaming basée sur l'utilisation du protocole HTTP. Classiquement, le terminal client (1) souhaite entrer en communication avec un serveur de contenus (8) pour télécharger un contenu multimédia composé d'un ou plusieurs médias (audio, vidéo, etc.). Dans la suite de l'exemple, comme exposé ci-dessus, on se positionne dans un contexte de streaming selon la norme MPEG DASH. Le terminal (1) interroge tout d'abord une plateforme de service (3) pour obtenir l'adresse (ici, l'URL, mais de manière plus générale, une adresse 15 universelle de type URI) du document de description 4 du contenu multimédia (y) ; dans la suite, ce document est un fichier de type MPD (y.mpd). La plateforme de service (3) répond en fournissant au terminal l'adresse du fichier 4 ; dans l'exemple il s'agit de l'URL « HTTP://x.com/y.mpd » symbolisant un fichier y de type mpd qui peut être téléchargé sur le serveur de 20 contenus (8) « x.com ». Un exemple de fichier de description 4 conforme à la norme MPEG/DASH est présenté dans l'annexe 1. Les champs pertinents dans le contexte de l'invention, qui permettent notamment de générer les adresses universelles, sont présentés en italique. 25 Le fichier de description 4 permet de générer des adresses de segments de média Cette construction met en oeuvre un mécanisme préalable de résolution d'adresses universelles (URI) décrit dans la RFC 3986 mentionnée ci-dessus. Le terminal client doit interpréter certains champs et les modifier de manière 30 appropriée pour construire la première adresse universelle (URL ou URI) du segment de média. Cette résolution d'URI est faite selon l'élément BaseURL, qui peut être présent à différents niveaux de la hiérarchie du fichier 4. Dans cet exemple, les adresses URL sont construites à l'aide des deux champs « BaseUrl » (« HTTP:// x.com/ » et « video/ ») et « SegmentTemplate ». Le « SegmentTemplate » précisé par la norme MPEG/DASH est un procédé générique de construction des adresses (URI) intermédiaires à partir de différents identifiants, dans notre exemple : - $Time$ : à remplacer par le temps de début du segment de média. Ce temps est fourni par la « SegmentTimeline » qui indique ici un offset de 180180 pour chaque début de nouveau segment ; - $Number$ : à remplacer par le numéro d'ordre du segment de média désiré ; - $Bandwidth$ : à remplacer par la valeur de l'attribut « bandwidth » (bande passante) de la représentation ciblée. Ainsi, les deux premières adresses URL d'accès aux deux premiers segments vidéo pour une qualité (ou débit) de 500 kbps (Kilo Bits par seconde) sont ici : 1. HTTP:// x.com/video/500000/0.mp4v, et 2. HTTP:// x.com/video/500000/180180.mp4v A noter qu'à un même segment peut correspondre plusieurs représentations possibles. Ici, à chaque représentation correspond un débit respectif. Par exemple, HTTP:// x.com/video/500000/0.mp4v HTTP:// x.com/video/2000000/0.mp4v sont deux représentations possibles du second segment, l'une correspondant à un débit de 500kbps l'autre à 300kbps La figure 4 est une vue schématique des échanges ayant lieu entre le terminal, la plateforme et le serveur de contenus. On suppose que le terminal 1 souhaite recevoir un contenu (y). On suppose aussi que suite à la transmission du deuxième segment, le serveur de contenus requiert une baisse du débit d'encodage et que celui-ci soit inférieur à 2000 kbps. Lors d'une première étape ET1, le terminal 1 interroge la plateforme de service 3 pour obtenir l'adresse (ici, l'URL, mais de manière plus générale, une adresse universelle de type URI) du document de description 4 du contenu multimédia (y) ; dans la suite, ce document est un fichier de type MPD (y.mpd). Lors d'une deuxième étape ET2, la plateforme de service (3) répond en fournissant au terminal l'adresse du fichier 4, dans l'exemple il s'agit de l'URL « HTTP://x.com/y.mpd » symbolisant un contenu « y » de type « mpd » qui peut être téléchargé sur le serveur de contenus (8) « x.com ». Lors d'une troisième étape ET3, le terminal requiert REQ(4) auprès du serveur 8 un téléchargement du fichier de description 4. Lors d'une quatrième étape ET4, le terminal reçoit et stocke le fichier de description 4. Lors d'une cinquième étape ET5, le terminal (1) accède au premier segment grâce à la première URL1 décrite ci-dessus : HTTP:// x.com/video/2000000/0.mp4v. Lors d'une sixième étape ET6, le serveur 8 transmet un premier flux de données F1/2000k, incluant les premiers segments. A réception, le terminal peut restituer les premiers segments. Lors d'une septième étape ET7, le terminal (1) accède au second segment grâce à la seconde URL2 décrite ci-dessus : HTTP:// x.com/video/2000000/180180.mp4v. A réception de la demande de téléchargement du second segment, lors d'une huitième étape ET8, le serveur 8 transmet au terminal 1 une demande de modification du débit d'encodage. Dans notre exemple, la demande est incluse dans un message distinct du flux de données incluant les segments. La demande est illustrée au moyen d'une information requérant au terminal une diminution du débit d'encodage pour ce second segment. L'information est par exemple insérée dans un message d'erreur de type http. Le message d'erreur est par exemple le suivant : HTTP/1.1 500 Internai Server Error Age: 0 Date: Mon, 14 Jan 2013 14:04:43 GMT Content-Length: 0 Content-Type: video/mp4 Cache-Control: max-age=7200 Pragma: IISMS/4.0,IIS Media Services by Microsoft Server: Microsoft-IIS/7.5 IISMS/4.0 bandwidth: 500000 Supposons que l'information en question soit une valeur donnée d'un débit par exemple 500000 bps. Cette valeur peut être fournie dans le message d'erreur ou déduit par le terminal client à partir d'une base de correspondance par exemple stockée dans la première mémoire MEM1. Dans ce cas, à un code correspond non seulement une demande de modification de la représentation mais aussi une valeur donnée. Dans notre exemple, à la valeur 500 correspondrait la valeur de débit de 500kbps. Lors d'une neuvième étape ET9, le terminal 1 reçoit le message d'erreur ; le terminal interprète le code « 500 » et en déduit que le message est lié à une demande de modification de débit d'encodage. Le terminal interprète également l'information de diminution/limitation de débit d'encodage afin d'appliquer cette diminution par la suite. Lors d'une dixième étape ET10, le terminal 1 modifie l'adresse pour accéder au second segment en prenant en compte l'information reçue lors de la sixième étape. La nouvelle adresse résultante est donc dans notre exemple: HTTP:// x.com/video/500000/180180.mp4v. Le serveur de contenus reçoit la nouvelle demande d'accès au second segment avec un débit d'encodage à 200 kbps. Lors d'une onzième étape ET11, le serveur de contenus transmet un flux de données F2/500k incluant le segment avec un débit d'encodage à 200kbps. Le terminal reçoit ensuite le second segment et le restitue. Le procédé décrit ci-dessus peut faire l'objet de variantes. L'information décrite peut prendre plusieurs formes. Elle peut avoir une valeur fixe comme dans l'exemple décrit ci-dessus. Elle peut aussi correspondre à une valeur maximum à ne pas dépasser. Dans cette configuration, en supposant que l'information indique que le débit ne doit pas dépasser 1000kbps, la nouvelle adresse résultante à la huitième étape inclurait une valeur de débit inférieure à 1000kbps. Dans l'exemple qui précède l'information est incluse dans un message d'erreur HTTP. L'invention ne se limité bien évidemment pas au protocole HTTP mais peut s'étendre à tout autres protocoles. L'information peut aussi avoir une durée de vie limitée At. Cette variante est illustrée sur la figure 5. Sur cette figure, Les étapes ET1 à ET7 (non référencées) correspondent à celles décrites en référence à la figure 4. Les étapes ET8 à ET11 (représentées sur la figure 5) sont également identiques à celles décrites sur la figure 4. La suite des étapes sont référencées ET1-1 à ET1-4. Lors de l'étape ET1-1, le terminal (1) accède au troisième segment. La durée At n'ayant pas expiré, le terminal 1 tient compte de la demande de modification du débit reçue à la huitième étape ET8 et transmet la requête grâce à la première URL suivante décrite ci-dessus : HTTP:// x.com/video/500000/360360.mp4v. Lors d'une deuxième étape ET1-2, le serveur de contenus 8 transmet un troisième flux de données F3/500k incluant le segment avec un débit d'encodage à 500kbps. Le terminal reçoit ensuite le troisième segment et le restitue. Lors de l'étape ET1-3, le terminal (1) accède au quatrième segment. La durée At ayant pas expiré, le terminal 1 ne tient plus compte de la demande de modification du débit reçue à la huitième étape ET8. Le terminal consulte de nouveau le fichier de description afin de créer l'adresse URL du quatrième segment : HTTP:// x.com/video/2000000/720720.mp4v. Lors de l'étape ET1-4, le serveur de contenus 8 transmet un flux de données F3/2000k incluant des segments avec un débit d'encodage à 2000kbps. Le terminal 1 reçoit ensuite les segments et les restitue. Dans notre exemple, le message d'erreur inclut un code, voire plusieurs codes, indiquant le débit à utiliser et la durée At pendant laquelle ce débit doit être pris en compte. A expiration de la durée At, les adresses qui suivent se basent à nouveau sur le fichier de description 4 et sur les représentations ou débits initialement disponibles initialement à l'établissement de la session. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent y être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. A noter que pour la réalisation du procédé de l'invention, le terminal comprend, outre les éléments décrits ci-dessus en référence à la figure 2, - un premier module de transmission d'une requête d'accès à un premier segment selon une première représentation choisie, - un premier module de réception d'une réponse à la requête incluant une demande de modification de la première représentation, - un deuxième module de transmission d'une requête d'accès au premier segment selon une deuxième représentation ; - un deuxième module de réception depuis le serveur du premier segment selon la deuxième représentation. A noter aussi que pour la réalisation du procédé de l'invention, le serveur comprend, outre les éléments décrits ci-dessus en référence à la figure 3, - un premier module de réception d'une requête d'accès à un premier segment selon une première représentation choisie, - un premier module de transmission d'une réponse à la requête incluant une demande de modification de la première représentation ; - un deuxième module de réception d'une requête d'accès au premier segment selon une deuxième représentation ; - un module de transmission du premier segment selon la deuxième représentation. A noter que le te terme « module » utilisé dans ce document, peut correspondre soit à un composant logiciel, soit à un composant matériel, soit encore à un ensemble de composants matériels et/ou logiciels, aptes à mettre en oeuvre la ou les fonctions décrites pour le module. Annexe 1 HTTP:// xcom/ video/ Table 1: Exemple de fichier 4 de type MPD selon MPEG/DASH5 REVENDICATIONS1. Procédé de gestion de la représentation des segments de données (0.mp4v, 180180.mp4v) d'un contenu reçu par un terminal depuis un serveur, le procédé comportant une étape d'obtention (ET2) d'un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation du segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, le segment étant apte à être reçu depuis le serveur selon la représentation choisie, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal, - une première étape de transmission (ET7) d'une requête d'accès à un premier segment selon une première représentation choisie, - une première étape de réception (ET8) d'une réponse à la requête incluant une demande de modification de la première représentation ; - une deuxième étape de transmission (ET7) d'une requête d'accès au premier segment selon une deuxième représentation ; - une deuxième étape de réception (ET11) depuis le serveur du premier segment selon la deuxième représentation. 2. Procédé de gestion selon la revendication 1, caractérisé en ce que la représentation inclut une valeur de débit d'encodage du segment et en ce que la première et la deuxième représentation incluent des valeurs différentes. 3. Procédé selon la revendication 1, caractérisé en ce que la modification de la première représentation est prise en compte par le terminal pendant une durée donnée (At). 4. Procédé selon la revendication1, caractérisé en ce que la demande de modification est transmise selon le protocole HTTP. 5. Terminal (1) apte à recevoir des segments d'un contenu, le terminal ayant accès un document (4) à partir duquel sont générées des adressesuniverselles, à une adresse étant associée une représentation d'un segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, caractérisé en ce qu'il comprend - un premier module de transmission d'une requête d'accès à un premier segment selon une première représentation choisie, - une premier module de réception d'une réponse à la requête incluant une demande de modification de la première représentation, - un deuxième module de transmission d'une requête d'accès au premier segment selon une deuxième représentation ; - un deuxième module de réception depuis le serveur du premier segment selon la deuxième représentation. 6. Procédé d'émission, par un serveur, de segments d'un contenu selon une représentation respective donnée, caractérisé en ce qu'il comprend les étapes suivantes : - une première étape de réception d'une requête d'accès à un premier segment selon une première représentation choisie, - une première étape de transmission d'une réponse à la requête incluant une demande de modification de la première représentation ; - une deuxième étape de réception d'une requête d'accès au premier segment selon une deuxième représentation ; - une deuxième étape d'émission depuis le serveur du premier segment selon la deuxième représentation. 7. Serveur (8) apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un premier module de réception d'une requête d'accès à un premier segment selon une première représentation choisie,- un premier module de transmission d'une réponse à la requête incluant une demande de modification de la première représentation ; - un deuxième module de réception d'une requête d'accès au premier segment selon une deuxième représentation ; - un module de transmission du premier segment selon la deuxième représentation. 8. Programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans l'une des revendications 1 à 5. 9. Programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans la revendication 6. 20 25