Brevet FR2942095A1 — publié le 20100813

La présente invention se rapporte à un procédé et à un dispositif d'identification de pertes de données vidéo. Dans toute la description, le terme "perte" se rapporte aussi bien à des données manquantes qu'à des données erronées. L'invention se place dans le cadre de la transmission d'une séquence vidéo entre un serveur et au moins un client sur un réseau de communication non fiable, c'est-à-dire dans lequel les conditions de transmission ne sont pas stables et où des pertes de données peuvent se produire. L'invention s'intéresse plus particulièrement à la détection et à la localisation des données vidéo affectées par de telles pertes. Les traitements de détection et de localisation des pertes de données vidéo sont résumés dans toute la suite par l'expression "identification des pertes". On se place dans le cas où le codage de la séquence vidéo est de type hiérarchique ou "scalable", c'est-à-dire qu'il met en oeuvre un ou plusieurs niveaux hiérarchiques, appelés aussi niveaux ou couches de scalabilité. Un exemple non limitatif d'un tel format de codage scalable est la norme SVC ("Scalable Video Coding"). Trois types de scalabilité ont été définis dans la norme SVC : scalabilité spatiale, temporelle et en qualité, la scalabilité en qualité étant également connue sous le nom de scalabilité SNR (de l'anglais "Signal to Noise Ratio", rapport signal à bruit). La scalabilité temporelle permet de modifier la résolution temporelle d'une séquence (c'est-à-dire le nombre d'images par seconde représentées par les données codées) en supprimant certaines images, cette suppression prenant en compte les dépendances éventuelles entre les images. La scalabilité spatiale consiste à insérer plusieurs résolutions spatiales (correspondant à différents nombres de pixels représentés par les données codées) dans un flux vidéo, la résolution la plus basse étant utilisée pour la prédiction des résolutions supérieures. La scalabilité en qualité prend trois formes différentes : scalabilité à grains grossiers ou CGS (en anglais "Coarse Grain Scalability"), scalabilité à grains moyens ou MGS (en anglais "Medium Grain Scalability") et scalabilité à grains fins ou FGS (en anglais "Fine Grain Scalability"). La scalabilité CGS utilise les mêmes concepts que la scalabilité spatiale, à ceci près que pour CGS, les opérations de sur-échantillonnage de la prédiction inter-couche sont omises. La scalabilité FGS permet la création d'un flux binaire qui peut être tronqué en un point quelconque tout en restant décodable. La scalabilité MGS a été définie comme intermédiaire entre CGS et FGS : elle offre des points de décodage dans le flux binaire plus fins que CGS mais ne permet pas la troncature en n'importe quel point comme FGS. La scalabilité MGS est souvent considérée comme offrant une granularité suffisante pour des conditions réseau réalistes. La transmission d'une vidéo sur un réseau est facilitée par l'introduction de la notion d'entité NAL (en anglais "Network Abstraction Layer"). Une NAL est une unité élémentaire de transfert du flux binaire qui fournit dans son en-tête des éléments de description des données transportées dans la partie données de la NAL. A titre d'exemple non limitatif, pour la transmission d'un flux SVC, la NAL peut être vue comme un conteneur de données vidéo (en anglais "video data container") ; l'en-tête de NAL comporte en particulier les paramètres suivants : • Dependency_id (DId) : spécifie la couche spatiale des données vidéo contenues dans la NAL ; • Quality_id (QId) : spécifie la couche de qualité des données vidéo contenues dans la NAL ; • Temporal_id (TId) : spécifie la couche temporelle des données 25 vidéo contenues dans la NAL. Toutes les NALs correspondant à une même image codée forment une entité appelée AU (en anglais "Access Unit"). Le numéro de séquence est choisi aléatoirement pour le premier paquet d'une session de diffusion vidéo. Il augmente ensuite de 1 chaque fois 30 qu'un nouveau paquet est créé pour cette application. L'estampille temporelle (en anglais "timestamp") représente l'instant de création des données transportées. Par exemple, toutes les données SVC correspondant à un même instant doivent porter la même estampille temporelle si elles sont transportées par plusieurs paquets. Il est particulièrement intéressant de disposer d'une technique permettant d'identifier de façon précise les données d'une séquence vidéo qui ont été perdues lors de la transmission. Dans un premier exemple, du côté du client, il est particulièrement avantageux de pouvoir identifier précisément les images affectées par une perte avant d'entamer le processus de décodage. En effet, on pourra ainsi éviter de décoder une couche SVC d'un flux binaire SVC si on sait que la qualité globale de cette couche est fortement dégradée. Dans un deuxième exemple, l'identification précoce des images affectées par des pertes peut permettre de prendre une décision sur le type de méthode de résistance aux erreurs (en anglais "error resilience method") à appliquer. En effet, de nombreuses techniques de résistance aux erreurs sont disponibles lorsqu'une erreur s'est produite : retransmission des données perdues, mise à profit du codage INTRA (en anglais "Infra refresh"), masquage d'erreur (en anglais "error concealment"), codes correcteurs d'erreurs (FEC, en anglais "Frame Error Correction"), etc. L'efficacité de certaines de ces techniques dépend étroitement du temps de réaction du client. Par exemple, la retransmission des données perdues est souvent considérée comme un processus lent qui n'est pas adapté à des applications de diffusion vidéo. Dans un dernier exemple, on peut avoir le cas d'un réseau constitué de noeuds réseau dits intelligents, du type MANE ("Media Aware Network Bernent"), capables d'analyser l'en-tête de NAL mais incapables de décoder les données vidéo. Un tel réseau transporte des données vidéo scalables, chaque couche de scalabilité étant transportée dans une session de diffusion groupée (en anglais "multicast session") dédiée. Les utilisateurs de cette application peuvent souscrire à un sous-ensemble de ces couches de scalabilité en fonction de leurs capacités. Dans un tel cas, il est particulièrement avantageux de pouvoir évaluer dans quelle mesure une couche est affectée par des pertes, afin d'éviter d'acheminer vers un client des couches qui n'apporteront pas une amélioration suffisante de la qualité spatiale, SNR ou temporelle. Dans le cadre d'une application de diffusion vidéo (souvent appelée "video streaming" en anglais) entre un système serveur et un client au travers d'un réseau, les données vidéo sont souvent transportées dans des paquets RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof') car RTP offre un jeu intéressant d'outils de résistance aux erreurs. L'en-tête de paquet RTP contient en particulier deux informations : • un numéro de séquence, et • un élément d'horodatage ou estampille temporelle (noté Timestamp). Le numéro de séquence offre une façon de détecter qu'une perte s'est produite dans un ensemble de paquets. En effet, RTP empêche les sauts de numéro de séquence. Si un client détecte dans les numéros de séquence un saut supérieur à 1 entre deux paquets reçus consécutivement, il peut en déduire qu'au moins une perte s'est produite. Cependant, la détection des pertes par la couche réseau au moyen du seul numéro de séquence ne permet pas d'identifier les images qui ont été affectées par ces pertes, ni de déterminer l'impact de ces pertes sur la qualité globale. Le document US-A-7 072 403 propose une coopération entre la couche réseau et le décodeur, dans un système où les paquets transportent des blocs de données correspondant à un ensemble de pixels. Le récepteur détecte des erreurs dans les paquets au niveau réseau en utilisant des codes détecteurs d'erreurs et fournit l'information correspondante au décodeur. Le décodeur décide si les blocs contenus dans les paquets sont effectivement affectés par une perte. Si c'est le cas, un masquage d'erreurs est appliqué. Cette méthode présente un inconvénient majeur : sans l'aide du décodeur, la couche réseau est incapable d'identifier les blocs de pixels qui ont été affectés par les pertes. La norme SVC propose certains outils pour détecter des pertes de données, en imposant des contraintes sur les valeurs prises par les paramètres DId, QId et TId définis ci-dessus, contenus dans les en-têtes de NAL, et en introduisant une NAL particulière : le message scalable SEI ("Supplemental Enhancement Information"), qui transporte des informations décrivant la séquence SVC. L'organigramme de la figure 1 illustre le principe du processus de détection de pertes disponible dans la norme SVC. Ce processus débute lors d'un test 101 par l'analyse de la valeur, notée Tid, du paramètre TId contenu dans l'en-tête de NAL SVC. La notation Tid représente la valeur du paramètre TId du dernier paquet reçu et la notation Tid_ représente la valeur du paramètre TId du paquet reçu immédiatement avant le dernier paquet reçu. Si les paramètres TId de ces deux paquets ont la même valeur, le test 101 est suivi d'un test 103. Le test 103 consiste à analyser la valeur du paramètre DId. La notation Did représente la valeur du paramètre DId du dernier paquet reçu et la notation Did_ représente la valeur du paramètre DId du paquet reçu immédiatement avant le dernier paquet reçu. Si les paramètres DId de ces deux paquets ont la même valeur, le test 103 est suivi d'un test 105. Le test 105 consiste à analyser la valeur du paramètre QId. La notation Qid représente la valeur du paramètre QId du dernier paquet reçu et la notation Qid_ représente la valeur du paramètre QId du paquet reçu immédiatement avant le dernier paquet reçu. Si les paramètres QId de ces deux paquets ont la même valeur, on peut en déduire certaines informations sur l'événement 121 correspondant à la réception du dernier paquet : il y a une bonne probabilité pour qu'aucune perte ne se soit produite et que le dernier paquet reçu corresponde à une nouvelle tranche (en anglais "slice") de la même AU dans la même couche de scalabilité que le paquet précédent. Cependant, l'événement 121 peut aussi correspondre à une erreur qui ne peut pas être détectée au moyen des seuls outils que constituent les paramètres TId, QId, DId et le message SEI. Ainsi, si une image est constituée de plusieurs tranches, la perte de certaines tranches ne peut pas être détectée. Si lors du test 105, les deux paquets consécutifs n'ont pas la même valeur de QId, on examine lors d'un test 107 si Qid = Qid +1. Si tel est le cas, on peut en déduire qu'il y a une bonne probabilité pour qu'aucune perte ne se soit produite et que le dernier paquet reçu transporte la couche de qualité suivante de la même AU (événement 123). Cependant, ici encore, il y a une incertitude car l'événement 123 peut correspondre à un changement d'AU qui peut cacher une perte de données. Lors du test 107, si Qid est différent de Qid_-F1, on peut en déduire qu'une perte s'est produite. Cependant, il n'est pas possible de déterminer si plusieurs NALs ont été perdues (événement 109). Lors du test 103, si Did est différent de Did , on examine lors d'un test 147 si Did = Did_-F1. Si ce n'est pas le cas, on peut en déduire qu'une perte s'est produite (événement 149). Cependant, ici encore, il est impossible de déterminer le nombre de NALs perdues. Si lors du test 147, Did = Did +1, on examine lors d'un test 151 si Qid = O. Si ce n'est pas le cas, on peut en déduire qu'une perte s'est produite (événement 153), mais on ne peut pas en déduire combien de NALs ont été perdues. Si Qid = 0, il y a une bonne probabilité pour qu'on ait reçu une nouvelle couche spatiale de la même AU que le paquet précédent (événement 155). Cependant, l'événement 155 peut également correspondre à la réception d'une nouvelle AU, qui peut cacher une perte. Si lors du test 101, les deux paquets consécutifs n'ont pas la même valeur de TId, on examine lors d'un test 111 si Tid = Tid +1. Si la différence entre ces deux valeurs de TId est supérieure à 1 (test 111 négatif), on peut en déduire qu'une perte s'est produite (événement 125), sans cependant savoir précisément combien de NALs ont été perdues. Si Tid = Tid +1, on examine lors d'un test 113 si Did Did_), on peut en déduire que certaines NALs (correspondant à des couches de scalabilité spatiale) ont été perdues, sans cependant en connaître le nombre (événement 137). Si le test 115 est positif, on examine lors d'un test 117 si Qid Si le test 117 est négatif (c'est-à-dire si Qid Qid_), Qid et Qid_ devraient avoir la valeur 0 (test 119). Si tel est le cas, on peut en déduire qu'il y a une bonne probabilité pour qu'aucune perte ne se soit produite et que le dernier paquet reçu contienne une nouvelle AU (événement 143). Cependant, ici encore, si un changement illégal d'AU s'est produit, on ne peut pas identifier cette erreur. Si le test 119 est négatif, on peut en déduire qu'une perte s'est produite (événement 120) mais ici encore, sans savoir précisément combien de NALs (correspondant à des couches de scalabilité en qualité) ont été affectées. Ainsi, les seuls outils proposés par la norme SVC ne permettent pas de déterminer précisément si une perte s'est produite (événements 121, 123, 143, 145, 133, 155 sur la figure 1) et, lorsqu'une perte s'est effectivement produite, ils ne permettent pas de déterminer précisément combien de NALs sont affectées ni, a fortiori, quelle image est affectée par cette perte. Par ailleurs, les mécanismes de détection et de localisation d'erreurs habituels utilisent parfois des informations contenues dans les tranches, telles que le numéro d'image (FrameNum) et/ou le paramètre POC (en anglais "Picture Order Count"), présent dans l'image décodée et relatif notamment à l'ordre des images. Toutefois, ces informations ne sont pas disponibles au niveau réseau et ces mécanismes requièrent un décodage au moins partiel des tranches par le décodeur. Par ailleurs, les normes H.264 et SVC spécifient diverses façons de coder, dans l'en-tête de tranche (en anglais "slice header'), le paramètre POC mentionné ci-dessus. Une façon consiste à coder le paramètre POC par un codage prédictif (en anglais "predictive encoding"). Cependant, lorsqu'une perte de données vidéo se produit dans une NAL ayant un POC ainsi codé de façon prédictive, il devient impossible de récupérer le POC des images suivantes. Les techniques connues de détection et de localisation de pertes de données vidéo fondées sur les paramètres TId, DId, QId, FrameNum et POC sont alors inopérantes. La présente invention a pour but de remédier aux inconvénients de l'art antérieur. Dans ce but, la présente invention propose un procédé d'identification de pertes de données dans une séquence vidéo transmise entre un serveur et au moins un client sur un réseau de communication, la séquence vidéo comportant une pluralité de conteneurs de données vidéo, ces données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, les conteneurs de données vidéo étant transmis sur le réseau par l'intermédiaire d'une suite de paquets de transport de données, ce procédé d'identification de pertes de données étant remarquable en ce qu'il comporte une étape de détection et de localisation d'erreurs, consistant à détecter des pertes de données et à localiser les données vidéo affectées par lesdites pertes, l'étape de détection et de localisation d'erreurs ne nécessitant aucun décodage de données vidéo contenues dans les conteneurs de données vidéo 15 et consistant à : combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données vidéo et en déduire la détection des pertes de données et la localisation des 20 données vidéo affectées par ces pertes. Ainsi, l'invention permet de détecter et de localiser de façon précoce, au niveau réseau, des pertes de données (c'est-à-dire des données manquantes ou erronées), sans nécessiter d'information de la part du décodeur. Elle permet de déterminer non seulement les images qui ont été 25 affectées par des pertes, mais également l'influence de ces pertes sur la qualité de la séquence vidéo, et ce sans mettre en oeuvre le décodage des images. En particulier, grâce à la présente invention, il n'est pas nécessaire de décoder les tranches (en anglais "slices"). Ces décisions précoces sur les pertes peuvent être utilisées pour 30 une requête précoce de retransmission de données perdues. Les données perdues, c'est-à-dire les données manquantes ou erronées, peuvent ainsi être retransmises plus tôt. En outre, l'emplacement des erreurs peut être déterminé de façon précise. Toutes les pertes peuvent être détectées et localisées, sans incertitude. Par ailleurs, cela permet, au niveau réseau, un choix efficace des 5 méthodes de résistance aux erreurs ("error resilience methods") et une sélection efficace des couches décodées. Dans un mode particulier de réalisation, où la séquence vidéo comporte en outre au moins un conteneur d'informations descriptives, ces informations décrivant la séquence vidéo, le procédé d'identification de pertes 10 de données comporte en outre une étape de réception du conteneur d'informations descriptives et une étape de création d'une représentation d'un groupe d'images de la séquence vidéo. La représentation ainsi créée contribue à permettre de localiser les pertes de données. 15 Dans un mode particulier de réalisation, l'étape de réception du conteneur d'informations descriptives comporte : une opération d'extraction consistant à extraire des informations du conteneur d'informations descriptives, cette opération d'extraction étant effectuée une fois et une seule, 20 l'étape de création précitée utilisant les informations du conteneur d'informations descriptives. A titre d'exemple nullement limitatif, le conteneur d'informations descriptives peut être une NAL spécifique. Ces informations descriptives sont facilement détectables par un désassembleur de paquets (en anglais 25 "depacketizer'), car bien localisées dans une partie spécifique de la séquence vidéo, en l'occurrence, le conteneur d'informations descriptives. L'analyse des informations descriptives ne nécessite aucun décodage complexe : une simple lecture suffit. Cette analyse peut être effectuée en dehors du décodeur vidéo (par exemple, décodeur SVC) qui met 30 en oeuvre des opérations inverses de celles effectuées lors du codage vidéo hiérarchique. Une entité séparée, dédiée à cette analyse, peut être prévue. Selon une caractéristique particulière, la détection de pertes de données consiste à utiliser des informations relatives au rang des paquets de transport de données dans la suite de paquets de transport de données. Le fait de fonder la détection des pertes sur des paramètres simples tels que le rang des paquets de transport permet d'éviter de mettre en oeuvre une procédure complexe au niveau du décodeur. En outre, si aucune perte n'est détectée, la procédure de localisation des pertes n'est pas mise en oeuvre. Dans un mode particulier de réalisation où le procédé d'identification de pertes de données conforme à la présente invention met en oeuvre un protocole de transport du type RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof'), selon une caractéristique particulière, les paquets de transport sont des paquets RTP et les informations relatives au rang des paquets de transport dans la suite de paquets de transport sont les numéros de séquence RTP des paquets de transport. Le protocole RTP est particulièrement bien adapté à la procédure de détection des pertes et permet de la faciliter. Dans un mode particulier de réalisation, la séquence vidéo est codée conformément à la norme SVC (en anglais "Scalable Video Coding"). Grâce à un en-tête de NAL spécifique prévu dans la norme SVC, cette norme est particulièrement bien adaptée à la localisation des pertes et permet de faciliter cette localisation. Dans le même but que celui indiqué plus haut, la présente invention propose également un dispositif client dans un réseau de communication, comportant une unité de calcul, une unité de stockage et une unité de communication avec le réseau, l'unité de calcul coopérant avec l'unité de stockage et l'unité de communication avec le réseau, ce dispositif client étant remarquable en ce que l'unité de calcul est adaptée à identifier des pertes de données dans une séquence vidéo reçue en provenance d'un dispositif serveur, la séquence vidéo comportant une pluralité de conteneurs de données vidéo, les données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, les conteneurs de données vidéo étant reçus par le dispositif client en provenance du dispositif serveur, à travers le réseau, par l'intermédiaire d'une suite de paquets de transport de données, l'unité de calcul comportant une unité de détection et de localisation 5 d'erreurs, adaptée à détecter des pertes de données et à localiser les données vidéo affectées par ces pertes, l'unité de détection et de localisation d'erreurs intervenant sans nécessiter de décoder des données vidéo contenues dans les conteneurs de données vidéo et comportant : 10 un module pour combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données vidéo et un module pour en déduire la détection des pertes de données et la localisation des données vidéo affectées par ces pertes. 15 Toujours dans le même but, la présente invention propose également, comme application du procédé d'identification de pertes de données succinctement décrit ci-dessus, un procédé de réception d'une séquence vidéo transmise entre un serveur et au moins un client sur un réseau de communication, 20 la séquence vidéo comportant une pluralité de conteneurs de données vidéo, ces données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, les conteneurs de données vidéo étant transmis sur le réseau par l'intermédiaire d'une suite de paquets de transport de données, 25 ce procédé de réception étant remarquable en ce qu'il comporte : une étape de détection et de localisation d'erreurs, consistant à détecter des pertes de données et à localiser les données vidéo affectées par ces pertes, l'étape de détection et de localisation d'erreurs ne nécessitant aucun décodage de données vidéo contenues dans les conteneurs de données 30 vidéo et consistant à : combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données vidéo et en déduire la détection des pertes de données et la localisation des données vidéo affectées par ces pertes ; et une étape de sélection, consistant à sélectionner, en fonction de la localisation des données vidéo affectées par les pertes, au moins un niveau hiérarchique de données vidéo à ne pas décoder. On améliore ainsi le décodage, en prenant en compte le fait que les différents niveaux qui résultent du codage vidéo hiérarchique sont d'importance variable. Dans un mode particulier de réalisation du procédé de réception, l'étape de sélection comporte : un premier test, consistant à déterminer si un conteneur de données 15 vidéo qui correspond à une image appartenant à un niveau hiérarchique donné est perdu ; et une opération de marquage, consistant à marquer l'image comme étant perdue si, lors du premier test précité, un conteneur correspondant à cette image est déterminé comme étant perdu. 20 Dans un mode particulier de réalisation du procédé de réception, l'étape de sélection comporte en outre : un deuxième test, consistant à déterminer si une image de référence pour une image appartenant à un niveau hiérarchique donné est perdue ; et une opération de marquage, consistant à marquer l'image comme 25 étant perdue si, lors du deuxième test précité, une image de référence pour cette image est déterminée comme étant perdue. Dans un mode particulier de réalisation du procédé de réception, lors de l'étape de sélection, on sélectionne un niveau hiérarchique en fonction du nombre d'images appartenant à ce niveau hiérarchique qui ont été marquées 30 comme étant perdues. Selon une caractéristique particulière, ce nombre est comparé à un seuil qui dépend du niveau hiérarchique précité. Cela permet de traiter les niveaux hiérarchiques de manière différenciée, en leur accordant une importance variable. Dans un mode particulier de réalisation du procédé de réception, lorsque, lors de l'étape de sélection, on sélectionne un niveau hiérarchique, on sélectionne également un ou plusieurs niveaux hiérarchiques supérieurs au niveau sélectionné. Les caractéristiques du procédé de réception énoncées précédemment permettent d'accélérer le décodage, étant donné qu'on évite de décoder des niveaux qui sont supérieurs à un niveau qui a subi des pertes, c'est-à-dire qu'on n'a pas besoin de parcourir la totalité de la représentation de la séquence vidéo reçue. Dans un mode particulier de réalisation du procédé de réception, les étapes de détection et localisation et de sélection sont effectuées par niveau hiérarchique, en commençant par le niveau hiérarchique le plus bas. Cela permet de préserver la stabilité de la qualité du décodage sans avoir à parcourir toute la représentation de la séquence vidéo reçue. Toujours dans le même but, la présente invention propose aussi un dispositif client tel que succinctement décrit ci-dessus, ce dispositif client étant également remarquable en ce que l'unité de calcul comporte en outre un module pour sélectionner, en fonction de la localisation des données vidéo affectées par les pertes, au moins un niveau hiérarchique de données vidéo à ne pas décoder. Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il permet de mettre en oeuvre un procédé d'identification de pertes de données et/ou un procédé de réception tels que ceux succinctement décrits ci-dessus. Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, remarquable en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé d'identification de pertes de données et/ou un procédé de réception tels que ceux succinctement décrit ci-dessus, lorsque ce programme est chargé dans et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif client, du moyen de stockage d'informations et du produit programme d'ordinateur sont similaires à ceux des procédés succinctement décrits ci-dessus. Ces aspects et avantages ne sont donc pas répétés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1, déjà décrite, est un organigramme illustrant le principe du processus de détection de pertes de données disponible dans la norme SVC ; - la figure 2A représente de façon schématique, dans un mode particulier de réalisation, des éléments d'information utilisés par le procédé conforme à la présente invention, ainsi que des modules respectivement en charge de l'analyse de ces éléments d'information, dans un client au sens de l'architecture client/serveur, sur un réseau de communication ; - la figure 2B représente de façon schématique un mode particulier 20 de réalisation d'un système de transmission vidéo adapté à mettre en oeuvre la présente invention ; - la figure 3 est un organigramme illustrant les phases principales de traitement effectuées du côté du client conformément à la présente invention, dans un mode particulier de réalisation ; 25 - les figures 4 et 5 sont des organigrammes illustrant plus en détail, dans un mode particulier de réalisation, la phase d'identification illustrée sur la figure 3; - la figure 6 est un organigramme illustrant la phase d'analyse des couches scalables, préalable à la sélection des couches à décoder, comprise 30 dans la phase de sélection des couches scalables illustrée sur la figure 3, dans un mode particulier de réalisation ; et - la figure 7 est un organigramme illustrant la phase de sélection proprement dite des couches à décoder, comprise dans la phase de sélection des couches scalables illustrée sur la figure 3, dans un mode particulier de réalisation. Dans toute la suite, on considère une séquence vidéo transmise entre un serveur et un ou plusieurs client(s), sur un réseau de communication. Conformément à la présente invention, on cherche à identifier les pertes de données vidéo dans cette séquence, c'est-à-dire détecter des données vidéo manquantes ou erronées et les localiser. On décrit un exemple particulier de réalisation où les données vidéo sont codées conformément à une norme de codage vidéo avec compression de données telle que H.264 ou SVC, où intervient la notion d'entité NAL évoquée dans la partie introductive de la présente description. Dans cet exemple, nullement limitatif, on cherche à déterminer les 15 NALs perdues (manquantes ou erronées). Ce traitement a lieu du côté du client, au sens de l'architecture client/serveur. L'invention est décrite dans une application particulière consistant à sélectionner les couches hiérarchiques (en anglais "scalable layers") qui seront 20 fournies au décodeur pour être décodées et affichées avec une contrainte consistant à fournir une qualité constante au client. Comme représenté sur la figure 2B, un système de transmission vidéo adapté à mettre en oeuvre la présente invention comporte un serveur 1 et un client 2. 25 Le serveur 1 comporte une unité de stockage 4 qui mémorise une vidéo codée. Le serveur 1 comporte en outre une unité de calcul 3 adaptée à exécuter des programmes, ainsi qu'une unité réseau 5 adaptée à émettre des données vidéo sur le réseau. Une unité d'acquisition de données vidéo (non représentée), telle 30 qu'une caméra vidéo, peut être ajoutée afin de saisir des vidéos en direct, l'unité de calcul 3 prenant en charge la compression de la vidéo. Le client 2 comporte une unité de stockage 6 qui mémorise des programmes du client et une unité de calcul 7 adaptée à exécuter des programmes. L'unité de stockage 6 du client comporte notamment un ou plusieurs programme(s) qui comporte(nt) des séquences d'instructions pour mettre en oeuvre un procédé d'identification de pertes de données conforme à la présente invention, lorsque ce ou ces programme(s) est (sont) chargé(s) dans le client 2 et exécuté(s) par l'unité de calcul 7 du client. Le client 2 comporte également une unité réseau 8 adaptée à recevoir des paquets de données, ainsi qu'une unité d'affichage 9. Comme le montre la figure 2A, dans un mode particulier de réalisation, le procédé conforme à l'invention est mis en oeuvre par le client 2 sous forme logicielle, principalement, d'une part, dans un module 200 désassembleur de paquets (en anglais "depacketizer') et d'autre part, dans un module 202 de décodage SVC (appelé "décodeur SVC" sur le dessin) dans le cas, nullement limitatif, où les données vidéo sont codées suivant la norme SVC. La figure 2A représente un paquet RTP (dans l'exemple non limitatif où les données sont transportées sur le réseau suivant le protocole RTP) transportant une tranche SVC. Le dessin montre aussi l'emplacement, dans le paquet RTP, des données utilisées, par le procédé conforme à l'invention, pour la détection et la localisation des pertes de données, à savoir : • Numéro de séquence du paquet RTP et estampille temporelle du paquet RTP : dans l'en-tête RTP ; • Paramètres DId, QId et TId : dans l'en-tête dit d'extension SVC de 25 la NAL (en anglais "SVC NAL extension header') ; Les informations contenues dans l'en-tête RTP et les informations contenues dans l'en-tête de NAL sont gérées par le module 200 désassembleur de paquets. Les informations contenues dans l'en-tête de tranche sont gérées 30 par le module 202 de décodage SVC. Il est à noter que les paramètres FrameNum et POC (situés dans l'en-tête de tranche) ne sont pas utilisés par le procédé conforme à l'invention. Ils ont cependant été représentés afin de montrer que leur détermination nécessiterait un décodage par le décodeur SVC. La présente invention permet précisément de s'affranchir d'un tel décodage. Conformément à l'invention, on décode uniquement une NAL particulière, une fois et une seule, au début de la séquence vidéo : le message scalable SEI (en anglais "scalable Supplemental Enhancement Information message" ou "scalable SEI message" (voir étape 301 sur l'organigramme de la figure 3 décrite ci-après). Comme mentionné dans la partie introductive de la description, le message scalable SEI transporte des informations décrivant la séquence SVC. Ce processus de décodage particulier peut être effectué par un module dédié, à l'extérieur du décodeur SVC. Les principaux traitements effectués du côté du client sont résumés sur l'organigramme de la figure 3. Dans ce qui suit, on décrit ces traitements plus en détail, en liaison avec la figure 3 et en référence aux figures 2A et 2B décrites précédemment. Comme mentionné plus haut, une session vidéo débute à l'étape 301 par la réception d'un message scalable SEI. Ce message subit une analyse syntaxique (en anglais "is parsed") et toutes les données nécessaires à la création d'une représentation d'un groupe d'images ou GOP (en anglais "Group Of Pictures") sont extraites durant l'étape 301. Une telle représentation du GOP est créée lors d'une étape 303 et est mémorisée dans l'unité de stockage 6 du client. Puis les paquets suivants sont reçus (étape 305). Dans le mode particulier de réalisation décrit ici, le client reçoit le flux vidéo SVC sous forme de paquets RTP. Une boucle est alors effectuée, comportant l'étape 305 ainsi que les étapes 307, 309 et 311, comme suit. A l'étape 307, le désassembleur de paquets 200 extrait les NALs à partir des paquets RTP. Lors de l'extraction des NALs durant cette étape 307, le désassembleur de paquets 200 extrait également le numéro de séquence de paquet RTP ainsi que l'estampille temporelle. Puis lors d'une étape 309, le désassembleur de paquets 200 mémorise ces éléments d'information dans une mémoire tampon dans l'unité de stockage 6 du client. Le numéro de séquence de paquet RTP et l'estampille temporelle y demeurent stockés tant que la NAL correspondante n'est pas décodée par le décodeur SVC 202 et/ou supprimée de l'unité de stockage 6 du client par le désassembleur de paquets 200. Débutent ensuite les traitements de détection/localisation conformes à la présente invention. Ces traitements sont illustrés de façon résumée par le bloc 311 ("processus de détection/localisation") sur la figure 3 et sont effectués dans le désassembleur de paquets 200. Ils seront décrits en détail plus loin. Puis à l'étape suivante 315, on met en oeuvre un processus de sélection de couche(s) scalable(s). A l'étape suivante 317, le décodeur SVC 202 accède aux NALs précédemment traitées comme décrit ci-dessus et déroule le processus de décodage SVC de ces NALs, si toutefois ce décodage est possible, en fonction des éventuelles erreurs détectées et localisées précédemment dans les données. Lors de l'étape suivante 319, les images résultant de ce décodage SVC sont affichées. Il est à noter que, en parallèle au déroulement des étapes 315, 317 et 319 qui viennent d'être décrites, les étapes 305, 307, 309 et 311 (c'est-à-dire respectivement la réception des paquets, l'extraction de NAL, le stockage de numéro de séquence de paquet et le stockage d'estampille temporelle, ainsi que le processus de détection/localisation des erreurs) sont effectuées pour les paquets suivants et ce, tant que des paquets continuent à être reçus. Comme le montre la figure 4, conformément à la présente invention, le processus de détection/localisation de l'étape 311 de la figure 3 débute lors d'un test 401 qui consiste à comparer le numéro de séquence, noté SeqNum, du dernier paquet reçu, et le numéro de séquence, noté SeqNum_, du paquet reçu immédiatement avant le dernier paquet reçu. Si la différence entre ces deux numéros de séquence est de 1 (test 401 positif), on peut en déduire qu'aucune perte ne s'est produite. Dans ce cas, le processus de détection/localisation prend fin. Sinon (test 401 négatif), on sait déjà à ce stade qu'au moins un paquet est perdu, sans cependant encore savoir quelle NAL est affectée. Dans ce cas, on effectue un test 403, consistant à comparer l'estampille temporelle, notée Timestamp, du dernier paquet reçu, et l'estampille temporelle, notée Timestamp_, du paquet reçu immédiatement avant le dernier paquet reçu. Si ces deux paquets consécutifs n'ont pas la même valeur d'estampille temporelle (test 403 négatif), on passe à l'étape 501, décrite plus loin en liaison avec la figure 5. Si en revanche les deux paquets consécutifs ont la même valeur d'estampille temporelle (test 403 positif), on compare lors du test suivant 407 Did et Did_. Si Did = Did , on teste si Qid = Qid_ lors du test suivant 409. Si le test 409 est positif (Qid = Qid_), cela signifie qu'il manque au moins une tranche dans la même AU, dans la même couche spatiale et dans la même couche de qualité que celles de la NAL reçue en dernier (événement 425). Si le test 409 est négatif, on teste si Qid = Qid_+1 lors du test 411. Si le test 411 est positif (Qid = Qid_-F1), on peut en déduire qu'il manque au moins une tranche dans la même AU et dans la même couche spatiale et avec une couche de qualité égale à Qid ou Qid_ (événement 427). Si le test 411 est négatif (Qid n'est pas égal à Qid_-F1), on peut en déduire que les NALs pour lesquelles QId est compris entre Qid_ et Qid sont 25 perdues (événement 413). Si les deux paquets consécutifs ont des valeurs différentes de Did (test 407 négatif), on teste lors d'un test 415 si Did = Did_-F1. Si ce n'est pas le cas (test 415 négatif), on peut en déduire que les NALs pour lesquelles Did est compris entre Did et Did_ sont perdues (événement 421). 30 Sinon, c'est-à-dire si Did = Did_+1 (test 415 positif), on teste si Qid = 0 (test 417). Si Qid n'est pas nul (test 417 positif), cela signifie que des NALs avec QId = 0 et QId L'unité de temps autorisée A peut être déduite de Timestamp_, à partir de la représentation du GOP créée à l'étape 303 (figure 3) et en suivant les règles relatives à l'ordre de décodage des NALs SVC telles que définies dans la norme SVC. Ainsi, par exemple, une NAL sera décodée avant toute NAL qui en dépend. De plus, toute NAL correspondant à une entité AU sera décodée avant toute autre NAL d'une autre AU - l'entité AU représentant, comme mentionné dans la partie introductive de la description, l'ensemble des NALs correspondant à une même image codée. Le test 501 et l'étape 503 sont suivies par le test 505, qui consiste à déterminer si Did Qid_ et DId > Did_ à la fin de la dernière AU (événement 509). Le test 507 et l'événement 509 sont suivis par un test 511 qui consiste à déterminer si Did prend sa valeur minimale pour la valeur courante de Tid, c'est-à-dire si Did = minDid(Tid). Si tel est le cas (test 511 positif), on peut en déduire (événement 513) qu'une nouvelle AU a été reçue et qu'il manque au moins une tranche, soit avec DId = minDid(Tid) dans l'AU courante, soit avec DId = MaxDid ou QId = MaxQid dans l'AU reçue précédemment. Si le test 511 est négatif, c'est-à-dire si Did est différent de minDid(Tid), on peut en déduire qu'il manque des couches spatiales avec DId Si le test 517 est négatif, c'est-à-dire si Did et Did_ ne sont pas égaux et sont non nuls, on retourne au test 507 décrit plus haut. Chaque fois qu'un paquet est reçu, le processus de sélection de couche(s) scalable(s) 315 (figure 3) est activé. Comme le montre la figure 6, le processus de sélection de couche(s) scalable(s) 315 consiste tout d'abord à déterminer, lors d'un test 601, si une perte de NAL a été identifiée lors de la précédente activation du processus de détection/localisation d'erreurs conforme à la présente invention. Si aucune perte n'a été détectée lors de cette dernière activation de la détection/localisation d'erreurs, toutes les couches sont sélectionnées (étape 603) pour être décodées et le décodage de NAL est effectué à l'étape 317 (figure 3). Si en revanche une perte a été détectée lors de l'activation précédente de la détection/localisation d'erreurs, le processus de sélection de couche(s) scalable(s) 315 consiste ensuite à initialiser les variables Did, Qid, Tid et NumFrame à la valeur 0 (étape 605). Puis lors d'un test 607, on recherche la NAL qui a été identifiée comme étant perdue lors de l'exécution du processus de détection/localisation. Si la NAL ayant une valeur donnée de Did, Qid et Tid (ce qu'on note NAL(Did, Qid, Tid)) est perdue, l'image correspondante est marquée comme perdue (même si seule une tranche de cette image est perdue) lors d'une étape 613. Cette étape est suivie d'un test 615 qui sera décrit ci-après. Si le test 607 est négatif, c'est-à-dire que la NAL considérée (NAL(Did, Qid, Tid)) n'est pas perdue, on détermine lors d'un test 609 si l'image de référence de cette NAL avait été perdue. Si ce n'est pas le cas (test 609 négatif), on effectue le test 615 décrit ci-après. Si en revanche l'image de référence de cette NAL avait été perdue (test 609 positif), l'image concernée est marquée comme perdue (étape 611). Le test 615 consiste à déterminer si toutes les couches de qualité ont été analysées. Pour cela, on teste si Qid MaxQid, où MaxQid désigne la plus haute couche de qualité. Si toutes les couches de qualité n'ont pas encore été analysées, c'est-à-dire si Qid MaxQid (test 615 positif), on augmente Qid, en incrémentant par exemple d'une unité la valeur de Qid (étape 616), puis le processus se poursuit avec une nouvelle NAL (retour au test 607). Si toutes les valeurs de Qid ont été testées (test 615 négatif), on passe au test 617, lors duquel on teste si toutes les couches spatiales ont été analysées. Pour cela, on teste si Did MaxDid, où MaxDid désigne la plus haute couche spatiale. Si toutes les couches spatiales n'ont pas été analysées (test 617 positif), lors d'une étape 619 on augmente Did, en incrémentant par exemple d'une unité la valeur de Did, et on attribue à Qid la valeur minimale autorisée de Qid pour la valeur courante de Tid (notée minQid(Tid)). Si en revanche toutes les valeurs de Did et de Qid pour l'AU courante ont été analysées, on examine lors d'un test 621 si toutes les images dans le GOP pour la couche temporelle courante (notée Tid) ont été analysées. Pour cela, on teste si NumFrame NumFrame (Did,Tid). Si les images du GOP pour Tid n'ont pas toutes été analysées (test 621 positif), le processus se poursuit avec l'image suivante (étape 623). En outre, à l'étape 623, le paramètre DId est fixé à sa valeur minimale autorisée pour la valeur courante de Tid (cette valeur minimale est notée MinDid(Tid)). De plus, à l'étape 623, le paramètre QId est fixé à sa valeur minimale autorisée pour la valeur courante de Tid (cette valeur minimale est notée MinQid(Tid)). Lorsque toutes les images de la couche temporelle courante ont été analysées (test 621 négatif), on examine lors d'un test 625 si toutes les 25 couches temporelles ont été testées. Pour cela, on teste si Tid MaxTid, où MaxTid désigne la plus haute couche temporelle. Si les images de la couche temporelle courante n'ont pas toutes été analysées (test 625 positif), on passe à l'étape 629, où on passe à la couche temporelle supérieure (Tid + 1) et où on fixe les paramètres DId et QId 30 à leurs valeurs minimales respectives pour la valeur courante de Tid (ces valeurs minimales sont respectivement notées minDid(Tid) et minQid(Tid). Lorsque toutes les images de la couche temporelle courante ont été analysées (test 625 négatif), toutes les images perdues, soit directement (par perte de paquets), soit indirectement (par propagation d'erreurs) sont identifiées (état 631). Le processus de sélection des couches décodées peut alors débuter. Ce processus est illustré sur l'organigramme de la figure 7. Le processus de sélection débute lors d'une étape 701 par l'initialisation de Did, Qid et Tid à la valeur 0. De plus, le processus démarre avec la première image ayant les valeurs courantes de Did et Tid (soit NumFrame(Did, Tid)=0). Ces variables vont permettre d'analyser (en anglais "to parse") toute la structure du GOP. En outre, une variable Nloss(x,y,z) désignant le nombre de pertes est aussi initialisée à la valeur nulle lors de l'étape 701 (les variables x, y et z prenant respectivement toutes les valeurs possibles de Did, Qid et Tid). Puis lors d'un test 703, on examine si l'image considérée est perdue. Si elle n'est pas perdue (test 703 négatif), l'image concernée est marquée comme affichée dans la représentation de la structure du GOP (étape 705). L'étape 705 est suivie d'un test 717 décrit plus loin. Si en revanche l'image considérée est perdue (test 703 positif), on incrémente la variable Nloss(Did,Qid,Tid) d'une unité (étape 707). Puis lors d'un test 709, on examine si la valeur de la variable Nloss(Did,Qid,Tid) est strictement supérieure à un seuil qui dépend des valeurs de Did, Qid et Tid. Ce seuil est noté Th(Did,Qid,Tid). Il représente la quantité acceptable de pertes pour un triplet donné de valeurs de Did, Qid et Tid. En effet, chaque triplet représente une couche scalable. Etant donné que certaines couches sont plus importantes que d'autres, le niveau de pertes acceptable ne peut être le même pour toutes les couches. Si le seuil n'est pas dépassé (test 709 négatif), on passe au test 717. Sinon (test 709 positif), toutes les images avec DId Did, QId Qid et TId Tid sont marquées comme non affichées lors d'une étape 711. Puis, lors d'une étape 713, on modifie les valeurs de MaxQid, de MaxTid et de MaxDid. On évite ici l'analyse (en anglais "parsing") de l'intégralité de la structure du GOP si on sait déjà que la qualité des couches suivantes ne sera pas acceptable. De plus, lors de l'étape 713, la valeur de MaxQid pour les valeurs de DId supérieures ou égales à Did et pour les valeurs de TId supérieures ou égales à Tid est fixée, soit à la valeur (Qid ù 1), soit à la valeur nulle si Qid = 0. Toujours à l'étape 713, la valeur de MaxTid pour les valeurs de DId supérieures ou égales à Did est fixée, soit à la valeur (Tid ù 1), soit à la valeur nulle si Tid = 0, et la valeur de MaxDid est fixée, soit à la valeur (Did ù 1), soit à la valeur nulle si Did = 0. L'étape 713 est suivie par un test 719 qui sera décrit plus loin. Lors du test 717, on examine si toutes les images avec le triplet courant (Did, Qid, Tid) ont été traitées. Si les images correspondant à ce triplet n'ont pas encore toutes été traitées (test 717 négatif), on passe à l'image suivante (étape 715) puis on retourne au test 703 décrit plus haut. Lorsque toutes les images ayant le triplet courant (Did, Qid, Tid) ont été traitées (test 717 positif), on passe au test 719. Lors du test 719, on examine si Did a atteint sa valeur maximale. Pour cela, on teste si la valeur Did est inférieure ou égale à MaxDid. Si Did n'a pas atteint sa valeur maximale (test 719 positif), on augmente Did, en incrémentant par exemple d'une unité la valeur de Did (étape 721), puis on retourne au test 703. Si Did a atteint sa valeur maximale MaxDid (test 719 négatif), on effectue un test 723, consistant à examiner si Tid a atteint sa valeur maximale pour la valeur courante de Did. Pour cela, on teste si la valeur Tid est inférieure ou égale à MaxTid(Did). Si Tid n'a pas atteint cette valeur maximale (test 723 positif), on augmente Tid, en incrémentant par exemple d'une unité la valeur de Tid (étape 725), puis on retourne au test 703. De plus, à l'étape 725, Did est réinitialisé à sa valeur minimale pour la valeur donnée de Tid. Si Tid a atteint sa valeur maximale pour la valeur courante de Did, soit Tid = MaxTid(Did) (test 723 négatif), on effectue un test 727, consistant à examiner si Qid a atteint sa valeur maximale pour les valeurs courantes de Did et Tid. Pour cela, on teste si la valeur Qid est inférieure ou égale à MaxQid(Did,Tid). Si Qid n'a pas atteint cette valeur maximale (test 727 positif), on augmente la valeur de Qid, en incrémentant par exemple d'une unité la valeur de Qid (étape 729), puis on retourne au test 703. De plus, à l'étape 729, Did est réinitialisé à sa valeur minimale pour Tid = 0 et Tid est réinitialisé à la valeur nulle. Si Qid a atteint sa valeur maximale pour les valeurs courantes de Did et Tid, soit Qid = MaxQid(Did,Tid) (test 727 négatif), le processus de sélection de couche(s) scalable(s) 315 est terminé. Il est à noter que, dans les organigrammes des figures 4 à 7, les descriptions des tests consistant à tester, soit si une valeur est atteinte et/ou dépassée, soit si une valeur est strictement supérieure à un seuil, soit si toutes les images ont été traitées, etc., ont été données à titre d'exemples nullement limitatifs, conformément aux modes particuliers de réalisation décrits. En variante, ces tests pourraient tout aussi bien consister à tester la condition inverse, à savoir, respectivement, soit si la valeur considérée n'est pas atteinte et/ou n'est pas dépassée, soit si la valeur considérée est inférieure ou égale au seuil fixé, soit s'il reste au moins une image non encore traitée, etc. Les traitements illustrés sur la figure 7 sont suivis par l'étape 317 de décodage de NAL illustrée sur la figure 3. Avant de décoder la NAL courante, le décodeur SVC 202 illustré sur la figure 2 examine si l'image concernée a été marquée comme étant perdue, dans la structure du GOP mémorisée dans l'unité de stockage 6 du client. Conformément à la présente invention, si l'image courante a été marquée comme perdue, le décodeur SVC 202 rejette la NAL courante sans la décoder. Si cette image n'est pas marquée comme perdue, la NAL est décodée. Le résultat de l'exécution des traitements décrits précédemment et illustrés sous forme résumée sur la figure 3 est la sélection d'un jeu de couches scalables, à décoder par un décodeur. Il est à noter que les traitements décrits en liaison avec les figures 4 à 7 peuvent être mis en oeuvre par des noeuds réseau dits intelligents, du type MANE ("Media Aware Network Bernent"), évoqués dans la partie introductive de la présente description. Dans ce cas, le résultat de l'étape 315 (processus de sélection de couche(s) scalable(s)), au lieu d'être un jeu de couches scalables à décoder, est un jeu de couches scalables à transmettre. En outre, dans le cas d'une telle mise en oeuvre, l'étape 317 de décodage de NAL et l'étape 319 d'affichage sont remplacées par une étape consistant à transmettre sur le réseau uniquement la ou les couche(s) scalable(s) qui aura (auront) été sélectionnée(s). REVENDICATIONS1. Procédé d'identification de pertes de données dans une séquence vidéo transmise entre un serveur (1) et au moins un client (2) sur un réseau de 5 communication, ladite séquence vidéo comportant une pluralité de conteneurs de données vidéo, lesdites données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, lesdits conteneurs de données vidéo étant transmis sur ledit 10 réseau par l'intermédiaire d'une suite de paquets de transport de données, ledit procédé d'identification de pertes de données étant caractérisé en ce qu'il comporte une étape (311) de détection et de localisation d'erreurs, consistant à détecter des pertes de données et à localiser les données vidéo affectées par lesdites pertes, 15 ladite étape (311) de détection et de localisation d'erreurs ne nécessitant aucun décodage de données vidéo contenues dans lesdits conteneurs de données vidéo et consistant à : combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données 20 vidéo et en déduire la détection desdites pertes de données et la localisation des données vidéo affectées par lesdites pertes. 2. Procédé d'identification de pertes de données selon la revendication 1, dans lequel ladite séquence vidéo comporte en outre au moins 25 un conteneur d'informations descriptives, lesdites informations décrivant ladite séquence vidéo, caractérisé en ce qu'il comporte en outre une étape (301) de réception dudit conteneur d'informations descriptives et une étape (303) de création d'une représentation d'un groupe d'images de ladite séquence vidéo. 3. Procédé d'identification de pertes de données selon la 30 revendication 2, caractérisé en ce que ladite étape (301) de réception dudit conteneur d'informations descriptives comporte : une opération d'extraction consistant à extraire des informations dudit conteneur d'informations descriptives, ladite opération d'extraction étant effectuée une fois et une seule, ladite étape de création (303) utilisant lesdites informations dudit conteneur d'informations descriptives. 4. Procédé d'identification de pertes de données selon la revendication 1, 2 ou 3, caractérisé en ce que ladite détection de pertes de données consiste à utiliser des informations relatives au rang des paquets de transport de données dans ladite suite de paquets de transport de données. 5. Procédé d'identification de pertes de données selon la revendication 4, mettant en oeuvre un protocole de transport du type RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof'), caractérisé en ce que lesdits paquets de transport sont des paquets RTP et en ce que lesdites informations relatives au rang des paquets de transport dans ladite suite de paquets de transport sont les numéros de séquence RTP desdits paquets de transport. 6. Procédé d'identification de pertes de données selon l'une quelconque des revendications précédentes, caractérisé en ce que la séquence vidéo est codée conformément à la norme SVC (en anglais "Scalable Video Coding"). 7. Dispositif client (2) dans un réseau de communication, comportant des moyens (7) de calcul, des moyens (6) de stockage et des moyens (8) de communication avec ledit réseau, lesdits moyens (7) de calcul coopérant avec lesdits moyens (6) de stockage et lesdits moyens (8) de communication avec le réseau, ledit dispositif client étant caractérisé en ce que lesdits moyens (7) de calcul sont adaptés à identifier des pertes de données dans une séquence vidéo reçue en provenance d'un dispositif serveur (1), ladite séquence vidéo comportant une pluralité de conteneurs de données vidéo, lesdites données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, lesdits conteneurs de données vidéo étant reçus par ledit dispositif client (2) en provenance dudit dispositif serveur (1), à travers ledit réseau, par l'intermédiaire d'une suite de paquets de transport de données, lesdits moyens (7) de calcul comportant des moyens de détection et de localisation d'erreurs, adaptés à détecter des pertes de données et à localiser les données vidéo affectées par lesdites pertes, lesdits moyens de détection et de localisation d'erreurs intervenant sans nécessiter de décoder des données vidéo contenues dans lesdits conteneurs de données vidéo et comportant : des moyens pour combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données vidéo et des moyens pour en déduire la détection desdites pertes de données et la localisation des données vidéo affectées par lesdites pertes. 8. Procédé de réception d'une séquence vidéo transmise entre un serveur (1) et au moins un client (2) sur un réseau de communication, ladite séquence vidéo comportant une pluralité de conteneurs de données vidéo, lesdites données vidéo étant codées selon un codage vidéo hiérarchique mettant en oeuvre un nombre prédéterminé de niveaux hiérarchiques, lesdits conteneurs de données vidéo étant transmis sur ledit réseau par l'intermédiaire d'une suite de paquets de transport de données, ledit procédé de réception étant caractérisé en ce qu'il comporte : une étape (311) de détection et de localisation d'erreurs, consistant à détecter des pertes de données et à localiser les données vidéo affectées par lesdites pertes, ladite étape (311) de détection et de localisation d'erreurs ne nécessitant aucun décodage de données vidéo contenues dans lesdits conteneurs de données vidéo et consistant à : combiner des informations provenant de paquets de transport et des informations provenant d'en-têtes de conteneurs de données vidéo et en déduire la détection desdites pertes de données et la localisation des données vidéo affectées par lesdites pertes ; et une étape (315) de sélection, consistant à sélectionner, en fonction de la localisation des données vidéo affectées par lesdites pertes, au moins un niveau hiérarchique de données vidéo à ne pas décoder. 9. Procédé de réception selon la revendication 8, caractérisé en ce que ladite étape (315) de sélection comporte : un premier test (607), consistant à déterminer si un conteneur de données vidéo qui correspond à une image appartenant à un niveau hiérarchique donné est perdu ; et une opération (613) de marquage, consistant à marquer ladite image comme étant perdue si, lors dudit premier test (607), un conteneur correspondant à ladite image est déterminé comme étant perdu. 10. Procédé de réception selon la revendication 9, caractérisé en ce que ladite étape (315) de sélection comporte : un deuxième test (609), consistant à déterminer si une image de 15 référence pour une image appartenant à un niveau hiérarchique donné est perdue ; et une opération (611) de marquage, consistant à marquer ladite image comme étant perdue si, lors dudit deuxième test (609), une image de référence pour ladite image est déterminée comme étant perdue. 20 11. Procédé de réception selon la revendication 10, caractérisé en ce que, lors de ladite étape (315) de sélection, on sélectionne (709) un niveau hiérarchique en fonction du nombre d'images appartenant audit niveau hiérarchique qui ont été marquées comme étant perdues. 12. Procédé de réception selon la revendication 11, caractérisé en ce 25 que ledit nombre est comparé à un seuil qui dépend dudit niveau hiérarchique. 13. Procédé de réception selon la revendication 11 ou 12, caractérisé en ce que lorsque, lors de ladite étape (315) de sélection, on sélectionne (709) un niveau hiérarchique, on sélectionne également un ou plusieurs niveaux hiérarchiques supérieurs audit niveau sélectionné. 30 14. Procédé de réception selon l'une quelconque des revendications 8 à 13, caractérisé en ce que les étapes de détection et localisation (311) et de sélection (315) sont effectuées par niveau hiérarchique, en commençant par le niveau hiérarchique le plus bas. 15. Dispositif client (2) selon la revendication 7, caractérisé en ce que lesdits moyens (7) de calcul comportent en outre des moyens pour sélectionner, en fonction de la localisation des données vidéo affectées par lesdites pertes, au moins un niveau hiérarchique de données vidéo à ne pas décoder. 16. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet de mettre en oeuvre un procédé d'identification de pertes de données selon l'une quelconque des revendications 1 à 6 et/ou un procédé de réception selon l'une quelconque des revendications 8 à 14. 17. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé d'identification de pertes de données selon l'une quelconque des revendications 1 à 6 et/ou un procédé de réception selon l'une quelconque des revendications 8 à 14, lorsque ce programme est chargé dans et exécuté par l'appareil programmable.