FR2929787A1 - Procede et dispositif de traitement d'un flux de donnees - Google Patents

Procede et dispositif de traitement d'un flux de donnees Download PDF

Info

Publication number
FR2929787A1
FR2929787A1 FR0852260A FR0852260A FR2929787A1 FR 2929787 A1 FR2929787 A1 FR 2929787A1 FR 0852260 A FR0852260 A FR 0852260A FR 0852260 A FR0852260 A FR 0852260A FR 2929787 A1 FR2929787 A1 FR 2929787A1
Authority
FR
France
Prior art keywords
data
data stream
decoding
erroneous
decoded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0852260A
Other languages
English (en)
Other versions
FR2929787B1 (fr
Inventor
Christophe Gisquet
Floch Herve Le
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0852260A priority Critical patent/FR2929787B1/fr
Priority to US12/417,359 priority patent/US8650469B2/en
Publication of FR2929787A1 publication Critical patent/FR2929787A1/fr
Application granted granted Critical
Publication of FR2929787B1 publication Critical patent/FR2929787B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045Arrangements at the receiver end

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Un procédé de traitement d'un flux de données codées avant décodage comporte une étape de détection de données manquantes ou erronées dans le flux de données codées.Il comporte une étape de génération (303, 304, 306) d'une suite de données prête au décodage formée à partir du flux de données codées, et d'une suite de données additionnelles fournissant une information représentative de la position des données manquantes ou erronées détectées.

Description

1 La présente invention concerne un procédé et un dispositif de traitement d'un flux de données. Plus particulièrement, elle concerne le traitement d'un flux de données codées avant décodage. Lors de la transmission de données dans un réseau, des erreurs peuvent survenir. A titre d'exemple nullement limitatif, les données transmises sur un réseau de communication à commutation de paquets sont organisées en paquets de données binaires et les erreurs auxquelles ces communications sont généralement assujetties sont des erreurs sur les données constituant un paquet réseau, ainsi que des pertes de paquets réseau complets. Ces erreurs sur les données constituant un paquet sont des données manquantes ou erronées dans le paquet réseau, par exemple, une inversion de la valeur d'une ou plusieurs donnée(s) binaire(s) ou la perte d'une ou plusieurs donnée(s).
Ces erreurs sont typiquement dues à la nature du canal de transmission. La perte de paquets réseau est typiquement due à des congestions du réseau, ainsi qu'au rejet de paquets réseau corrompus, c'est-à-dire comportant une ou plusieurs erreur(s) et/ou omission(s).
Les erreurs de bits peuvent être indiquées par : - une couche réseau inférieure, ou - des codes correcteurs ayant été incapables de corriger une erreur mais ayant pu au moins cerner sa position. Ainsi, lorsqu'un flux de données codées contenant la charge utile d'au moins un paquet réseau arrive à un décodeur afin d'être décodé, et que ce flux de données comporte une erreur, le décodeur peut subir une désynchronisation lors de la lecture de cette erreur. 2
Certains décodeurs, lorsqu'ils détectent qu'une erreur est survenue, passent en mode de resynchronisation, c'est-à-dire qu'ils recherchent un marqueur de synchronisation indiquant le début d'une séquence de données ou le début d'un paquet de données codées, par exemple des données vidéo.
Néanmoins, cette erreur étant détectée une certaine durée après être survenue, le décodeur continue de lire les données du flux de données. Ces données ne sont donc pas décodées correctement, étant donné que le décodeur est désynchronisé après la lecture de l'erreur. En outre, entre le moment où le décodeur lit l'erreur (moment où il se désynchronise) et le moment où le décodeur sait qu'une erreur s'est produite (moment où il se met en mode de resynchronisation), le décodeur, désynchronisé, peut interpréter le début d'un paquet de données codées de manière erronée. Ainsi, les données suivantes de ce paquet de données codées sont interprétées de manière erronée.
Dans les deux cas, des données qui étaient valides (c'est-à-dire qui ne contenaient pas de données erronées) sont mal décodées. Ainsi, en plus de la présence d'erreurs dans le flux de données pour les raisons exposées ci-dessus, ces erreurs peuvent se propager dans le flux de données, provoquant ainsi des erreurs additionnelles.
La norme ISO/IEC 14496-2, "Information technology - coding of audio-visual objects - part 2: Visuaf' décrit l'attribution d'une valeur prédéterminée à une donnée appartenant au flux de données afin d'indiquer, au sein du flux de données, la présence d'une erreur. Cette donnée indiquant la présence d'une erreur consiste en un bit 25 situé au début du flux de données correspondant à une image. Dans la norme MPEG-4, une image est nommée VOP (de l'anglais "Video Object Plane"). Plus particulièrement, le bit est situé dans une unité d'information appelée GOV ou GOP (de l'anglais "Group of Video Object Plane") située avant une image ou VOP de type I-VOP (de l'anglais "Infra coded 30 VOP'). Ce type de VOP contient toutes les informations nécessaires pour être décodé par le décodeur. 3
Les images ou VOP peuvent également être de type P-VOP (de l'anglais "Predictive coded VOP'). Ce type de VOP nécessite une image de référence pour son décodage. Les images ou VOP peuvent aussi être de type B-VOP (de l'anglais "Bidirectionally-predictive coded VOP'), nécessitant deux images de référence, dont au moins une de type P-VOP. Dans le cadre de l'utilisation de ce bit, une image de type B-VOP utilise comme références une image de type I-VOP (la précédente dans le flux de données) et une image de type P-VOP (la suivante, dans le flux de données).
Lorsque le bit indiquant la présence d'une erreur a une valeur "1", le décodeur est averti du fait que le premier B-VOP ou la première séquence de B-VOPs consécutifs situés après le I-VOP qui se trouve au début du flux de données ne seront pas correctement décodés, dès lors que le P-VOP qui devrait suivre le ou les B-VOPs n'est pas présent dans le flux de données.
Le décodeur prend ainsi la décision de ne pas afficher ces B-VOPs ou images. Ainsi, à l'aide d'un bit situé au début du flux de données, le décodeur est prévenu de l'existence d'une erreur. Néanmoins, la possibilité d'avertir le décodeur de la présence d'une erreur par l'intermédiaire de ce bit est limitée au type d'erreur décrit ci-dessus. Le bit ne peut pas être utilisé pour signaler d'autres types d'erreurs. Par ailleurs, il est situé à une position fixe dans le flux de données, ce qui ne permet pas de localiser les erreurs. Le document US-A-5 778 191 propose d'insérer des points de synchronisation dans des positions fixes du train binaire produit par un codeur, afin d'améliorer la détection d'erreurs et la resynchronisation d'un décodeur. Cette solution, en plus de ne pas permettre de localiser la position exacte des erreurs, a une influence sur le format de compression, et cela implique des incompatibilités des formats avec certaines normes.
La présente invention a pour but de remédier à au moins un des inconvénients précités, en proposant un procédé de traitement d'un flux de 4
données et un dispositif associé à ce procédé, permettant notamment de connaître la position exacte d'une erreur présente dans un flux de données. Dans ce but, la présente invention propose un procédé de traitement d'un flux de données codées avant décodage, comportant une étape de détection de données manquantes ou erronées dans le flux de données. Selon l'invention, le procédé comporte une étape de génération d'une suite de données prête au décodage formée à partir du flux de données codées, et d'une suite de données additionnelles fournissant une information représentative de la position des données manquantes ou erronées détectées.
Ainsi, la présence des données erronées dans la suite de données prête au décodage est signalée au décodeur au moyen de la suite de données additionnelles. En outre, la suite de données additionnelles signale l'endroit où des données manquent dans la suite de données prête au décodage.
Par conséquent, le décodeur connaît les positions, dans la suite de données prête au décodage, des données erronées ou manquantes détectées. Avantageusement, le procédé comporte en outre une étape de concaténation, à la suite de données prête au décodage, d'une suite de données de remplissage de façon à obtenir une suite de données de longueur prédéterminée. Par conséquent, le décodeur, désynchronisé du fait de la lecture de l'erreur, continue le décodage de la suite de données prête au décodage en lisant des données de remplissage au lieu de lire des données qui suivent l'erreur dans le flux de données. Ainsi, on évite de décoder de façon incorrecte les données qui suivent l'erreur dans le flux de données. Selon une caractéristique préférée, le procédé comporte : - une étape de décodage d'une partie de la suite de données prête au décodage ayant la longueur prédéterminée précitée ; - une étape de comparaison de la position de la dernière donnée 30 décodée de la partie de la suite de données prête au décodage, à une position des données erronées ou manquantes dans la suite de données additionnelles.
Ainsi, une fois que le décodeur a fini le décodage d'une partie de la suite de données prête au décodage, il vérifie si cette partie de la suite de données prête au décodage comporte des erreurs, c'est-à-dire des données manquantes ou erronées. 5 Avantageusement, les données de la suite de données prêtes au décodage, situées entre la position de la dernière donnée décodée et la position des données représentant le début d'un paquet de données codées, ne sont pas décodées, lorsqu'à l'étape de comparaison, la position de la dernière donnée décodée est supérieure à la position des données erronées ou manquantes. Lorsque la position de la dernière donnée décodée est supérieure à la position des données erronées ou manquantes, la partie décodée de la suite de données prête au décodage contient des données manquantes ou erronées. Ainsi, le décodeur ne lit pas les données qui suivent la partie de la suite prête au décodage décodée, et se met en mode de lecture des données de synchronisation, c'est-à-dire que le décodeur cherche à se resynchroniser. Par ailleurs, une seconde partie de la suite de données prête au décodage est décodée lorsqu'à l'étape de comparaison, la position de la dernière donnée décodée est inférieure à la position des données erronées ou manquantes. En effet, lorsque la position de la dernière donnée décodée est inférieure à la position des données erronées ou manquantes, la partie de la suite de données prête au décodage décodée ne contient pas de données manquantes ou erronées.
Le décodeur va ainsi continuer le décodage de la suite prête au décodage. Selon un mode de réalisation, l'information représentative de la position comporte la position de la donnée située devant les données manquantes ou erronées dans la partie de la suite de données prête au décodage. Ainsi, la position du début des données manquantes ou erronées est indiquée au décodeur d'une manière simple, dès lors que la position de la 6
dernière donnée présente dans la suite de données prête au décodage est connue par le désencapsuleur à tout moment. Dans le même but que celui indiqué plus haut, la présente invention propose également un dispositif de traitement d'un flux de données codées avant décodage, comportant des moyens de détection de données manquantes ou erronées dans le flux de données codées. Selon l'invention, le dispositif comporte des moyens de génération d'une suite de données prête au décodage formée à partir du flux de données codées, et d'une suite de données additionnelles fournissant une information représentative de la position des données manquantes ou erronées détectées. Avantageusement, le dispositif comporte en outre des moyens de concaténation, à la suite de données prête au décodage, d'une suite de données de remplissage de façon à obtenir une suite de données de longueur prédéterminée.
Selon une caractéristique préférée, le dispositif comporte : - des moyens de décodage d'une partie de la suite de données prête au décodage ayant la longueur prédéterminée précitée ; - des moyens de comparaison de la position de la dernière donnée décodée de la partie de la suite de données prête au décodage, à une position des données erronées ou manquantes dans la suite de données additionnelles. Toujours dans le même but, la présente invention propose également un système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, comprenant au moins un dispositif terminal équipé d'un dispositif tel que succinctement décrit ci-dessus. Toujours dans le même but, la présente invention propose également un moyen de stockage d'informations pouvant être lues par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il est adapté à mettre en oeuvre un procédé tel que succinctement décrit ci-dessus, lorsque les informations stockées sont lues par l'ordinateur ou le microprocesseur. 7
Dans un mode particulier de réalisation, ce moyen de stockage est partiellement ou totalement amovible. Toujours dans le même but, la présente invention propose également un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, comportant des séquences d'instructions pour mettre en oeuvre un procédé tel que succinctement décrit ci-dessus, lorsque ce produit programme d'ordinateur est chargé dans et exécuté par l'appareil programmable. Les avantages du dispositif de traitement de données, ainsi que les caractéristiques particulières et avantages du système de télécommunications, du moyen de stockage d'informations et du produit programme d'ordinateur étant similaires à ceux du procédé de traitement de données, ils ne sont 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 d'un mode particulier de réalisation et de variantes, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 représente schématiquement le contexte de la présente invention ; - la figure 2 représente schématiquement un mode particulier de réalisation d'un appareil susceptible de mettre en oeuvre la présente invention ; - la figure 3 est un organigramme représentant un mode particulier de réalisation d'une partie d'un procédé de traitement de données conforme à l'invention ; - la figure 4 est un organigramme représentant un mode particulier de réalisation d'une seconde partie d'un procédé de traitement de données conforme à l'invention ; et - la figure 5 illustre des portions des flux de données codées susceptibles d'être traités conformément à l'invention. A titre d'exemple nullement limitatif, on décrit ici le traitement d'un flux de données consistant en des données vidéo. 8
Ces données sont codées par exemple en utilisant la norme MPEG-4, en particulier la partie 2 de MPEG-4. Bien entendu, d'autres normes peuvent être employées, comme par exemple H.263 ou MPEG-2. La norme correspondant au format de codage vidéo MPEG-4 partie 5 2 est ISO 14496-2. L'encapsulation du flux de données vidéo codées dans des paquets réseau selon cette norme est décrite dans la RFC (de l'anglais "Request for comments") 3016. Chaque image codée à transmettre à travers le réseau de 10 communication est généralement divisée en paquets de données codées. Comme indiqué plus haut, cette image s'appelle VOP en langage MPEG-4. On décrit tout d'abord, en référence à la figure 1, le contexte dans lequel se situe l'invention. Le contexte général de l'invention est la transmission d'un flux de 15 données codées à travers un réseau de communication entre un émetteur et au moins un destinataire. Comme le montre la partie supérieure de la figure 1, des données 100 à transmettre à travers le réseau de communication sont codées par un codeur 101 afin de former un flux de données codées 102. 20 Dans le mode particulier de réalisation décrit ici, ce flux de données codées 102 est un train binaire codé. A titre d'exemple non limitatif, ce train binaire codé 102 peut représenter des données multimédia, c'est-à-dire des données vidéo ou audio. En général, le train binaire est organisé en un ensemble de paquets de 25 données codées. Chaque paquet de données codées comporte deux parties, un en-tête et un corps (en anglais "body"), comme expliqué ci-dessous en référence à la figure 5. Un encapsuleur 103 forme des paquets réseau 104 à partir du train binaire 102, par exemple en fonction des règles contenues dans une RFC. 30 Le processus d'encapsulation est détaillé pour certains types de flux au sein des RFCs. Par exemple, comme cité ci-dessus, la RFC 3016 décrit le processus d'encapsulation pour la norme MPEG-4 partie 2. 9
Dans chaque paquet réseau, on distingue notamment deux parties. Une première partie correspond à des données représentant le début d'un paquet ou un en-tête réseau, par exemple un en-tête RTP (de l'anglais "Realtime Transport Protocof'). Une seconde partie correspond aux données utiles (ou charge utile) du paquet réseau, comportant les données du flux de données codées. Ces données utiles contiennent au moins une partie d'un paquet de données codées. Si la taille du paquet de données codées ne dépasse pas la taille maximale acceptable pour la partie correspondant aux données utiles d'un paquet réseau, il est possible qu'un paquet réseau contienne, dans la partie correspondant aux données utiles, exactement un paquet de données codées. L'en-tête réseau comporte des informations concernant par exemple le numéro du paquet réseau indiquant l'indice du paquet réseau dans l'ordre d'émission, un marqueur indiquant qu'un paquet est le dernier composant d'une image, etc.
Dans la présente description, "encapsuler" consiste à former des paquets réseau 104 à partir d'un flux de données codées 102. Inversement, "désencapsuler" consiste à former une suite de données prête au décodage 153 à partir des paquets réseau 151 (cf. désencapsuleur 152, mentionné plus loin).
Les paquets de données codées 102 sont encapsulés dans des paquets réseau 104 qui sont émis par un serveur 105 sur un réseau de communication. De cette manière, si un paquet réseau est perdu ou corrompu, les autres paquets réseau contenant des données utiles composant une même image ou VOP restent décodables, dès lors que chaque paquet de données codées est codé et encapsulé de manière indépendante par rapport aux autres paquets de données codées. Dans le mode particulier de réalisation décrit ici, le réseau de communication est un réseau de communication à commutation de paquets. Le protocole utilisé pour le transport des données dans ce type de réseau est par exemple le protocole RTP. Ce type de protocole, en soi bien connu de l'homme du métier, est souvent utilisé dans la diffusion de données multimédia. 10
Comme le montre la partie inférieure de la figure 1, un client 150 récupère les paquets réseau 151 du réseau de communication et identifie les paquets réseau 104 appartenant à une même image ou VOP. Le client 150 lit alors les paquets réseau 151.
Eventuellement, le client 150 ordonne les paquets réseau 151 lorsque l'ordre de réception n'a pas été le même que celui utilisé pour l'émission (par exemple dans le cas où les paquets réseau 151 ont suivi des routes différentes lors de leur transmission dans le réseau de communication). Les paquets de données codées sont désencapsulés par un module désencapsuleur 152 afin de former une suite de données 153, ici un train binaire, à partir de la charge utile des paquets réseau 151. Cette suite de données 153 devrait être identique au flux de données 102 encapsulé dans des paquets réseau 104 et puis émis par le serveur 105. Néanmoins, il est possible que ces deux flux ne soient pas identiques, en raison d'erreurs survenues pendant la transmission à travers le réseau de communication. En plus du train binaire 153, le désencapsuleur 152 forme une suite de données additionnelles 154 qui est acheminée vers le décodeur 155. La formation de cette suite de données additionnelles 154 ainsi que son utilisation par le décodeur 155 sera décrite ci-dessous. Un décodeur 155 décode la suite de données codées 153 formée par le désencapsuleur 152, et produit ainsi des données décodées 156. La figure 2 illustre un dispositif mettant en oeuvre l'invention, dans un mode particulier de réalisation.
Ce dispositif est par exemple un lecteur portable multimédia 210. Le dispositif 210 comporte une interface de communication 212 reliée à un réseau 213 apte à recevoir des données numériques à traiter par le dispositif dans le cadre de la mise en oeuvre de l'invention. Il comporte aussi un lecteur 209 de stockage de masse 205. Ce stockage de masse 205 peut être une carte mémoire ou un périphérique USB, par exemple. Il peut ainsi contenir des données traitées selon l'invention ainsi que, dans une première variante, le ou les programmes mettant en oeuvre l'invention. Selon une seconde variante, 11
le ou les programmes permettant au dispositif de mettre en oeuvre l'invention pourront être stockés en mémoire morte 207 (appelée ROM sur le dessin). En troisième variante, le ou les programmes pourront être reçus pour être stockés de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication 213. Ce même dispositif possède un écran 204 permettant de visualiser les données traitées ou de servir d'interface avec l'utilisateur qui peut ainsi sélectionner d'autres données à traiter, à l'aide du clavier 214 ou de tout autre moyen (souris, molette ou stylet par exemple).
L'unité centrale 200 (appelée CPU sur le dessin) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 207 ou dans les autres éléments de stockage. Par exemple, l'unité centrale réalise les étapes illustrées en figure 3 et décrites plus loin. Lors de la mise sous tension, les programmes de traitement stockés dans une mémoire non volatile, par exemple la ROM 207, sont transférés dans la mémoire vive RAM 203 qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement totalement ou partiellement amovible, mémorise un programme mettant en oeuvre le procédé de traitement de données selon l'invention. Le bus de communication 201 permet la communication entre les différents éléments inclus dans le dispositif 210 ou reliés à lui. La représentation du bus 201 n'est pas limitative et notamment l'unité centrale 200 est susceptible de communiquer des instructions à tout élément du dispositif 210 directement ou par l'intermédiaire d'un autre élément du dispositif 210. Le dispositif 210 comporte en outre un codec 208, par exemple sous la forme d'une puce standard, utilisée par l'unité centrale 200 de manière 30 classique à travers le bus 201. La figure 5 représente une portion de la suite de données codées prête au décodage 153 formée par le désencapsuleur 152. 12
Cette portion de la suite de données codées 153 comporte la charge utile de plusieurs paquets réseau 151 correspondant à quatre paquets de données codées 501 appartenant à une image ou VOP. Ainsi, dans cet exemple nullement limitatif, les paquets de données 5 codées sont des paquets de données vidéo. Chaque paquet de données vidéo 501 comporte un en-tête de paquet de données vidéo 502, appelé marqueur de synchronisation dans le cas de la partie 2 de MPEG4, suivi des données 503 du flux de données qui, dans l'exemple non limitatif décrit ici, est un flux vidéo. 10 Un en-tête de paquet de données vidéo représente un code signifiant le début du décodage du paquet de données vidéo indépendamment des autres paquets de données vidéo. Il comprend des informations se référant aux données du paquet de données vidéo, par exemple le numéro d'indice du premier macrobloc codé 15 appartenant à une image. On notera qu'un paquet de données vidéo peut être entièrement contenu dans un paquet réseau, ou réparti sur plusieurs paquets réseau. On reviendra à cette figure une fois qu'un mode de réalisation d'un procédé conforme à l'invention sera décrit. 20 La figure 3 est un organigramme illustrant une partie d'un mode particulier de réalisation du procédé de traitement de données conforme à l'invention. Lorsque le désencapsuleur 152 reçoit les paquets réseau 151 correspondant à une image, il initialise la suite de données codées 153 dans 25 laquelle la charge utile de ces paquets réseau va être insérée après désencapsulation, lors d'une étape d'initialisation 300. L'étape d'initialisation consiste par exemple en l'allocation d'une mémoire tampon de taille suffisante (par exemple supérieure à la somme des tailles des charges utiles des paquets réseau 151 correspondant à une image), 30 où va être placé le train binaire. En fonction de l'architecture du dispositif mettant en oeuvre l'invention, la mémoire utilisée peut être par exemple une 13
zone d'une mémoire vive RAM, une mémoire tampon sur le bus de communication, ou une mémoire tampon au sein du décodeur. Ici, la suite de données codées 153 prête à être fournie en entrée au décodeur 155 est un train binaire organisé en octets, c'est-à-dire que la plus petite unité d'information correspond à un octet. Lors d'une première étape de sélection 301, le désencapsuleur sélectionne un premier paquet réseau 151. Une première étape de vérification 302 est mise en oeuvre afin de vérifier s'il y a eu une erreur dans le réseau lors de la transmission du paquet réseau sélectionné. Comme décrit ci-dessus, cette erreur peut être la perte d'un paquet réseau précédent 151, ainsi qu'une erreur dans le paquet réseau 151, comme par exemple un ou plusieurs bits erronés ou la perte d'un ou plusieurs bits. Cette erreur est détectée, par exemple, via l'application d'une somme de contrôle (telle qu'un code CRC (de l'anglais "Cyclic Redundancy Check")). Le paquet réseau contenant des bits erronés est marqué comme tel. La perte d'un paquet réseau 151 est détectable via l'en-tête réseau du paquet réseau 151. L'en-tête réseau peut par exemple comporter un numéro de séquence représentant l'indice du paquet réseau 151 lors de son émission.
S'il manque un numéro dans la séquence, cela indique la perte d'un paquet réseau 151. Un paquet réseau 151 contenant une erreur peut être marqué comme erroné par des couches du réseau inférieures à la couche applicative (couche de fonctionnement du désencapsuleur et du décodeur).
S'il n'y a pas eu d'erreurs lors de la transmission du paquet réseau précédent, la charge utile du paquet réseau 151 sélectionné est concaténée au train binaire codé 153 lors d'une étape première de concaténation 306. Ensuite, on effectue une seconde étape de vérification 307 consistant à vérifier si le paquet réseau était le dernier paquet réseau de la séquence reçue par le client 150. 14
S'il ne s'agit pas du dernier paquet réseau 151, le désencapsuleur met en oeuvre une seconde étape de sélection 308, au cours de laquelle un paquet suivant est sélectionné. Après la mise en oeuvre de cette seconde étape de sélection 308, on retourne à la première étape de vérification 302, afin de vérifier s'il y a eu une erreur dans le réseau lors de la transmission de ce nouveau paquet réseau 151 sélectionné. Lorsqu'à la première étape de vérification 302, on constate qu'il y a eu une erreur, une deuxième étape de concaténation est mise en oeuvre.
Cette deuxième étape de concaténation 303 consiste à concaténer la partie correcte de la charge utile (c'est-à-dire des données situées devant les données manquantes ou erronées) au train binaire codé 153. Ensuite, une étape de signalisation 304 est mise en oeuvre. Selon un mode de réalisation, l'étape de signalisation 304 consiste à noter une information représentative de la position à laquelle se situe l'erreur dans une suite de données additionnelles 154. Cette suite de données additionnelles 154 sera transmise au décodeur en même temps que la suite de données prête au décodage ou train binaire codé 153. Cette information représentative de la position comporte la position 20 de la donnée située devant les données manquantes ou erronées dans la partie de la suite de donnée prête au décodage 153. En pratique, l'information représentative de la position comporte la longueur du train binaire codé 153 qui a été désencapsulé jusqu'à présent. La longueur du train binaire codé 153, c'est-à-dire le nombre de bits 25 contenus dans le train binaire 153, est connue par le désencapsuleur 152. Différentes méthodes pour noter la position des données erronées ou manquantes peuvent être employées. Par exemple, une autre méthode consisterait à noter une longueur relative à l'erreur précédente, c'est-à-dire que l'on noterait la différence entre la 30 position de l'erreur présente et la position de l'erreur précédente. Bien entendu, d'autres méthodes pour noter les positions des données erronées ou manquantes pourraient être employées. 15
Afin d'illustrer l'étape de signalisation 304, on revient à la figure 5. La figure 5 montre une portion de train binaire codé 153 et une portion de suite des données additionnelles 154, produites par le désencapsuleur 152.
Le train binaire codé 153 comporte un premier paquet 501a, un deuxième paquet 501b et un troisième paquet 501c qui ne comportent pas de données manquantes ou erronées. Le train binaire codé 153 comporte également un cinquième paquet 501d comportant des données erronées.
Le quatrième paquet est manquant. On notera que le deuxième paquet 501b ne comporte pas d'en-tête de paquet 502. Cela veut dire que l'encapsuleur 103 a divisé un paquet de données codées en deux paquets réseau 104 différents en raison du fait que la taille des données codées dépasse la taille acceptable pour la partie correspondant aux données utiles d'un paquet réseau 104. Ainsi, le premier paquet 501a présente la taille maximale acceptable pour la partie correspondant aux données utiles d'un paquet réseau 104. Les longueurs des premier 501a, deuxième 501b, troisième 501c et cinquième 501d paquets sont représentées sur un axe et sont nommées respectivement L1, L2, L3 et L5. L4 représente la position à partir de laquelle commencent des données erronées dans le cinquième paquet 501d. Lorsque le décapsuleur 152 forme ce train binaire 153 et qu'il se rend compte que le quatrième paquet est manquant, la longueur du train binaire codée L3 (correspondant à la fin du troisième paquet 501c) est notée dans la suite de données additionnelles 154. De même, lors de la désencapsulation du cinquième paquet 501d, la longueur du train binaire L4 correspondant à la position de la dernière donnée du train binaire avant la position des données erronées est notée dans la suite de données additionnelles 154.
On revient à la figure 3 afin de décrire la suite du procédé de traitement conforme à l'invention. 16
Dans ce mode de réalisation, on a vu qu'une l'étape de signalisation 304 et une deuxième étape de concaténation 303 sont mises en oeuvre. Cette deuxième étape de concaténation 303 consiste, comme décrit ci-dessus, à extraire la partie de la charge utile située entre le début de la charge utile du paquet réseau 151 et la position des données manquantes ou erronées, et à concaténer cette charge utile au train binaire codé 153. Bien entendu, si les données manquantes ou erronées sont situées au début de la charge utile du paquet réseau 151, il n'existe pas de données correctes situées devant les données manquantes ou erronées à concaténer au train binaire 153. De manière similaire, si l'erreur correspond à un paquet réseau manquant, il n'existe pas d'étape de concaténation 303. Une troisième étape de concaténation 305 est ensuite mise en oeuvre. Elle consiste à rajouter une suite de données de remplissage à la suite 15 des données prête au décodage 153. Cette suite de données de remplissage est insérée à partir du début des données manquantes ou erronées. La raison pour laquelle on insère une suite de données de remplissage est que ces données permettent d'empêcher le décodeur de 20 décoder de manière erronée des données valides qui suivent des données erronées. Par exemple, un décodeur qui décode une suite de données correspondant à un macrobloc entier avant de vérifier si des erreurs sont présentes dans les données de ce macrobloc, ne reconnaît pas la présence 25 d'une erreur pendant le décodage de ce macrobloc. Dans ce cas, après une erreur, le décodeur continue à décoder les données qui la suivent et par conséquent, ces données valides seront mal décodées. La présence des données de remplissage à partir de la position du 30 début des données erronées permet d'éviter de décoder de façon erronée des données valides et de les valider comme s'il s'agissait de données décodées correctement. 17
La longueur de la suite de données de remplissage est telle que la suite de données prête au décodage présente une longueur prédéterminée. Cette longueur prédéterminée correspond à la longueur de lecture du décodeur, dans cet exemple, la longueur d'un macrobloc.
A titre d'exemple nullement limitatif, dans le cas de MPEG4 Partie 2, la longueur de la suite de données additionnelles peut être de 700 octets. Ainsi, après la position des données erronées, et jusqu'à la fin du macrobloc, les données prêtes au décodage 153 correspondent à la suite de données de remplissage, et des données valides de la suite de données prête au décodage 153 ne sont pas décodées de manière erronée. Ensuite, la première étape de concaténation 306 est mise en oeuvre. Ensuite, la seconde étape de vérification 307 est mise en oeuvre afin de déterminer si le paquet réseau 151 traité est le dernier paquet réseau 151 de la séquence.
Comme décrit ci-dessus, lorsque le paquet réseau 151 n'est pas le dernier, on procède à la seconde étape de sélection 308. Lorsque le paquet réseau 151 est le dernier de la séquence, on effectue une étape de transfert 309, consistant à transmettre au décodeur 155 la suite de données prête au décodage 153 ainsi que la suite de données additionnelles 154 formée par le désencapsuleur 152. La figure 4 montre la partie de procédé de traitement conforme à l'invention concernant le décodage de la suite de données prête au décodage 153. Dans cet exemple, le décodeur 155 sélectionne et décode macrobloc 25 par macrobloc. Un macrobloc est une zone de l'image vidéo. La taille du macrobloc est variable, par exemple en fonction du codage utilisé. A titre d'exemple nullement limitatif, la taille d'un macrobloc peut être 1, 50, 300 ou 700 octets. Le nombre de macroblocs contenus dans un paquet de données 30 codées est variable. 18
Lorsque le décodeur 155 reçoit le train binaire codé 153 du désencapsuleur correspondant à une image, il initialise le décodeur 155 lors d'une étape d'initialisation 400. D'une manière similaire à ce qui a été décrit plus haut pour le désencapsuleur, l'étape d'initialisation du décodeur consiste par exemple en l'allocation d'une mémoire tampon de taille suffisante (par exemple supérieure à la somme des tailles des charges utiles des paquets réseau 151 correspondant à une image), où va être placé le train binaire 153. En fonction de l'architecture du dispositif mettant en oeuvre l'invention, la mémoire utilisée peut être par exemple une zone d'une mémoire vive RAM, une mémoire tampon sur le bus de communication, ou une mémoire tampon au sein du décodeur. Ici, la suite de données codées 153 prête à être fournie en entrée au décodeur 155 est un train binaire organisé en octets, c'est-à-dire que la plus petite unité d'information correspond à un octet.
Lors d'une étape de réception des positions d'erreur 401, le décodeur 155 reçoit la suite des données additionnelles 154 contenant les positions d'erreur de la suite de données prête au décodage 153. Dans cet exemple, la suite de données additionnelles 154 est ajoutée à la suite de données prêtes au décodage 153, les deux suites de données 153, 154 formant ainsi un flux de données reçu par le décodeur 155. Une fois que la suite de données prête au décodage 153 et la suite de données additionnelles 154 sont prêtes, une étape de sélection 402 est mise en oeuvre. Dans ce mode de réalisation, l'étape de sélection 402 consiste à sélectionner le premier macrobloc à décoder de la suite de données prête au décodage ou train binaire codé 153, et la première position d'erreur de la suite de données additionnelles 154. Ensuite, le macrobloc est décodé lors d'une étape de décodage 403. Une fois que le macrobloc a été décodé, la position dans le train binaire codé 153 à laquelle l'on se trouve, c'est-à-dire la position de la dernière donnée du macrobloc décodé, est comparée à la position d'erreur lors d'une étape de comparaison 404. 19
Si la position d'erreur est supérieure à la position à laquelle on se trouve dans le train binaire codé 153, cela veut dire que le macrobloc qui vient d'être décodé ne comporte pas de données erronées ou manquantes. Dans ce cas, une troisième étape de vérification 408 est mise en oeuvre, afin de vérifier si le macrobloc décodé est le dernier macrobloc du train binaire codé 153. Si la réponse est négative, lors d'une seconde étape de sélection 409, le macrobloc suivant est sélectionné et ensuite décodé lors de l'étape de décodage 403.
Si la réponse est affirmative à la troisième étape de vérification 408, on procède à une étape de finalisation du décodage 410. Lorsqu'à l'étape de comparaison 404, la position d'erreur est inférieure à la position à laquelle on se trouve dans le train binaire codé 153, cela veut dire que le macrobloc décodé contient des données manquantes ou erronées. Lorsque le décodeur se rend compte que le macrobloc décodé contient des erreurs, le décodeur 155 qui était désynchronisé à cause de la lecture des données erronées ou manquantes procède à une étape de resynchronisation 405 afin de rechercher la synchronisation.
En pratique, lors de l'étape de resynchronisation 405, le décodeur 155 est en mode de resynchronisation, c'est-à-dire que le décodeur 155 cherche un code sur lequel il peut se synchroniser et recommencer ainsi à lire et décoder des données. Un tel code est connu sous le nom de marqueur de synchronisation.
Un marqueur de synchronisation comporte des données représentant le début d'un paquet de données vidéo ou d'une suite de paquets de données vidéo, et peut être un en-tête de paquet de données vidéo ou un marqueur de début. Comme décrit ci-dessus, un en-tête de paquet de données vidéo indique le début d'un paquet de données vidéo et un marqueur de début indique le début d'une image ou VOP. 20
Un marqueur de synchronisation présente une longueur variable. Dans cet exemple nullement limitatif, le marqueur de synchronisation est constitué de 16 à 22 bits à 0 suivis d'un bit à 1. Une fois le marqueur de synchronisation trouvé, la position de l'erreur suivante est sélectionnée lors d'une troisième étape de sélection 406, et cette position d'erreur est comparée à la position à laquelle on se trouve dans le train binaire codé 153 (position à laquelle le marqueur de synchronisation a été trouvé) lors d'une quatrième étape de vérification 407. Si la position d'erreur est inférieure à la position à laquelle on se trouve dans le train binaire codé 153, on procède à nouveau à l'étape de sélection 406 afin de sélectionner l'erreur suivante. L'étape de sélection de l'erreur suivante 406 et la quatrième étape de vérification 407 sont mises en oeuvre jusqu'à ce que la position de l'erreur suivante soit supérieure à la position à laquelle on se trouve dans le train binaire codé 153. Il est possible qu'à l'étape de resynchronisation 405, le décodeur se soit resynchronisé de manière erronée, à la rencontre d'une erreur émulant un marqueur de synchronisation. Afin d'éviter cela, une cinquième étape de vérification 408 est mise 20 en oeuvre. Cette cinquième étape de vérification 408 consiste à comparer la position à laquelle on se trouve dans le train binaire codé 153 (ou position à laquelle le décodeur a trouvé le marqueur de synchronisation) à la position d'erreur actuelle. 25 Si ces deux positions sont les mêmes, cela veut dire que le décodeur s'est resynchronisé de manière erronée et on doit retourner à l'étape de resynchronisation 405 afin de chercher à nouveau un marqueur de synchronisation. Si, au contraire, ces deux positions sont différentes, cela veut dire 30 que le marqueur de synchronisation trouvé par le décodeur est véritablement un marqueur de synchronisation. 21
L'étape de resynchronisation 405, la troisième étape de sélection ou étape de sélection de l'erreur suivante 406, la quatrième de vérification 407 et la cinquième étape de vérification 408 sont mises en oeuvre jusqu'à ce que, à la cinquième étape de vérification 408, la position de l'erreur suivante soit supérieure à la position à laquelle on se trouve dans le train binaire codé 153. Lorsque l'on est dans cette situation à la cinquième étape de vérification 408, on procède à l'étape de décodage 403 afin de décoder le macrobloc suivant. Dans le mode de réalisation décrit, l'étape de concaténation des 10 données de remplissage 305 permet au décodeur 155 de lire des données de remplissage au lieu de lire des données valides à décoder. Dans un autre mode de réalisation, dans lequel l'étape de concaténation de données de remplissage 305 n'est pas mise en oeuvre, le décodeur est apte à revenir en arrière sur le train binaire codé 153.
15 Ainsi, le décodeur, lorsqu'il reconnaît qu'il existe une erreur dans le macrobloc décodé, revient à la dernière position correcte connue (c'est-à-dire le début du macrobloc décodé) et cherche un marqueur de synchronisation à l'étape de resynchronisation 405 à partir de cette position correcte. Ainsi, dans les deux cas, des données valides du train binaire codé 20 153 ne sont pas décodées de manière erronée et validées comme s'il s'agissait de données décodées correctement. Bien entendu, le procédé conforme à l'invention peut être utilisé pour le traitement de flux de données de types autres que multimédia. Par ailleurs, le procédé s'applique également à des données codées 25 selon des normes différentes, comme par exemple MPEG-2 ou H.263, ces deux exemples n'étant aucunement limitatifs.

Claims (13)

  1. REVENDICATIONS1. Procédé de traitement d'un flux de données codées avant décodage, comportant une étape de détection de données manquantes ou erronées dans ledit flux de données codées, caractérisé en ce qu'il comporte une étape de génération (303, 304, 306) d'une suite de données prête au décodage (153) formée à partir dudit flux de données codées, et d'une suite de données additionnelles (154) fournissant une information représentative de la position des données manquantes ou erronées détectées.
  2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de concaténation (305), à ladite suite de données prête au décodage (153), d'une suite de données de remplissage de façon à obtenir une suite de données de longueur prédéterminée.
  3. 3. Procédé selon la revendication 2, caractérisé en ce qu'il 15 comporte : - une étape de décodage (403) d'une partie de ladite suite de données prête au décodage (153) ayant ladite longueur prédéterminée ; - une étape de comparaison (404) de la position de la dernière donnée décodée de ladite partie de ladite suite de données prête au décodage 20 (153), à une position des données erronées ou manquantes dans la suite de données additionnelles (154).
  4. 4. Procédé selon la revendication 3, caractérisé en ce que les données de la suite de données prêtes au décodage (153), situées entre la position de la dernière donnée décodée et la position des données représentant 25 le début d'un paquet de données codées (501a, 501b, 501c, 501d) ne sont pas décodées, lorsqu'à l'étape de comparaison (404), la position de la dernière donnée décodée est supérieure à ladite position des données erronées ou manquantes.
  5. 5. Procédé selon la revendication 3 ou 4, caractérisé en ce qu'une 30 seconde partie de ladite suite de données prête au décodage est décodée lorsqu'à l'étape de comparaison (404), la position de la dernière donnée décodée est inférieure à la position des données erronées ou manquantes. 23
  6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite information représentative de la position comporte la position de la donnée située devant les données manquantes ou erronées dans la partie de la suite de données prête au décodage (153).
  7. 7. Dispositif de traitement d'un flux de données codées avant décodage, comportant des moyens de détection de données manquantes ou erronées dans ledit flux de données codées, caractérisé en ce qu'il comporte des moyens de génération d'une suite de données prête au décodage (153) formée à partir dudit flux de données codées, et d'une suite de données additionnelles (154) fournissant une information représentative de la position des données manquantes ou erronées détectées.
  8. 8. Dispositif selon la revendication 7, caractérisé en ce qu'il comporte en outre des moyens de concaténation, à ladite suite de données prête au décodage (153), d'une suite de données de remplissage de façon à obtenir une suite de données de longueur prédéterminée.
  9. 9. Dispositif selon la revendication 8, caractérisé en ce qu'il comporte : - des moyens de décodage d'une partie de ladite suite de données prête au décodage (153) ayant ladite longueur prédéterminée ; - des moyens de comparaison de la position de la dernière donnée décodée de ladite partie de ladite suite de données prête au décodage (153), à une position des données erronées ou manquantes dans la suite de données additionnelles (154).
  10. 10. Système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, caractérisé en ce qu'il comprend au moins un dispositif terminal équipé d'un dispositif selon l'une quelconque des revendications 7 à 9.
  11. 11. Moyen de stockage d'informations pouvant être lues par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il est adapté à mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 6, lorsque lesdites informations sont lues par ledit ordinateur ou ledit microprocesseur. 24
  12. 12. Moyen de stockage d'informations selon la revendication 11, caractérisé en ce qu'il est partiellement ou totalement amovible.
  13. 13. 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é selon l'une quelconque des revendications 1 à 6, lorsque ledit produit programme d'ordinateur est chargé dans et exécuté par ledit appareil programmable.
FR0852260A 2008-04-04 2008-04-04 Procede et dispositif de traitement d'un flux de donnees Expired - Fee Related FR2929787B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0852260A FR2929787B1 (fr) 2008-04-04 2008-04-04 Procede et dispositif de traitement d'un flux de donnees
US12/417,359 US8650469B2 (en) 2008-04-04 2009-04-02 Method and device for processing a data stream

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0852260A FR2929787B1 (fr) 2008-04-04 2008-04-04 Procede et dispositif de traitement d'un flux de donnees

Publications (2)

Publication Number Publication Date
FR2929787A1 true FR2929787A1 (fr) 2009-10-09
FR2929787B1 FR2929787B1 (fr) 2010-12-17

Family

ID=40122384

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0852260A Expired - Fee Related FR2929787B1 (fr) 2008-04-04 2008-04-04 Procede et dispositif de traitement d'un flux de donnees

Country Status (2)

Country Link
US (1) US8650469B2 (fr)
FR (1) FR2929787B1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2915342A1 (fr) * 2007-04-20 2008-10-24 Canon Kk Procede et dispositif de codage video
FR2920632A1 (fr) * 2007-08-31 2009-03-06 Canon Kk Procede et dispositif de decodage de sequences video avec masquage d'erreurs
US8897364B2 (en) * 2007-08-31 2014-11-25 Canon Kabushiki Kaisha Method and device for sequence decoding with error concealment
US8079054B1 (en) * 2008-04-14 2011-12-13 Adobe Systems Incorporated Location for secondary content based on data differential
EP2299716B1 (fr) 2009-09-09 2016-11-23 Canon Kabushiki Kaisha Procédé et dispositif pour le codage d'un signal numérique multidimensionnel
GB2505912B (en) * 2012-09-14 2015-10-07 Canon Kk Method and device for generating a description file, and corresponding streaming method
US9645878B2 (en) * 2014-07-09 2017-05-09 Qualcomm Incorporated Error handling for files exchanged over a network
EP3499885B1 (fr) 2017-12-18 2024-07-17 Canon Kabushiki Kaisha Procédé et dispositif de codage de données vidéo
EP3499886A1 (fr) 2017-12-18 2019-06-19 Canon Kabushiki Kaisha Procédé et dispositif de codage de données vidéo

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007084167A1 (fr) * 2006-01-17 2007-07-26 Truespan, Inc. Procédés de résilience d'erreur pour les implémentations de correction d'erreurs sans circuit de retour d'encapsulation multi-protocoles

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6571361B1 (en) * 1995-09-29 2003-05-27 Kabushiki Kaisha Toshiba Encoder and decoder
US5778191A (en) 1995-10-26 1998-07-07 Motorola, Inc. Method and device for error control of a macroblock-based video compression technique
FR2812502B1 (fr) 2000-07-25 2002-12-20 Canon Kk Insertion et extraction de message dans des donnees numeriques
FR2816153B1 (fr) 2000-10-27 2002-12-20 Canon Kk Procede de controle prealable de la detectabilite d'un signal de marquage
US7610543B2 (en) * 2002-06-18 2009-10-27 Nokia Corporation Method and apparatus for puncturing with unequal error protection in a wireless communication system
WO2004030266A1 (fr) * 2002-09-24 2004-04-08 Telefonaktiebolaget Lm Ericsson (Publ) Procede et dispositifs de transmission de donnees a tolerance d'erreurs au cours de laquelle la retransmission de donnees erronees est effectuee jusqu'au point ou le nombre restant d'erreurs est acceptable
FR2875042B1 (fr) 2004-09-03 2006-11-24 Canon Kk Procede et dispositif d'acces aleatoire a une zone d'une image codee en vue de la decoder et procede et dispositif de codage d'une image
US7936938B2 (en) 2004-09-07 2011-05-03 Canon Kabushiki Kaisha Methods and devices for encoding a digital image signal and associated decoding methods and devices
US7861131B1 (en) * 2005-09-01 2010-12-28 Marvell International Ltd. Tensor product codes containing an iterative code
FR2897741B1 (fr) 2006-02-17 2008-11-07 Canon Kk Procede et dispositif de generation de donnees representatives d'un degre d'importance de blocs de donnees et procede et dispositif de transmission d'une sequence video encodee
FR2898757A1 (fr) 2006-03-14 2007-09-21 Canon Kk Procede et dispositif d'adaptation d'une frequence temporelle d'une sequence d'images video
FR2908585B1 (fr) 2006-11-15 2008-12-26 Canon Kk Procede et dispositif de transmission de donnees video.
FR2910211A1 (fr) 2006-12-19 2008-06-20 Canon Kk Procedes et dispositifs pour re-synchroniser un flux video endommage.
FR2919779B1 (fr) 2007-08-02 2010-02-26 Canon Kk Procede et dispositif de codage avec perte d'un signal numerique

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007084167A1 (fr) * 2006-01-17 2007-07-26 Truespan, Inc. Procédés de résilience d'erreur pour les implémentations de correction d'erreurs sans circuit de retour d'encapsulation multi-protocoles

Also Published As

Publication number Publication date
FR2929787B1 (fr) 2010-12-17
US8650469B2 (en) 2014-02-11
US20090254798A1 (en) 2009-10-08

Similar Documents

Publication Publication Date Title
FR2929787A1 (fr) Procede et dispositif de traitement d'un flux de donnees
EP1997254B1 (fr) Procede de protection de donnees multimedia au moyen de couches d'abstraction reseau (nal) supplementaires
FR2927216A1 (fr) Methode de transmission d'images numeriques et de reception de paquets de transport.
EP1726162A1 (fr) Procede et systeme hautement securises pour la distribution de flux audiovisuels
EP1483915B1 (fr) Procede de transmission de flux de donnees dependants
EP2735167B1 (fr) Système de diffusion de programmes vidéos
FR2944938A1 (fr) Procede et dispositif de correction d'erreurs.
FR2866183A1 (fr) Procedes d'emission et de reception d'une animation, et dispositifs associes
EP1590959B1 (fr) Dispositif securise pour la diffusion, l ' enregistrement et la visualisation a la demande des oeuvres audiovisuelles au format de type mpeg-2 ts
FR2827447A1 (fr) Procede de transmission de flux de donnees, flux de donnees, serveur, terminal, procede de reception et utilisation correspondants
EP3317799B1 (fr) Procédé de fourniture d'un contenu multimédia protégé
FR2929786A1 (fr) Procede et dispositif de traitement d'un flux de donnees
FR2767618A1 (fr) Procedes et dispositifs d'emission et de reception de donnees et systemes les utilisant
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
WO2013144531A1 (fr) Procede de tatouage avec streaming adaptatif
EP1383336B1 (fr) Procédé de décompression et de restitution d'un flux de données multimédia numériques compressées comprenant une pluralité d'entités encodées. Dispositif, système et signal correspondants
FR2873532A1 (fr) Procede de codage et de decodage d'une sequence d'elements, signal, codeur, decodeur, programmes d'ordinateur et moyens de stockage correspondants
EP0982866A1 (fr) Procédé de codage convolutif et de transmission par paquets d'un flux série de données numériques, procédé et dispositif de décodage correspondants
EP2163020B1 (fr) Methode a base de codes correcteurs d'erreurs applicable a un flux de donnees multimedia a debit variable
FR3069996A1 (fr) Procede de lecture d'un flux multimedia chiffre avec acces rapide au contenu en clair et dispositif d'utilisation
EP1455537A1 (fr) Protection de données avec en-tête contre les erreurs dans un système de transmission
EP3170296B1 (fr) Procédé d'accès à un contenu multimédia protégé par un terminal
EP2326035B1 (fr) Procédé de traitement par un module de sécurité de messages de contrôle d'accès à un contenu et module de sécurité associé
EP1521475A1 (fr) Procédé et dispositif de traitement de flux de données codées
FR2964520A1 (fr) Procede de detection d'erreurs lors de la diffusion de contenu dans un reseau de communication

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20131231