Brevet FR2923970A1 — publié le 20090522

La présente invention concerne un procédé et un dispositif de formation de paquets de transport, un procédé et un dispositif de transfert de paquets de transport et un procédé et un dispositif de réception de paquets de transport encapsulant des données codées représentatives d'une séquence d'images. L'invention se situe dans le domaine technique du transport des données numériques représentatives de séquences d'images codées, dans un réseau de communication, issues d'un dispositif serveur vers une pluralité de dispositifs clients. On connaît dans l'état de la technique divers formats de codage d'images et de séquences vidéos permettant d'obtenir, à partir d'un flux de données codées, des sous-flux correspondant à des résolutions spatiales inférieures, des fréquences temporelles inférieures et des qualités inférieures. On appelle de tels formats des formats scalables. En particulier, le futur standard de compression vidéo hiérarchique SVC (Scalable Video Coding), décrit dans le document de T. Wiegand, G. Sullivan, J. Reichel, H. Schwarz, and M. Wien. Scalable Video Coding -Joint Draft 10 of SVC Amendment. Joint Video Team (JVT) of ISO/IEC MPEG & ITUT VCEG, San Jose, California, April 2007, Document JVT-W201, est une extension du standard vidéo H.264, apportant des nouvelles fonctionnalités de scalabilité spatiale, temporelle et en qualité, tout en maintenant un excellent taux de compression. En utilisant le format de compression SVC, il est possible, par exemple, de coder une vidéo de haute définition spatiale (720x576) comportant 60 images par seconde. L'ensemble des données codées ainsi sera décodable à partir d'un appareil ayant de bonnes capacités de décodage tel un ordinateur ou un téléviseur muni d'un décodeur interne ou externe. Grâce aux fonctionnalités de scalabilité de la norme SVC, il est possible d'extraire de ce flux un sous-flux comportant des données codées permettant de reconstruire une séquence d'images de résolution spatiale 180x144, donc 4 fois plus petite en hauteur et en largeur, et comportant 15 images par seconde. Un tel flux est 2 facilement décodable par un appareil de faible capacité tel un téléphone portable. Pour le transport des séquences vidéo compressées sur un réseau de communication, il est usuel d'utiliser le protocole RTP (Real Time Protocol) , qui a été défini par la recommandation RFC3550 de I'IETF, qui est adapté au transport des données en temps réel. Le format d'encapsulation ('payload format' en terminologie anglo-saxonne) pour des données codées selon le format SVC dans des paquets de transport RTP est en cours de définition. Ce format de paquets de transport est décrit dans le document 'RTP Payload Format for SVC video-draft-ietf-AVT-RTP-SVC-01', par S. Wenger et al. Un paquet de transport RTP comporte un en-tête, que l'on appellera aussi première portion et un corps, que l'on appellera aussi seconde portion. Un flux au format SVC est organisé en unités de données codées, connues sous le nom de NAL units (Network Abstract Layer Units). Une ou plusieurs unités de données codées peuvent être encapsulées dans le corps des paquets de transport RTP, selon le mode d'encapsulation choisi et selon la taille des paquets RTP, qui peut varier de 254 octets pour un réseau sans fil à 1500 octets pour un réseau IP filaire. L'en- tête d'un paquet RTP contient des champs de type et de taille prédéfinis, permettant notamment de mettre en oeuvre des numéros de séquence de paquets pour pouvoir reconstituer l'ordre des données vidéo même si le réseau de communication change l'ordre des paquets lors de la transmission. Il est courant dans un réseau de communication, lors d'un transfert de paquets de transport entre un dispositif serveur et une pluralité de dispositifs clients, de faire transiter les paquets de transport par des dispositifs réseau intermédiaires, appelés également noeuds réseau ou routeurs. Dans le cas d'une transmission d'une vidéo codée selon un format scalable, entre un dispositif serveur vers une pluralité de dispositifs clients ayant des capacités de traitement hétérogènes, certains paquets de transport contiennent des données codées appartenant à des sous-flux, et destinées seulement à certains dispositifs clients. Cette information de destination des 3 paquets est connue au niveau du dispositif serveur, mais elle ne peut pas être obtenue de manière aisée par un dispositif réseau intermédiaire. En effet, pour connaître la destination des unités de données codées contenues dans le corps d'un paquet RTP, un dispositif réseau intermédiaire doit être capable d'extraire les unités de données codées selon le format SVC du corps des paquets de transport et d'analyser la syntaxe des en-têtes de ces unités de données. Le dispositif réseau intermédiaire devrait donc avoir une connaissance des media transportés, comme le format de codage SVC dans le présent exemple. Ainsi, le dispositif réseau intermédiaire pourrait obtenir des informations relatives à la résolution spatiale, à la fréquence temporelle et au niveau de qualité auxquels contribuent les diverses unités de données codées. Sur la base de ces informations, le dispositif réseau intermédiaire pourrait ensuite transférer les paquets de transport de type RTP reçus vers les divers dispositifs clients. Il serait utile de permettre aux dispositifs réseau intermédiaires d'effectuer le routage des paquets de transport de manière plus systématique et plus aisée. Cela permettrait d'alléger la charge calculatoire nécessaire pour les dispositifs réseaux intermédiaires. A cet effet, la présente invention propose un procédé de formation de paquets de transport pour la transmission, d'un dispositif serveur vers au moins deux dispositifs clients, de données représentatives d'une séquence d'images codée, les données codées étant encapsulées dans des paquets de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion. Le procédé comprend les étapes suivantes : - obtention d'une information de routage pour chaque dispositif client, et - formation d'au moins un paquet de transport à partir de données codées, de sorte qu'au moins un champ de la première portion de chaque paquet de transport formé est généré en fonction d'au moins une information de routage obtenue. Ainsi, l'invention permet de véhiculer une information relative au routage des paquets de transport vers un ou plusieurs dispositifs clients, grâce 4 à la génération d'au moins un champ prédéfini d'un paquet de transport en fonction d'une information de routage. Cela permet de rendre le routage ultérieur des paquets plus rapide et plus aisé, tout en conservant la même quantité d'information à transmettre. Selon un mode de mise en oeuvre particulier, la valeur d'un champ représentatif d'un marqueur temporel est générée de manière à y insérer ladite au moins une information de routage. Ce mode de mise en oeuvre est particulièrement intéressant, car il permet de transporter l'information de routage insérée sans perturber l'usage initial du champ modifié, et en particulier sans provoquer une désynchronisation notable des paquets de transport. Dans un mode de mise en oeuvre particulier, l'information de routage représente une classe de dispositif client. Ainsi, l'information de routage est compacte et peut être codée sur 15 un faible nombre de bits. L'étape d'obtention d'une information de routage, selon un mode de mise en oeuvre de l'invention, comprend les sous-étapes de : -réception de chaque dispositif client d'au moins une information représentative de la capacité de traitement dudit dispositif client, 20 -détermination d'un ensemble de classes de dispositifs clients en fonction desdites informations. Ainsi, les classes de dispositifs clients utilisées pour la mise en oeuvre du procédé sont adaptées aux dispositifs clients connectés au serveur. Dans une variante, le procédé selon l'invention comporte en outre une 25 étape d'ordonnancement des classes de dispositif client déterminées dans l'ordre croissant de la quantité de données codées nécessaires pour la reconstruction des images décodées destinées aux dispositifs clients desdites classes de dispositifs clients. Cette variante est plus particulièrement adaptée aux formats de codage 30 scalables dans lesquels on peut encoder des données d'un niveau d'amélioration par prédiction par rapport à un niveau de scalabilité inférieur. Selon un mode particulier de l'invention, dans lequel les données codées sont organisées en unités de données codées, le procédé comprend, avant l'étape de formation, une étape d'association d'au moins une unité de données codées à au moins une classe de dispositif client, si ladite unité de 5 données codées contribue à la reconstruction d'une image décodée destinée à ladite classe de dispositif client. Dans ce mode particulier, un paquet de transport est formé à partir d'au moins une unité de données codées. En variante, un paquet de transport est formé à partir d'une pluralité 10 d'unités de données codées associées à une même au moins une classe de dispositif client. Ainsi, il est possible de former des paquets de transport adaptés au réseau de télécommunications, tout en s'assurant que le routage des paquets vers des dispositifs clients sera aisé. 15 Selon un mode particulier de l'invention, l'étape de formation comprend, pour un paquet de transport, les sous-étapes de : - détermination d'une valeur dépendante d'une information de routage pour ledit paquet de transport, -modification de la valeur dudit marqueur temporel en fonction de la 20 valeur déterminée. Selon un mode de mise en oeuvre particulier, la valeur déterminée est ajoutée à la valeur dudit marqueur temporel. Cette modification du marqueur temporel est particulièrement rapide. Selon un mode particulier, la valeur déterminée est dépendante des 25 indices des classes de dispositif client auxquelles sont associées les unités de données codées contenues dans le corps dudit paquet de transport. Dans une variante dans laquelle la séquence d'images est codée sur au moins deux niveaux de résolution, la valeur déterminée pour un paquet de transport est égale à l'indice minimum parmi les indices des classes de 30 dispositif client associées aux unités de données codées contenues dans ledit paquet de transport. 6 Cette variante est particulièrement avantageuse, car elle permet de réduire encore le nombre de bits nécessaires pour représenter l'information de routage relative à un paquet de transport. Corrélativement, la présente invention concerne un dispositif de formation de paquets de transport pour la transmission, vers au moins deux dispositifs clients, de données représentatives d'une séquence d'images codée, les données codées étant encapsulées dans des paquets de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion. Ce dispositif comprend : - des moyens d'obtention d'une information de routage pour chaque dispositif client, et des moyens de formation d'au moins un paquet de transport à partir de données codées, aptes à générer au moins un champ de la première portion dudit paquet de transport formé en fonction d'au moins une information de routage obtenue. Les avantages de ce dispositif sont les mêmes que les avantages du procédé de formation de paquets de transport, ils ne sont donc pas rappelés ici. Selon un second aspect, l'invention concerne un procédé de transfert de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, d'un dispositif intermédiaire vers au moins deux dispositifs clients, mis en oeuvre par le dispositif intermédiaire. Ce procédé de transfert de paquets de transport comporte les étapes de : réception d'un paquet de transport, extraction d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et - transfert du paquet de transport vers au moins un dispositif client en fonction de ladite information de routage extraite. Ainsi, un dispositif réseau intermédiaire mettant en oeuvre ce procédé peut aisément transférer un paquet de transport vers des dispositifs clients, 7 après une simple étape d'extraction d'au moins un champ de la première portion du paquet de transport reçu. Selon un mode de mise en oeuvre particulier, l'information de routage représente au moins une classe de dispositif client. Selon un mode de mise en oeuvre particulier, le procédé de transfert comporte, avant l'étape de réception, une étape d'obtention d'une information relative à la classe de dispositif client de chaque dispositif client. Ainsi, le dispositif réseau intermédiaire peut exploiter directement l'information de routage extraite pour le transfert des paquets vers un ou plusieurs dispositifs clients. Selon un mode de mise en oeuvre particulier, dans l'étape d'extraction, un ensemble d'indices, chaque indice étant représentatif d'une classe de dispositif client, est extrait d'un champ représentatif d'un marqueur temporel. Selon un mode de mise en oeuvre particulièrement avantageux, l'étape d'extraction comprend une sous-étape de masquage binaire appliqué à la valeur représentative d'un marqueur temporel de ladite première portion. Cette mise en oeuvre est particulièrement avantageuse, car elle est particulièrement efficace du point de vue calculatoire. Dans une variante dans laquelle les données codées sont organisées en unités de données codées et la séquence d'images est codée sur au moins deux niveaux de résolution, lorsque les unités de données codées sont dépendantes, dans l'étape de transfert, le paquet est transféré à tous les dispositifs client dont la classe a un indice supérieur ou égal à l'indice représentatif extrait. Corrélativement, la présente invention concerne un dispositif de transfert de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, vers au moins deux dispositifs clients. Le dispositif de transfert de paquets de transport est remarquable en ce qu'il comporte :, - des moyens de réception d'un paquet de transport, 8 - des moyens d'extraction d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et - des moyens de transfert du paquet de transport vers au moins un dispositif client en fonction de ladite information de routage extraite. Les avantages de ce dispositif sont les mêmes que les avantages du procédé de transfert de paquets de transport, ils ne sont donc pas rappelés ici. Selon un troisième aspect, la présente invention concerne un procédé de réception de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, mis en oeuvre par un dispositif client. Le procédé de réception est remarquable en ce qu'il comporte les étapes de : - réception d'un paquet de transport, - extraction d'au moins un champ de la première portion du paquet 15 de transport reçu d'au moins une information de routage, et - modification d'au moins un champ de la première portion du paquet de transport reçu en fonction de la au moins une information de routage extraite. Ainsi, un dispositif client peut, à la réception d'un paquet de transport 20 formé selon le procédé de formation de paquets de transport brièvement décrit ci-dessus, appliquer une modification à au moins un champ de la première portion du paquet reçu, de manière à corriger ce champ pour lui rendre sa valeur initiale, indépendante de l'information de routage. Corrélativement, la présente invention concerne un dispositif de 25 réception de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion. Le dispositif de réception de paquets est remarquable en ce qu'il comporte : -des moyens de réception d'un paquet de transport, 30 -des moyens d'extraction d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et 9 - des moyens de modification d'au moins un champ de la première portion du paquet de transport reçu en fonction de la au moins une information de routage extraite. Toujours dans le même but, la présente invention propose également un programme informatique qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de formation de paquets de transport, amène le dispositif à réaliser le procédé de formation de paquets de transport tel que décrit brièvement ci-dessus. Un tel programme informatique peut être porté par un support physique d'informations. Toujours dans le même but, la présente invention propose également un programme informatique qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de transfert de paquets de transport, amène le dispositif à réaliser le procédé de transfert de paquets de transport tel que décrit brièvement ci-dessus. Un tel programme informatique peut être porté par un support physique d'informations. Toujours dans le même but, la présente invention propose également un programme informatique qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de réception de paquets de transport, amène le dispositif à réaliser le procédé de réception de paquets de transport tel que décrit brièvement ci-dessus. Un tel programme informatique peut être porté par un support physique d'informations. Les caractéristiques et avantages particuliers de ces programmes informatiques étant similaires à ceux des procédés correspondants, ils ne sont pas répétés ici. Selon un autre aspect, la présente invention concerne un signal représentatif de données numériques formant un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, des données représentatives d'une séquence d'images codée étant encapsulées dans la seconde portion, dans lequel au moins un champ de la première portion contient une information modifiée en fonction d'une information de routage relative à au moins un dispositif client. 10 D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente schématiquement un système de 5 télécommunications dans lequel la présente invention est implémentée ; - la figure 2 est un diagramme d'un dispositif de traitement adapté à mettre en oeuvre la présente invention ; - la figure 3 illustre une séquence d'images codée selon un format scalable ; 10 - la figure 4 représente l'organigramme d'un algorithme de formation de paquets de transport de données vidéo mis en oeuvre par un dispositif serveur; - la figure 5 détaille les étapes de l'obtention d'une information de routage dans un mode de mise en oeuvre de l'invention ; 15 - la figure 6 représente un paquet de transport de type RTP ; - la figure 7 représente l'organigramme d'un algorithme de formation d'un champ d'en-tête modifié de paquet RTP ; - la figure 8 représente l'organigramme d'un algorithme de transfert de paquets de transport de données vidéo mis en oeuvre par un dispositif 20 réseau intermédiaire ; -la figure 9 représente l'organigramme d'un algorithme de réception de paquets de transport de données vidéo mis en oeuvre par un dispositif client. 25 La figure 1 représente un système de télécommunications dans lequel la présente invention est implémentée. Dans la figure 1, un serveur vidéo 10 émet des données vidéo codées pour une pluralité de dispositifs clients récepteurs, 20 à 28, par l'intermédiaire d'un réseau de télécommunication 50. Le réseau de 30 télécommunication 50 est, par exemple, un réseau Ethernet, un réseau Internet, un réseau GSM ou un réseau sans fil 802.11a ou b ou g. 11 Le serveur vidéo 10 comprend un dispositif 100 de formation de paquets de transport pour la transmission à partir d'unités de données codées représentatives d'une séquence d'images codée, par exemple, selon le format SVC. Les paquets de transport formés par le serveur sont de préférence des paquets selon le protocole RTP. Ces paquets sont acheminés, dans le réseau 50, vers une pluralité de dispositifs réseau intermédiaires, 11, 12 et 13. Chacun des dispositifs réseau intermédiaires transfère certains des paquets reçus du serveur vers un ou plusieurs dispositifs clients. Les dispositifs clients ont des capacités de traitement hétérogènes, en termes de taille d'écran d'affichage, de mémoire de stockage et de capacité calculatoire. Dans l'exemple de la figure 1, le dispositif client 28 est un dispositif léger, avec une résolution spatiale d'écran de 180x144 pixels et de faibles capacités calculatoires de type téléphone portable. Les dispositifs 22 et 26 sont des PDA (� Persona) Digital Assistant � en terminologie anglo-saxonne), avec une résolution spatiale d'écran de 360x288 pixels, alors que les dispositifs 20 et 24 sont des télévisions numériques munies de décodeurs internes ou externes, avec une résolution spatiale d'écran de 720x576 et des capacités calculatoires importantes. Dans l'exemple de la figure 1, les dispositifs réseau intermédiaires 11 et 13 comprennent chacun respectivement un dispositif (110, 130) de transfert de paquets de transport selon l'invention. Ainsi, le dispositif de transfert de paquets de transport 110 permet d'envoyer au dispositif client 22 seulement une partie des paquets reçus du serveur 10, qui correspondent à la résolution spatiale qui peut être affichée par ce dispositif, en appliquant un traitement rapide sur les en-têtes des paquets reçus. De même, le dispositif de transfert de paquets 130 envoie un sous- ensemble des paquets de transport contenant des données nécessaires pour reconstruire la résolution spatiale 180x144 au dispositif 28, en appliquant un traitement rapide sur les en-têtes des paquets reçus. 12 Le dispositif réseau intermédiaire 12, transfère les paquets de transport reçus du serveur 10 vers le dispositif client 24, ainsi que vers les dispositifs réseau intermédiaires 11 et 13 dans l'exemple de la figure 1. L'implémentation de l'invention lors de la formation des paquets n'affecte pas le comportement des dispositifs réseau intermédiaires conventionnels, qui n'implémentent pas l'invention. Les dispositifs clients 20 et 26 comportent respectivement des dispositifs 200 et 260 de réception de paquets de transport selon l'invention. La figure 2 est un diagramme d'un dispositif 1000 de traitement adapté à mettre en oeuvre la présente invention, qui est soit un dispositif serveur 10, ou un dispositif réseau intermédiaire 11 ou 13, ou un dispositif client 20 ou 26. L'appareil 1000 est par exemple un micro-ordinateur, un téléviseur, une station de travail ou un dispositif portable léger. L'appareil 1000 comporte un bus 202 de communication auquel sont connectés : - une unité centrale 203 de traitement, comme un microprocesseur, notée CPU ; - une mémoire morte 204 capable de contenir des programmes 20 informatiques afin de mettre en oeuvre l'invention, notée ROM ; - une mémoire vive 206, notée RAM, capable de contenir le code exécutable du procédé selon l'invention ainsi que les registres prévus pour enregistrer les variables et paramètres nécessaires à la mise en oeuvre de l'invention ; et 25 - une interface 218 de communication reliée au réseau 50 de communication sur lequel des données numériques sont transmises. Eventuellement, l'appareil 1000 peut également comprendre les composants suivants, inclus dans le mode de réalisation représenté sur la figure 2 : 30 - un moyen 212 de stockage des données tel qu'un disque dur, capable de contenir les programmes mettant en oeuvre l'invention et les données utilisées ou produites au cours de la mise en oeuvre de l'invention ; 13 - un lecteur 214 de disque destiné à un disque 216, ledit lecteur de disque étant prévu pour lire des données à partir du disque 216 ou pour écrire des données sur ledit disque ; - un écran 208 destiné à afficher des données et / ou servant d'interface graphique avec l'utilisateur, au moyen d'un clavier 210 ou d'un autre moyen quelconque de pointage. L'appareil 1000 peut être relié à divers périphériques, comme par exemple un appareil numérique 201 de prise de vues, relié à une carte d'entrée / sortie (non représentée) de façon à fournir des données représentatives d'une séquence d'images à l'appareil 1000. Le bus 202 de communication permet la communication et l'interopérabilité entre les divers éléments compris dans l'appareil 1000 ou reliés à celui-ci. La représentation du bus n'est pas limitative et, en particulier, l'unité centrale de traitement est capable de communiquer des instructions à un élément quelconque de l'appareil 1000 directement ou au moyen d'un autre élément de l'appareil 1000. Le disque 216 peut être remplacé par un support quelconque d'information comme par exemple un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire et, en termes généraux, par un moyen de stockage d'informations qui peut être lu par un micro-ordinateur ou par un microprocesseur, incorporé ou non à l'appareil, éventuellement amovible et prévu pour stocker un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé de formation de paquets de transport selon l'invention, du procédé de transfert de paquets de transport selon l'invention et du procédé de réception de paquets de transport selon l'invention. Le code exécutable permettant à l'appareil de mettre en oeuvre l'invention peut être stocké soit dans la mémoire morte 204, soit sur le disque dur 212, soit sur un support numérique amovible comme par exemple un disque 216 comme décrit précédemment. Selon une variante, le code exécutable des programmes peut être reçu au moyen du réseau de télécommunication 50, via l'interface 218, afin d'être stocké dans l'un des moyens de stockage de l'appareil 1000 avant d'être exécuté, comme le disque dur 212. 14 L'unité centrale 203 de traitement est prévue pour contrôler et diriger l'exécution des instructions ou des parties de code logiciel du ou des programmes selon l'invention, lesdites instructions étant stockées dans l'un des moyens de stockage susmentionnés. A la mise sous tension, le ou les programmes stockés dans une mémoire non volatile, par exemple sur le disque dur 212 ou dans la mémoire morte 204, sont transférés dans la mémoire vive 206, qui contient alors le code exécutable du ou des programmes selon l'invention ainsi que des registres destinés à stocker les variables et paramètres nécessaires à la mise en oeuvre de l'invention. II convient d'observer que l'appareil peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques, par exemple fixé dans un circuit intégré spécifique à l'application (Application Specific Integrated Circuit ou ASIC). La figure 3 permet d'illustrer schématiquement les nouvelles fonctionnalités de scalabilité spatiale et temporelle offertes par le format de compression SVC. Le format SVC permet également d'obtenir une scalabilité en qualité, qui n'est pas illustrée ici. Comme expliqué préalablement, l'invention trouve une application particulièrement intéressante dans le cadre de la transmission de données de séquences d'images codées selon le format de compression scalable SVC, mais pourrait s'appliquer avec d'autres formats de codage. Dans l'exemple de la figure 3 est représentée une séquence d'images originale SO, au format 720x576, comportant 60 images par seconde. A partir de cette séquence d'images originale, il est possible d'obtenir des ensembles de données codées selon le format SVC, permettant de reconstruire les ensembles des séquences représentées, R0,1 à R2,2. Les séquences R2,1 et R2,2 sont à la même résolution spatiale que la séquence originale, 720x576 , mais ont des résolutions temporelles différentes : R2,2 est à 60Hz, et R2,1 à 30Hz. Les séquences R1,1 à R1,3 sont codés à une résolution spatiale inférieure R1, égale à 360x288. Pour cette résolution spatiale, trois résolutions 15 temporelles dyadiques sont représentées : RI ,1 est à 15Hz, R1,2 à 30Hz et R1,3 à 60 Hz. Les séquences R0,1 à R0,3 sont à la résolution spatiale la plus basse, 180x144 dans cet exemple, et comme précédemment, trois résolutions temporelles sont représentées : R0,1 est à 15Hz, R0,2 à 30Hz et R0,3 à 60 Hz. Enfin, la norme SVC permet d'attribuer un débit variable à chaque image de chacune des séquences R0,1 à R2,2, de façon à obtenir une scalabilité en termes de qualité. L'exemple de la figure 3 illustre des flux formés avec un rapport de deux dans chaque dimension pour le passage d'une résolution spatiale à la résolution spatiale inférieure, mais il est également possible d'appliquer d'autres rapports, et en particulier d'appliquer un rapport différent selon la hauteur et la largeur, de manière à pouvoir s'adapter aux diverses tailles d'écran. Dans un scénario d'application typique de l'invention, la séquence R0,1 est destinée à un téléphone mobile(28), la séquence R1,2 à un PDA (22,26) et R2,2 à un téléviseur numérique(20,24). Selon le format de compression SVC, des données d'un niveau de résolution supérieur sont prédites par rapport à un niveau de résolution inférieur, et seules les erreurs de prédiction sont codées pour obtenir les données d'amélioration suffisantes pour représenter le niveau de résolution supérieur. II est possible d'extraire d'un flux SVC des sous-flux qui sont codés de manière imbriquée et interdépendante, chaque sous-flux de niveau de résolution supérieur encodant des données d'amélioration du flux de niveau inférieur. Les sous-flux encodés dans le flux au format SVC sont donc codés de manière interdépendante. Ainsi, dans l'exemple ci-dessus, l'ensemble de données codées nécessaires à la reconstruction de la séquence R1,2 est formé de l'ensemble des données codées contribuant à la reconstruction des images de la séquence R0,1 ainsi que les données d'amélioration contribuant aux séquences R0,2 à R1,2. 16 La figure 4 représente l'organigramme d'un algorithme de formation de paquets de transport de données vidéo mis en oeuvre par un dispositif serveur. Toutes les étapes de l'algorithme représentées sur la figure 4 peuvent être mises en oeuvre sous forme logicielle et exécutées par l'unité centrale de traitement 203 du dispositif 1000. Le présent algorithme est exécuté par le dispositif serveur lors de la transmission de données représentatives d'une séquence d'images codée à au moins deux dispositifs clients. Lors de la première étape E40, le dispositif serveur obtient une information de routage relative à chaque dispositif client. L'information de routage relative à un dispositif client est liée à la résolution spatiale, temporelle et en qualité de la séquence décodée à recevoir par ce dispositif client. Cette information est de préférence une information qui peut être représentée sur un faible nombre de bits. Dans le mode de mise en oeuvre préféré, l'information de routage est un indice de classe de dispositif client, comme expliqué ci-après en référence à la figure 5. L'étape E40 est suivie de l'étape E41, à laquelle on considère la première unité de données codées à traiter. Dans le cadre du format SVC, une unité de données codées est une unité de type NAL. L'étape E41 est suivie par l'étape E42, à laquelle l'unité de données codées en cours de traitement est associée à une ou plusieurs classes de dispositifs client, si cette unité de données codées contribue à la reconstruction d'une image de cette classe de dispositif client. Comme expliqué ci-dessus en référence à la figure 3, dans le cas du format SVC, des unités de données codées contribuent à la formation de plusieurs images décodées de divers niveaux de résolution. Dans ce cas, ces unités doivent être reçues par tous les dispositifs clients qui doivent recevoir un des niveaux de résolution auxquels elles contribuent. L'association obtenue est mémorisée dans un registre approprié de 30 la mémoire vive 206 du dispositif 1000. 17 Ensuite, à l'étape E43, des paquets de transport pour la transmission sur le réseau sont formés. Dans le mode de mise en oeuvre préféré, ces paquets sont formés selon le protocole RTP. Une ou plusieurs unités de données codées sont incluses dans la seconde portion d'un paquet RTP, appelée corps ('body' en terminologie anglo-saxonne), en fonction par exemple de la taille maximale MTU (acronyme de � Maximum Transfer Unit �) d'un paquet avant fractionnement dudit paquet par les dispositifs du réseau de télécommunication. Dans un mode de mise en oeuvre de l'invention, on insère une seule 10 unité de données codée (NAL) dans le corps d'un paquet RTP. Dans un mode de mise en oeuvre alternatif, dans lequel on cherche à former un paquet de transport ayant une taille aussi proche que possible de la taille MTU, plusieurs unités de données codées peuvent être insérées dans un même paquet. Dans ce cas, si la taille MTU n'est pas atteinte, l'étape E43 est 15 suivie de l'étape E44 d'extraction de l'unité de données codées suivante, elle même suivie de l'étape E42 précédemment décrite. Si plusieurs unités de données codées sont à inclure dans un même paquet de transport, lors de l'étape de formation E43, on vérifie qu'elles sont associées à la même ou aux mêmes classes de dispositif client. 20 Dans le cas où une unité de données codée a une taille qui dépasse la taille MTU, il est possible de la fractionner de manière à l'encapsuler dans plusieurs corps de paquets RTP. Lors de l'étape de formation E43, la première portion ou en-tête du paquet est également créée, basé sur la recommandation `RTP Payload 25 Format for SVC video-draft-ietf-AVT-RTP-SVC-01', par S. Wenger et al. Un en-tête selon ce format est représenté à la figure 6, contenant l'ensemble des champs suivants, détaillées dans la table 1 : Référence Nom du champ Nombre Utilisation figure 6 de bits 60 Ver=2 2 Version 61 P 1 Drapeau d'utilisation du padding 62 X 1 Existence d'extension d'en-tête 63 CC 4 Nombre d'indicateurs de contribution de source. 64 Marker bit 1 Indicateur du dernier paquet 65 Payload type 6 Définition du type de media transporté 66 Sequence Number 16 Ordre de décodage des paquets 67 Timestamp 32 Marqueur temporel 68 SSRC 32 Indicateur de synchronisation de source 69 CSRC 32 Indicateur de contribution de source Table 1 : champs d'en-tête de RTP Le rôle principal de RTP est de mettre en oeuvre des numéros de séquence de paquets (champ 66), pour pouvoir reconstituer les données vidéo même si le réseau sous-jacent change l'ordre des paquets de transport. Le type de données transportées dans le corps du paquet est spécifié par le champ 65. Le champ 61 indique l'existence d'une extension de paquet, et dans le cas où une telle extension est présente (X=1), une extension de 16 bits après le champ 69 indique un nombre de champs de 32 bits qui suivent. Selon la recommandation RFC3550 de I'IETF, l'usage de l'extension d'en-tête doit être limité, du fait de l'augmentation de la taille du paquet RTP. Les champs 63, 68 et 69 sont relatifs à la ou aux sources des données codées. De retour à la figure 4, l'étape E43 est suivie de l'étape E45 dans laquelle l'en-tête du paquet RTP est généré de manière à y inclure une information de routage vers un ou plusieurs dispositifs clients dudit paquet. Un tel en-tête est modifié par rapport à un en-tête de paquet RTP selon la recommandation RFC3550 de l'IETF. Dans le mode de mise en oeuvre préféré, détaillé à la figure 7, c'est le champ représentatif du marqueur temporel qui est modifié. Une telle modification est particulièrement avantageuse, car le champ marqueur temporel ainsi obtenu transporte l'information de routage ainsi que 19 l'information initiale, et peut donc être utilisé à la fois par un dispositif réseau intermédiaire mettant en oeuvre l'invention et par un dispositif réseau conventionnel. De plus, une telle information de routage est transportée sans 5 augmenter la taille du paquet de transport RTP. Les étapes E43 et E45 aboutissent à la formation d'un paquet de transport dans lequel un champ de la première portion est généré en fonction d'au moins une information de routage préalablement obtenue. L'étape E45 de génération est suivie de l'étape E46 d'envoi des 10 paquets vers les dispositifs clients, via un ou plusieurs dispositifs réseau intermédiaires. Cette étape est suivie de l'étape E47, à laquelle on vérifie si la dernière unité de données codées a été traitée. Si la réponse est négative, l'étape E47 est suivie de l'étape E44 précédemment décrite. Si la réponse est 15 positive, l'algorithme prend fin. La figure 5 détaille les étapes de l'obtention d'une information de routage dans un mode de mise en oeuvre de l'invention. Toutes les étapes de l'algorithme représentées sur la figure 5 peuvent être mises en oeuvre sous forme logicielle et exécutées par l'unité 20 centrale de traitement 203 du dispositif 1000. A l'étape E50 est effectué un protocole d'échange d'informations entre le serveur et les clients. Cette étape permet de connaître les ressources CPU, les capacités mémoire et éventuellement la résolution de l'écran d'affichage du dispositif client. 25 En pratique, une telle étape d'initialisation est mise en oeuvre entre le serveur et chaque client. De préférence, le protocole RTSP (� Real-Time Streaming Protoco �1) est utilisé. Chaque client 20 à 28 émet par exemple une requête RTSP 30 DESCRIBE au serveur de vidéo 10, pour connaître les caractéristiques de la séquence d'images stockée sur le serveur et pour transmettre un identifiant de type URI, acronyme de � Uniform Ressource Identifier �, correspondant à ses 20 caractéristiques. En retour, le serveur 10 transmet une description de la séquence d'images sous forme SDP (� Session Description Protocol � û recommandation RFC2327 de l'IETF). L'étape suivante E51 correspond à l'initialisation de la connexion pour la transmission, par l'intermédiaire d'une commande RTSP SETUP. L'étape E51 est suivie de l'étape E52 de détermination de classes de dispositifs clients. Le serveur peut avoir déjà en mémoire un ensemble de classes prédéterminées, correspondant aux types de dispositifs clients attendus, par exemple au nombre de 3 dans l'exemple de la figure 1, correspondant aux clients de type téléphone portable (classe 0), de type PDA (classe 1) et de type télévision numérique (classe 2). Ensuite, une classe de dispositif client prédéfinie est associée à chaque dispositif client, en fonction de ses caractéristiques recueillies lors de 15 l'étape E50. Alternativement, le serveur peut définir un ensemble de classes en fonction des premiers dispositifs clients connectés, et éventuellement augmenter ou réduire dynamiquement le nombre de classes en fonction des nouveaux dispositifs clients connectés. II est alors nécessaire de mettre à jour 20 l'attribution de classe de chaque dispositif client connecté. L'étape E52 est suive de l'étape E53 optionnelle d'ordonnancement des classes de dispositif client déterminées dans l'ordre croissant de la quantité de données codées nécessaires pour la reconstruction des images décodées destinées aux dispositifs clients desdites classes de dispositifs clients. L'étape 25 E53 n'est pas effectuée si les unités de données codées sont indépendantes. L'étape E53, ou l'étape E52 si l'étape E53 n'est pas effectuée, est suivie de l'étape E54 de notification aux dispositifs clients de leur information de routage associée, c'est-à-dire d'un indice représentatif de leur classe d'appartenance dans ce mode de mise en oeuvre. 30 Cette notification peut être faite en utilisant la commande SET PARAMETER du protocole RTSP. La commande SET PARAMETER transite sur les dispositifs réseau intermédiaires 11, 12, 13 qui sont placés entre le 21 serveur 10 et les dispositifs clients 20 à 28. Ainsi, les dispositifs réseau intermédiaires prennent également connaissance de l'information de routage associée aux dispositifs clients, comme expliqué ci-après en référence à la figure 8. D'autres informations utiles pour le traitement ultérieur des paquets de transport par des dispositifs réseau intermédiaires peuvent également être transmises par l'utilisation de la commande SET PARAMETER de RTSP. Par exemple, dans un mode de réalisation, la fréquence maximale Finax de la séquence d'images codées est notifiée aux dispositifs réseau intermédiaires via une commande SET PARAMETER. La figure 7 représente l'organigramme d'un algorithme de formation d'un champ d'en-tête modifié de paquet RTP, détaillant un mode de mise en oeuvre de l'étape E45 de la figure 4. Toutes les étapes de l'algorithme représentées sur la figure 7 peuvent être mises en oeuvre sous forme logicielle et exécutées par l'unité centrale de traitement 203 du dispositif 1000. L'algorithme de la figure 7 reçoit en entrée un paquet de transport au format RTP, noté R. La première étape E70 détermine une valeur dépendante d'une information de routage relative au paquet de transport R. En pratique, on commence par déterminer les indices CR représentatifs des classes de dispositifs clients auxquelles est destiné le paquet R. On envisage deux modes de fonctionnement selon la dépendance des unités de données codées. Dans le cas général, on considère que les unités de données codées peuvent être indépendantes ou pas, donc une unité de données codées peut contribuer à la reconstruction d'image(s) appartenant à un ou plusieurs niveaux de résolution. Dans ce cas, un paquet de transport RTP peut être associé à une ou plusieurs classes de dispositifs clients. Dans ce cas, CR={i} si I(R,i)=1, où I(R,i) est une fonction telle que I(R,i)=1 lorsque le paquet R contribue à la reconstruction des données à envoyer à la classe de dispositifs clients d'indice On détermine alors à l'étape E70 une valeur V(R) telle que : i où NC est le nombre total de classes de dispositifs clients. Dans l'exemple de la figure 1, NC=3. En d'autres termes, V(R) est le nombre entier codé sur NC bits, tel que chaque bit de poids i est égal à 1 si le paquet R est destiné à un dispositif client de classe d'indice i. Par exemple, si le paquet R est destiné à la fois aux dispositifs clients de classe d'indice 0 et de classe d'indice 2, on obtient V(R)=5, soit 101 en représentation binaire sur 3 bits. Dans le cas où les unités de données codées sont dépendantes, comme expliqué ci-dessus en référence à la figure 3, une unité de données codées est associée à plusieurs classes de dispositifs clients. Dans ce cas, l'indice représentatif associé au paquet R est l'indice 15 minimum des classes de dispositif client associées aux unités de données codées contenues dans le paquet. En effet, dans le cas de l'interdépendance des unités de données codées associées à diverses résolutions, une unité de données codée qui sert pour la reconstruction d'un niveau de résolution sert également pour la 20 reconstruction de tous les niveaux de résolution supérieurs. II est possible dans le cas des unités de données codées dépendantes d'optimiser encore le traitement selon l'invention, en minimisant le nombre de bits nécessaire pour encoder l'information de routage. En d'autres termes, si I(R,j)=1 alors I(R,i)=1 pour tout j i , 25 Dans ce cas, on détermine, à l'étape E70, une valeur V(R) telle que : V(R) = imin (Eq2) Où Imin est l'indice minimum des classes de dispositif client associées aux unités de données codées contenues dans le paquet. L'étape E70 est suivie de l'étape E71, à laquelle le champ 30 représentatif du marqueur temporel 67 est modifié en fonction de la valeur dépendante de l'information de routage V(R) déterminée à l'étape E70. 23 La valeur du marqueur temporel 67, codée sur 32 bits, est initialement obtenue en prenant en compte la fréquence temporelle Ft de la séquence d'images, et une fréquence d'horloge fixe de 90000Hz, comme indiqué dans le recommandation `RTP Payload Format for SVC videoûdraft-ietf-AVT-RTP-SVC-01', par S. Wenger et al. Ainsi, pour un ensemble d'unités de données codées encapsulées dans un paquet RTP R et ayant un temps de présentation t, le marqueur temporel est défini par : TS(R) = 90000 F + to (Eq3) où to est l'instant initial de présentation des données. Il est alors facile de déduire l'intervalle de temps DTS(Ft) entre deux paquets transportant des données codées correspondant à deux images successives d'une séquence de fréquence temporelle Ft. Nous donnons ci-dessous quelques exemples d'intervalle de temps pour des fréquences temporelles usuelles. Par exemple, lorsque Ft=30Hz, DTS(Ft)=3000 ; Pour Ft=29.97Hz, DTS(Ft)=3003 ; Pour Ft=15Hz, DTS(Ft)=6000. Dans le mode de mise en oeuvre préféré, c'est la valeur représentative du marqueur temporel qui est modifiée, car il existe un grand nombre de valeurs possibles entre deux images consécutives, et il est par conséquent possible de modifier légèrement la valeur du marqueur temporel tout en conservant son usage initial. Dans le mode de mise en oeuvre préféré, à l'étape E71 on additionne 25 la valeur V(R) obtenue précédemment à la valeur du marqueur temporel, pour obtenir une valeur de marqueur temporel modifiée TS'(R) : TS'(R) = TS(R) + V(R) (Eq4) En variante, la valeur de V(R) peut être soustraite à la valeur de TS(R) pour obtenir la valeur modifiée du marqueur temporel. 24 D'une manière plus générale, on peut utiliser toute fonction f(TS(R),V(R)), telle que f est une fonction inversible qui modifie peu la valeur initiale TS(R). L'étape de modification est suivie de l'étape E72, à laquelle la valeur 5 du marqueur temporel modifiée est insérée dans l'en-tête du paquet R. Ainsi, un paquet de transport ayant un en-tête modifié R' est obtenu. La figure 8 représente l'organigramme d'un algorithme de transfert de paquets de transport de données vidéo mis en oeuvre par un dispositif réseau intermédiaire. Toutes les étapes de l'algorithme représentées sur la 10 figure 8 peuvent être mises en oeuvre sous forme logicielle et exécutées par l'unité centrale de traitement 203 du dispositif 1000. Le présent algorithme est exécuté par un dispositif réseau intermédiaire (11, 13) pour traiter des paquets formés par un serveur (10) mettant en oeuvre un procédé de formation de paquets de transport conforme à 15 l'invention. Dans une première étape préliminaire E80, le dispositif réseau intermédiaire reçoit et mémorise une information relative à la classe de chaque dispositif client auquel il doit transférer des données. Comme expliqué ci-dessus en référence à l'étape E54 de la figure 5, lors de l'initialisation de la 20 connexion entre un dispositif client et un dispositif serveur, le serveur notifie au client sa classe d'appartenance selon une classification déterminée par le serveur. Cette notification est faite par exemple par l'intermédiaire d'une commande SET PARAMETER du protocole RTSP. La requête transite par les dispositifs réseau intermédiaires, qui peuvent alors obtenir et mémoriser les 25 informations de routage associées aux dispositifs clients sous la forme d'indices représentatifs des classes de dispositifs clients. Cette étape E80 peut être effectuée une seule fois lors de l'établissement de la session, ou éventuellement plusieurs fois, en cas de changement dynamique de l'assignation des classes de dispositifs clients, 30 comme expliqué ci-dessus en référence à la figure 5. 25 L'étape E80 est suivie de l'étape E81 de réception d'un paquet de transport de données R'. Dans le mode de mise en oeuvre préféré, on considère un paquet RTP. L'étape de réception est suivie de l'étape E82 d'extraction d'une 5 information de routage relative au paquet de routage R', à partir d'un champ de l'en-tête du paquet R'. Dans le mode de mise en oeuvre préféré, on considère que le dispositif serveur 10 a modifié le champ marqueur temporel 67 comme décrit ci-dessus en référence à la figure 7. 10 Comme dans le cas envisagé au serveur, dans cet exemple de mise en oeuvre les paquets de transport encapsulent, dans leur seconde portion ou corps, une ou plusieurs unités de données codées représentatives d'une séquence d'image, contribuant à reconstruire un ou plusieurs niveaux de résolution de la séquence d'images décodée. On peut distinguer, comme pour 15 la modification des en-têtes de paquets de transport RTP au niveau du dispositif serveur 10, entre le cas où les unités de données codées sont dépendantes et celui où les unités de données codées sont indépendantes. Le choix d'un de ces deux modes de traitement est fait au préalable et connu des dispositifs qui implémentent l'invention. Alternativement, ce choix peut-être fait 20 en début de session et notifié aux dispositifs réseau intermédiaires via une commande SET PARAMETER de RTSP. Lors de l'étape E82, on utilise la fréquence temporelle maximale Finax de la séquence d'images codée qui est transmise. Comme expliqué ci-dessus en référence à la figure 5, la valeur de la fréquence temporelle maximale peut 25 être notifiée aux dispositifs réseau intermédiaires via une commande SET PARAMETER de RTSP. Cette valeur est reçue à l'étape E80 et stockée dans la mémoire 206 du dispositif réseau intermédiaire. On utilise cette fréquence Finax pour déterminer la valeur maximale entière m telle que : 30 TS(R') û m • DTS(Finax) ? 0 où TS(R') est le marqueur temporel pour le paquet R', et DTS(Fm) représente l'intervalle de temps entre deux paquets transportant des données 26 codées correspondant à deux images successives d'une séquence de fréquence temporelle Finax• Ensuite, on prend la valeur de la différence X(R') = TS(R') ù m DTS(Fm,x) , qui permet ensuite de déduire une information de routage sous la forme d'un ou plusieurs indices de classe de dispositif client, qui a été insérée dans le champ marqueur temporel de l'en-tête du paquet RTP. Dans le cas général, où les unités de données codées peuvent être indépendantes ou pas, et peuvent donc contribuer à la reconstruction d'images décodées pour une ou plusieurs classes de dispositifs clients, on applique, dans le mode de mise en oeuvre préféré, autant d'opérations de comparaison binaire, qu'on appelle également masquages binaires, que le nombre NC de classes de dispositifs clients. Par exemple, lorsque NC=3, on applique les opérations suivantes : -si X(R')&001=1, 0ECR. (Eq5) -si X(R') & 010 = 1, 1 E CR, (Eq6) -si X(R') &100 =1, 2 E CR. (Eq7) Par exemple, si X(R') &001= 1 et X(R') & 100 =1, alors l'ensemble des indices de classe de dispositif clientCR, = {0,2}, donc le paquet R' est destiné aux classes de dispositifs clients d'indices 0 et 2. Dans le cas où les unités de données codées sont dépendantes et imbriquées, on applique de préférence une opération de comparaison binaire simple, qu'on appelle également masquage binaire, pour déduire une information de routage sous la forme d'un indice de classe de dispositif client à partir de la valeur X(R') : iR, = X(R') & l l (Eq8) Cette équation revient à extraire la valeur encodée par les bits de poids faible de la valeur X(R') pour déduire la valeur de l'indice iR'. Dans ces mode mise en oeuvre, le paquet R' est alors destiné aux classes de dispositifs clients d'indices j >. iR, . 27 Bien évidemment, les exemples donnés ici pour un ensemble de trois classes de dispositif client se généralisent de manière directe à un nombre plus grand de classes de dispositifs clients. Notons ici que dans les cas usuels où les fréquences de vidéo maximales sont respectivement égales à 15Hz, 25Hz et 30Hz, l'intervalle de temps DTS est un multiple de 10. Dans ce cas, on peut considérer directementX(R') =TS(R'), ce qui simplifie encore les calculs. Pour les deux modes envisagés, que les unités de données codées soient dépendantes ou indépendantes, l'extraction d'une information de routage peut être effectuée très simplement par application de masque(s) binaire(s) sur les bits de poids faible de la valeur X(R'), ce est très efficace du point de vue calculatoire. L'étape E82 est suivie de l'étapes E83 de transfert du paquet reçu R' vers un ou plusieurs dispositifs clients, en fonction de l'information de routage extraite à l'étape E82 et de l'information d'appartenance des dispositifs clients à des classes, préalablement mémorisée. Dans le cas où les unités de données codées sont indépendantes, le paquet est directement routé vers les dispositifs clients dont la classe est indiquée par les indices appartenant à CR,. Dans le cas particulier où les unités de données codées sont dépendantes, un paquet de transport R' est envoyé à tous les clients appartenant à une classe d'indice supérieur ou égal à l'indice iR, extrait. Ainsi, si iR.=O, le paquet est transféré vers toutes les classes de dispositif client, donc vers tous les dispositifs clients reliés au dispositif réseau intermédiaire qui effectue le traitement. Si l'indice iR.=1, le paquet est transféré vers les récepteurs de classes 1 et 2, donc pour les récepteurs de type PDA (22 et 26) et télévision numérique (20) dans l'exemple de la figure 1. Si l'indice iR.=2, le paquet est transféré vers les dispositifs clients de 30 classe 2 seulement. L'étape E83 est suivie de l'étape E81 précédemment décrite pour le traitement d'un nouveau paquet. 28 La figure 9 représente l'organigramme d'un algorithme de réception de paquets de transport de données vidéo mis en oeuvre par un dispositif client. Toutes les étapes de l'algorithme représentées sur la figure 9 peuvent être mises en oeuvre sous forme logicielle et exécutées par l'unité centrale de traitement 203 du dispositif 1000. Le présent algorithme est exécuté par un dispositif client (20,26) pour traiter des paquets formés par un serveur (10) mettant en oeuvre un procédé de formation de paquets de transport conforme à l'invention et ayant transité par des dispositifs réseau intermédiaires (11,13). Dans une première étape préliminaire E90, le dispositif client reçoit une notification du dispositif serveur, à partir de laquelle il peut obtenir et mémoriser une information de routage relative à la classe qui lui a été assignée par le dispositif serveur. Comme expliqué ci- dessus en référence à l'étape E54 de la figure 5, lors de l'initialisation de la connexion entre un dispositif client et un dispositif serveur, le serveur notifie au client sa classe d'appartenance selon une classification déterminée par le serveur. Cette notification est faite par exemple par l'intermédiaire d'une commande SET PARAMETER du protocole RTSP. Cette étape E90 peut être effectuée une seule fois lors de l'établissement de la session, ou éventuellement plusieurs fois, en cas de changement dynamique de l'assignation des classes de dispositifs clients, comme expliqué ci-dessus en référence à la figure 5. L'étape E90 est suivie de l'étape de réception E91, à laquelle un paquet de transport RTP contenant des données codées représentatives d'une 25 séquence d'images est reçu. L'étape E91 est suivie de l'étape E92 d'extraction d'une information de routage insérée dans la première portion ou en-tête du paquet reçu R'. Cette étape est analogue à l'étape E82 décrite en référence à la figure 8. Dans le cas général, où les unités de données codées peuvent être 30 indépendantes, en appliquant les opérations décrites en référence à l'étape E82 on extrait un ensemble d'indices de classes de dispositif client CR', auxquelles le paquet R' a été envoyé. Dans le cas particulier des unités de données codées dépendantes et imbriquées, l'information de routage extraite est un indice iR' de classe de dispositif client. Cette étape est suivie de l'étape E93, de modification inverse d'un 5 champ d'en-tête du paquet RTP reçu. Dans l'exemple de mise en oeuvre préféré, lorsque la valeur du champ représentatif du marqueur temporel a été modifiée selon le mode de mise en oeuvre décrit en référence à la figure 7 (modification selon Eq(4)), la valeur de ce champ est modifiée lors de l'étape E93. La modification a pour but 10 d'enlever l'information de routage qui a été insérée dans le marqueur temporel de façon à rendre à ce marqueur temporel sa valeur initiale. Dans le cas général, où les unités de données codées peuvent être indépendantes, on peut déduire la valeur V(R') à soustraire à la valeur du marqueur temporel : i où L(R',i)=l si i E CR. Dans le cas particulier des unités de données codées dépendantes, la valeur V(R') à soustraire à la valeur du marqueur temporel est donnée par : V(R') = lR. 20 Ensuite, la modification inverse du marqueur temporel consiste à soustraire la valeur V(R') à la valeur courante du marqueur temporel : TSfinal (R') = TS(R') ùV(R') De manière plus générale, on applique la fonction inverse de la fonction f appliquée à l'étape E71, pour obtenir la valeur TSfna,(R') à partir des 25 valeurs TS(R') et V(R'). La valeur obtenue, TSfnai(R'), est identique à la valeur du marqueur temporel avant modification pour y insérer une information de routage. L'étape E93 est suivie de l'étape E94, de désencapsulation des unités de données codées du corps du paquet de transport. Ces unités sont 30 passées à un décodeur de données codées selon le format de codage considéré, SVC dans ce mode de mise en oeuvre, pour le décodage. L'étape E94 est suivie de l'étape E91 préalablement décrite pour le traitement d'un autre paquet de transport RTP. Notons ici qu'un dispositif client qui ne contient pas un dispositif de réception de paquets de transport selon l'invention peut néanmoins traiter les paquets RTP reçus et décoder la séquence d'images transportée dans ces paquets. Dans ce cas, l'affichage des images décodées sera légèrement décalé, mais la fréquence d'affichage sera respectée. Le décalage dû à la modification du marqueur temporel reste faible lorsqu'on considère un nombre de classes de dispositif client relativement limité. Par exemple, lorsque la valeur du marqueur temporel est décale de +1, cela correspond seulement à 0.333 ms pour une séquence de fréquence temporelle 30Hz. REVENDICATIONS 1. Procédé de formation de paquets de transport pour la transmission, d'un dispositif serveur vers au moins deux dispositifs clients, de données représentatives d'une séquence d'images codée, les données codées étant encapsulées dans des paquets de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, caractérisé en ce qu'il comprend les étapes de : - obtention (E40) d'une information de routage pour chaque dispositif client, - formation (E43, E45) d'au moins un paquet de transport à partir de données codées, de sorte qu'au moins un champ de la première portion dudit paquet de transport formé est généré en fonction d'au moins une information de routage obtenue. 2. Procédé de formation de paquets de transport selon la revendication 1, dans lequel la valeur d'un champ représentatif d'un marqueur temporel (67) est générée de manière à y insérer ladite au moins une information de routage. 3. Procédé de formation de paquets de transport selon la revendication 1 ou la revendication 2, dans lequel l'information de routage représente une classe de dispositif client. 25 4. Procédé de formation de paquets de transport selon la revendication 3, dans lequel l'étape d'obtention d'une information de routage comprend les sous-étapes de : - réception (E50) de chaque dispositif client d'au moins une information représentative de la capacité de traitement dudit dispositif client, et 30 -détermination (E52) d'un ensemble de classes de dispositifs clients en fonction desdites informations. 20 5. Procédé de formation de paquets de transport selon la revendication 4, comportant en outre : -une étape d'ordonnancement (E53) des classes de dispositif client déterminées dans l'ordre croissant de la quantité de données codées nécessaires pàur la reconstruction des images décodées destinées aux dispositifs clients desdites classes de dispositifs clients. 6. Procédé de formation de paquets de transport selon l'une quelconque des revendications 3 à 5, les données codées étant organisées en unités de données codées, comportant, avant l'étape de formation : - une étape (E42) d'association d'au moins une unité de données codées à au moins une classe de dispositif client, si ladite unité de données codées contribùe à la reconstruction d'une image décodée destinée à ladite classe de dispositif client. 7. Procédé de formation de paquets de transport selon la revendication 6, dans lequel un paquet de transport est formé à partir d'au moins une unité de données codées. 8. Procédé de formation de paquets de transport selon la revendication 7, dans lequel un paquet de transport est formé à partir d'une pluralité d'unités de données codées associées à une même classe de dispositif client. 9. Procédé de formation de paquets de transport selon l'une quelconque des revendications 3 à 8, dans lequel l'étape de formation comprend, pour un paquet de transport, les sous-étapes de : - détermination (E70) d'une valeur dépendante d'une information de routage pour ledit paquet de transport, et -modification (E71) de la valeur dudit marqueur temporel en fonction de la valeur déterminée. 33 10. Procédé de formation de paquets de transport selon la revendication 9, dans lequel la valeur déterminée est dépendante des indices des classes de dispositif client auxquelles sont associées les unités de données codées contenues dans le corps dudit paquet de transport. 11. Procédé de formation de paquets de transport selon la revendication 10, dans lequel la séquence d'images est codée sur au moins deux niveaux de résolution, dans lequel la valeur déterminée pour un paquet de transport est égale à l'indice minimum parmi les indices des classes de dispositif client associées aux unités de données codées contenues dans ledit paquet de transport. 12. Procédé de transfert de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, d'un dispositif intermédiaire vers au moins deux dispositifs clients, mis en oeuvre par le dispositif intermédiaire, caractérisé en ce qu'il comporte les étapes de : réception (E81) d'un paquet de transport, extraction (E82) d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et - transfert (E83) du paquet de transport vers au moins un dispositif client en fonction de ladite information de routage extraite. 13. Procédé de transfert de paquets de transport selon la revendication 12, dans lequel l'information de routage représente au moins une classe de dispositif client. 14. Procédé de transfert de paquets de transport selon la revendication 30 13, comportant, avant l'étape de réception, une étape d'obtention (E80) d'une information relative à la classe de dispositif client de chaque dispositif client. 15. Procédé de transfert de paquets de transport selon l'une quelconque des revendications 13 à 14, dans lequel, dans l'étape d'extraction (E82), un ensemble d'indices (CR'), chaque indice étant représentatif d'une classe de dispositif client, est extrait d'un champ représentatif d'un marqueur r5 temporel. 16. Procédé de transfert de paquets de transport selon la revendication 15, dans lequel l'étape d'extraction comprend une sous- étape de masquage binaire (E82) appliqué à la valeur représentative d'un marqueur temporel de 10 ladite première portion. 17. Procédé de transfert de paquets de transport selon la revendication 16, dans lequel les données codées étant organisées en unités de données codées et la séquence d'images étant codée sur au moins deux niveaux de 15 résolution, lorsque les unités de données codées sont dépendantes, dans l'étape de transfert, le paquet est transféré (E83) à tous les dispositifs client dont la classe a un indice supérieur ou égal à l'indice représentatif extrait. 20 18. Procédé de réception de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, mis en oeuvre par un dispositif client, caractérisé en ce qu'il comporte les étapes de : 25 - réception (E91) d'un paquet de transport, extraction (E92) d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et -modification (E93) d'au moins un champ de la première portion du paquet de transport reçu en fonction de la au moins une information de routage 30 extraite. 19. Dispositif de formation de paquets de transport pour la transmission, vers au moins deux dispositifs clients, de données représentatives d'une séquence d'images codée, les données codées étant encapsulées dans des paquets de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, caractérisé en ce qu'il comprend : - des moyens d'obtention d'une information de routage pour chaque dispositif client, et - des moyens de formation d'au moins un paquet de transport à partir de données codées, aptes à générer au moins un champ de la première portion dudit paquet de transport formé en fonction d'au moins une information de routage obtenue. 20. Dispositif de transfert de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, vers au moins deux dispositifs clients, caractérisé en ce qu'il comporte : des moyens de réception d'un paquet de transport, des moyens d'extraction d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et - des moyens de transfert du paquet de transport vers au moins un dispositif client en fonction de ladite information de routage extraite. 21. Dispositif de réception de paquets de transport contenant des données représentatives d'une séquence d'images codée, un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, caractérisé en ce qu'il comporte : des moyens de réception d'un paquet de transport, des moyens d'extraction d'au moins un champ de la première portion du paquet de transport reçu d'au moins une information de routage, et- des moyens de modification d'au moins un champ de la première portion du paquet de transport reçu en fonction de la au moins une information de routage extraite. 22. Programme d'ordinateur qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de formation de paquets de transport, amène le dispositif à réaliser un procédé selon l'une quelconque des revendications 1 à 11. 23. Programme d'ordinateur qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de transfert de paquets de transport, amène le dispositif à réaliser un procédé selon l'une quelconque des revendications 12 à 17. 24. Programme d'ordinateur qui, lorsqu'il est exécuté par un ordinateur ou un processeur dans un dispositif de réception de paquets de transport, amène le dispositif à réaliser un procédé selon la revendication 18. 25. Signal représentatif de données numériques formant un paquet de transport comprenant une première portion composée d'une pluralité de champs et une seconde portion, des données représentatives d'une séquence d'images codée étant encapsulées dans la seconde portion, dans lequel au moins un champ de la première portion contient une information modifiée en fonction d'une information de routage relative à au moins un dispositif client.25