Brevet FR3020542A1 — publié le 20151030

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 d'une représentation particulière du 20 contenu. Etat de la technique Pour accéder à un contenu multimédia, un terminal client a généralement recours à une adresse universelle (URI). Une telle adresse fournit à la fois un accès au contenu et des indications sur le protocole associé pour le 25 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 30 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 (appelés segments médias par l'homme du métier). 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 ; selon un second mode, la sélection est à la charge du serveur. Selon le premier 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 terminal 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 . Dans le deuxième mode, la représentation est choisie par le serveur ou un composant quelconque d'une plate-forme de diffusion (ex : proew CDN). Dans cette configuration, le contenu adressé au client peut correspondre à un segment d'un débit différent de celui demandé par le client, et ceci pour s'adapter aux conditions réseau par exemple. Les inventeurs ont constaté que ce mécanisme pose problème au terminal car les paramètres de décodage sont potentiellement différents d'une représentation (débit) à une autre, et le terminal n'a alors aucun moyen de savoir que le segment reçu correspond à une représentation différente de celle demandée. Il en résulte des erreurs dans le décodage des segments reçus. 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 et décodé par le terminal, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une étape de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation apte à être prise en compte avant le décodage du segment reçu. Grâce à cette solution, la représentation des segments transmis par le serveur est toujours une représentation souhaitée par le serveur ; le serveur a donc la maîtrise du choix des représentations ; de plus, le terminal est prévenu du changement de représentation fait par le serveur par le biais d'une information indiquant ce changement. Le terminal peut alors prendre en compte l'information et adapter son fonctionnement notamment en paramétrant correctement les paramètres liés au décodage des segments reçu ; ce sans entraîner des erreurs de décodage et donc de restitution du segment lié au fait que la représentation des segments reçus n'est pas compatible avec le paramétrage courant utilisé pour le décodage des segments média. Cette solution évite aussi une mise à jour du fichier de description. Le segment reçu selon la deuxième représentation est transmis dans un message incluant un entête http et une partie utile incluant le segment. Selon un premier mode de réalisation, l'information est incluse dans l'entête http. Un segment inclut une première partie incluant des champs et une seconde partie incluant au moins un segment codé. Selon un second mode de réalisation, l'information est incluse dans un champ (B-evt) de ladite première partie. Les modes de réalisation décrits ci-dessus ont pour avantage de rendre possible la lecture de l'information avant le début de décodage dudit au moins un segment. Selon un aspect matériel, l'invention se rapporte à 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 module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu. On comprend ici que le module de traitement prend en compte l'information indiquant la représentation choisie par le serveur de manière à décoder ledit au moins un segment reçu sans générer d'erreurs de décodage. Selon un autre aspect fonctionnel, l'invention se rapporte à un 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 étape de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième 20 représentation. Selon un autre aspect matériel, l'invention se rapporte à un serveur apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un module de réception d'une requête d'accès à au moins un segment 25 selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation. Selon un autre aspect matériel, l'invention se rapporte à un programme 30 d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes du procédé s'exécutant sur le terminal définies ci-dessus. Selon un autre aspect matériel, l'invention se rapporte à un programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes du procédé s'exécutant sur le serveur définies ci-dessus. 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 un exemple de réalisation de la composition d'un flux de données transmis par le serveur à destination du terminal suite à une demande du terminal de recevoir des segments. 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 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 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.). A noter que l'expression « terminal client » sous-entend la présence dans le terminal d'un module client. Dans notre exemple, ce module client est un programme d'ordinateur. 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 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 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. 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 appropriée pour construire la première adresse universelle (URL ou URI) du segment de média. Cette résolution d'adresse 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 premier segment, l'une correspondant à un débit de 500kbps l'autre à 2000kbps 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). 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 décoder les segments reçus et les restituer. Lors d'une septième étape ET7, le terminal (1) requiert un accès 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 le second segment F2/500k, incluant le second segment avec un débit inférieur à celui demandé par le terminal (1). En d'autres mots, la représentation fournie par le serveur ne correspond pas à celle demandée par le terminal. Le débit choisi par le serveur correspond au débit v1 (500k) si on se réfère au fichier de description à l'annexe 1. Selon l'invention, en complément d'un segment transmis, le serveur fournit également au terminal une information relative à la représentation du segment transmis. Cette information a pour vocation d'être lu avant le décodage du segment reçu de manière à ce que les paramètres de décodage soit adapté au segment reçu. Rappelons que, dans la norme MPEG DASH, le serveur transmet des segments sous forme de réponse http, au moyen d'un entête http et d'une partie utile (appelée payload dans la norme). Dans notre exemple de réalisation, la fourniture de l'information relative à la représentation choisie par le serveur peut s'effectuer de différentes manières. Deux variantes vont illustrer deux cas possibles. Selon une première variante, par exemple, l'information sur la représentation peut être insérée dans l'en-tête http de la réponse du serveur au terminal. L'entête est par exemple le suivant : HTTP/1.1 200 OK Date: Tue, 15 Apr 2014 09:16:16 GMT Server: Apache/2.2.25 (Win32) Last-Modified: Tue, 24 Dec 2013 15:02:48 GMT ETag: "200000004b4ee-cda-4ee49099b12b2" Accept-Ranges: bytes Content-Length: 3290 Access-Control-Allow-Origin: * Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain Representation: 'v1' Dans notre exemple, un champ nommé arbitrairement « représentation » indique la représentation transmise par le serveur. La valeur « v1 » correspond à une valeur définie dans le fichier de description (voir annexe 1). Si la valeur n'est pas présente dans le fichier de description, le champ « Représentation » peut fournir la valeur exacte du débit utilisé. En d'autres mots, ce champ « Representation » est ajouté pour indiquer la représentation à laquelle appartient le segment contenu dans la payload (partie utile) de la réponse http. Une autre manière d'informer le client de la représentation choisie par le serveur, correspondant à une deuxième variante, est d'insérer l'information dans le segment média, plus précisément dans un champ nommé « box Event » inclut dans le segment SG. Rappelons en effet que, en référence à la figure 5, dans la norme MPEG DASH, un segment média SG comprend : - une partie HD incluant des champs HD nommés « box Event » - Une partie utile nommée DATA qui comprend des données encodées.. Rappelons que le champ nommé «Box Event » est décrit dans la norme MPEG DASH. Rappelons aussi que MPEG DASH (pour Dynamic Adaptive Streaming over HTTP - norme ISO/IEC 23009-1:2012(E)) de l'organisme de normalisation ISO/IEC est dédié au streaming de contenus multimédia sur Internet. Cette norme est incorporée par référence. Dans cette configuration, En référence à la norme MPEG DASH, l'indication de représentation peut être insérée dans un champ nommé « box Event » de la partie HD. De cette manière, A réception du segment SG, le terminal interprète dans un premier temps ces champs 'Box Event » » et peut alors adapter le paramétrage pour le décodage du segment reçu (F2/500k). Dans notre exemple, à la suite des champs HD, se trouvent les données encodées du segment courant. A noter que ces champs ne se trouvent pas au début de la trame dans tous les cas, mais peuvent se trouver ailleurs dans le segment. Suite à l'envoi du serveur du flux F2/500k, celui est reçu par le terminal. La suite du procédé est fonction de la variante choisie. Si la première variante a été choisie, lors d'une étape, le terminal extrait l'information représentative de la représentation. Après extraction, le terminal adapte les paramètres de décodage et décode ensuite le segment et le restitue. Si la deuxième variante a été choisie, le terminal interprète ensuite le segment média. En interprétant ce dernier, le terminal interprète dans un premier temps les champs dits « box Event » inclus dans le segment et dans un second temps le segment. Le terminal a donc connaissance de la représentation et peut donc adapter le paramétrage du décodage comme pour la première variante. On comprend donc ici qu'à ce stade du procédé, le terminal a connaissance de la représentation choisie par le serveur et qu'il peut en conséquence adapter son fonctionnement pour le décodage. 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 module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu. 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 module de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à 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 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 et décodé par le terminal, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une étape de transmission (ET7) d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de réception (ET8) dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation apte à être prise en compte avant le décodage du segment reçu. 2. Procédé de gestion selon la revendication 1, caractérisé en ce que le segment reçu selon la deuxième représentation est transmis dans un message incluant un entête http et une partie incluant le segment, et en ce que l'information est incluse dans l'entête http. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'un segment (SG) inclut une première partie (HD) incluant au moins un champs (N1,N2,...) et une seconde partie (DATA) incluant au moins un segment codé , caractérisé en ce que l'information est incluse dans un champs (N1,N2,...) de ladite première partie. 4. 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 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 module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie,- un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu. 5. 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 étape de réception (ET7) d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de transmission (ET11) dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation. 6. Serveur (8) apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un module de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation. 7. 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 à 3. 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 la revendication 5.