Brevet FR2934445A1 — publié le 20100129

CORRECTION EN RECEPTION D'UN CONTENU VIDEO TRANSMIS VIA UN RESEAU La présente invention concerne la correction d'erreur de transmission d'un flux de paquets de données correspondant à un contenu vidéo, sur un réseau de type IP (pour 'Internet Protocol' en anglais). On entend par les termes "contenu vidéo", un contenu audiovisuel adapté pour être transmis ou diffusé via un réseau IP. La diffusion d'un tel contenu audiovisuel peut correspondre par exemple à un service de type IPTV (pour 'Internet Protocol Télévision'). Ainsi, par exemple, pour un service de ce type, il est prévu de diffuser des contenus audiovisuels selon une multi diffusion (ou `multicast' en anglais), les données numériques correspondantes étant envoyées vers plusieurs dispositifs simultanément. Un contenu vidéo est transmis sous la forme d'un flux de paquets de données IP dans le réseau de diffusion. Il convient de noter que la qualité, en réception, d'un contenu vidéo ainsi transmis est très sensible à la perte de paquets dans le réseau IP. Afin de garantir un certain niveau de qualité de la vidéo ainsi transmise, on peut soit prévoir de mettre en oeuvre un mécanisme de correction de type FEC (pour 'Forward Error Correction' en anglais), c'est-à-dire `correction d'erreur sans voie de retour', soit encore prévoir de retransmettre les paquets qui n'ont pas été reçus au niveau du récepteur du contenu vidéo. Un tel récepteur peut correspondre à un boitier décodeur, ou STB (pour `Set Top Box' en anglais). Les mécanismes de correction sans voie de retour sont basés sur le fait que le contenu vidéo est transmis sous la forme d'un flux de paquets de données comprenant à la fois des paquets de données relatives au contenu vidéo et des paquets de données supplémentaires correspondant à de l'information redondante de correction. Cette dernière peut être transmise dans le flux de paquets de données correspondant au contenu vidéo concerné de manière à permettre de reconstituer le flux de paquets de données initial même si certains paquets de données ont été perdus au cours de la transmission ou dans un flux de paquets de données distinct. Le Forum ProMPEG (pour `Pro Moving Picture Experts Group' en anglais) a ainsi défini une norme de mise en place d'un tel mécanisme de correction d'erreur sans voie de retour, référencée FEC COP #3. Une telle norme de mise en place de correction de type FEC est adaptée pour protéger la transmission d'un flux de paquets de données correspondant à un contenu vidéo contre des pertes de paquets de données. Le flux de paquets de données transmis, correspondant au contenu vidéo, comprend ici, outre les paquets de données relatifs au contenu vidéo, des paquets de type FEC, tel que FEC COP#3 par exemple, qui transportent l'information redondante de correction requise pour la mise en oeuvre d'une correction d'erreur sans voie de retour au niveau de la réception du flux. Ainsi, grâce à ces paquets FEC, tel que par exemple FEC COP#3 supplémentaires, le récepteur est en mesure de régénérer certains paquets de données qui ont été perdus lors de la transmission du contenu vidéo sur le réseau IP. Une telle méthode consiste, au niveau de l'émetteur, à créer une matrice de correction d'erreurs de transmission. Les paquets de données correspondant au contenu vidéo sont rangés dans la matrice de correction au fur et à mesure de leur génération Une fois la matrice de correction complétée, des paquets de données supplémentaires correspondant à de l'information redondante de correction sont générés à partir de groupes de paquets de données correspondant au contenu vidéo. De tels groupes correspondent, par exemple, à des paquets de données correspondant au contenu vidéo constituant des lignes ou des colonnes de la matrice de correction. De tels paquets de données supplémentaires correspondant à de l'information redondante de correction comportent également des informations permettant de reconstituer la matrice de correction au niveau du récepteur. A réception des paquets de données correspondant au contenu vidéo et des paquets de données supplémentaires correspondant à de l'information redondante de correction, le récepteur reconstitue la matrice de correction. La perte d'un paquet de données correspondant au contenu vidéo se traduit dans la matrice de correction reconstituée par un emplacement vide là où devrait se trouver le paquet de donnés correspondant au contenu vidéo perdu. Le paquet de données correspondant au contenu vidéo perdu est reconstruit à l'aide d'un ou plusieurs paquets de données supplémentaires correspondant à de l'information redondante de correction correspondants à la ligne et/ou la colonne de la matrice de correction d'origine à laquelle appartient le paquet de données multimédia perdu. Ce type de correction d'erreur est efficace pour la correction de pertes de paquets de données consécutives ou de pertes de paquets de données aléatoirement réparties. Toutefois, les performances de ce type de correction d'erreur diminuent rapidement lorsque la transmission du flux de paquets de données est entachée de pertes de paquets de données telles que la position des paquets de données perdus dans la matrice de correction rend inefficace l'application du FEC. Un autre mécanisme de correction d'erreur repose sur la retransmission des paquets de données perdus. Dans ce contexte, il est généralement prévu que sur détection de perte de paquets de données dans le flux de paquets de données reçu, le récepteur requiert la retransmission des paquets de données perdus auprès d'un serveur de retransmission de paquets de données. En procédant ainsi, il est possible de garantir un certain niveau de qualité de la vidéo transmise. Cependant, en cas de perte de paquets de données retransmis, un mécanisme consiste à requérir à nouveau la retransmission des paquets de données perdus. Ceci engendre une latence supplémentaire préjudiciable lorsque le service requit est un service temps réel. II convient de noter que les mécanismes de correction précédemment décrits consomment de la bande passante pour la transmission des paquets de données supplémentaires correspondant à de l'information redondante de correction et pour la retransmission des paquets de données perdus et en outre introduisent un délai dans le traitement en réception du flux de paquets de données puisqu'il convient alors d'attendre la réception des paquets de données supplémentaires correspondant à de l'information redondante de correction ou des paquets de données retransmis pour poursuivre le traitement en réception du flux. Pour limiter le nombre de serveurs de retransmission dans le réseau ou pour diminuer le nombre que requêtes en retransmission à traiter par ces serveurs,, il est prévu de mettre en oeuvre dans certaines architectures une correction d'erreur sans voie de retour avant de mettre en oeuvre une correction par retransmission de paquets de données perdus. En procédant ainsi, seuls les paquets de données perdus qui n'ont pas pu être générés à partir de l'information redondante des paquets FEC sont retransmis. Dans ces architectures, le récepteur reçoit à la fois le flux de paquets de données vidéo et le flux de paquets de données de type FEC. Ainsi, il est en mesure de corriger certaines pertes de paquets sur la base du mécanisme de correction de type FEC, comme les pertes unitaires de paquets de données. En outre, il met en oeuvre un mécanisme de requête de retransmission de paquets de données perdus, visant à corriger les pertes de paquets qui n'ont pas pu être corrigées par le mécanisme de correction d'erreur sans voie de retour de type FEC, comme par exemple le FEC COP #3. Toutefois, cette succession des deux types de corrections d'erreur n'est pas performante lorsque des paquets de données retransmis sont à nouveau perdus au 5 cours de leur retransmission. La présente invention vise à améliorer la situation. Un premier aspect de la présente invention propose un procédé de réception, au niveau de ladite entité de traitement, d'un contenu vidéo via un réseau de transmission par paquets, 10 ladite entité de traitement recevant ledit contenu vidéo selon un flux de paquets de données comprenant des premiers paquets de données relatives au contenu vidéo et des second paquets de données relatives à une correction d'erreur sans voie de retour ; ledit procédé de réception comprenant, au niveau de ladite entité de traitement, les 15 étapes suivantes : /1/ si des paquets de données sont manquants dans le flux de paquets de données, compléter ledit flux de paquets de données avec des paquets de données générés sur la base des seconds paquets de données et ; /2/ si des paquets de données sont manquants dans le flux de paquets de 20 données obtenu à l'étape /1/, compléter le flux de paquets de données avec des paquets de données retransmis via ledit réseau de transmission ; et /3/ si des paquets de données sont manquants dans le flux de paquets de données obtenu à l'étape /2/, compléter le flux de paquets de données avec des paquets de données générés sur la base des seconds paquets de données. 25 Grace à ces dispositions, on est en mesure de corriger simplement et efficacement une perte de paquets qui n'est pas corrigée par application d'un mécanisme de correction d'erreur sans voie de retour ni par un mécanisme de correction basé sur une retransmission de paquets. Avantageusement, ici, on est en mesure de limiter le délai de traitement en 30 réception qu'une correction par retransmission de paquets de données déjà retransmis mais perdus lors de la retransmission engendre. En effet, une correction d'erreur sans voie de retour est appliquée en premier lieu sur le flux de paquets de données reçu, ce qui limite à un premier niveau la quantité de paquets de données à retransmettre puisqu'il est ainsi possible de générer certains paquets de données 35 manquants sur la base de l'information redondante de correction transmise en association avec les paquets de données du contenu vidéo et, par la suite, une telle correction d'erreur sans voie de retour est également appliquée suite à la correction par retransmission de paquets, ce qui permet d'éviter à un second niveau la quantité de paquets de données retransmis, par rapport au cas où l'on appliquerait à nouveau ici une autre correction par retransmission de paquets de données. En procédant ainsi, on est en mesure d'augmenter la qualité de la transmission d'un contenu vidéo sans toutefois, ni augmenter de manière sensible le délai de traitement de réception, ni même augmenter la quantité de bande passante consommée dans ce but. En effet, le rajout d'une étape de correction d'erreur sans voie de retour n'introduit pas de délai supplémentaire et n'augmente pas la bande passante utilisée, comme cela pourrait être le cas dans le contexte d'une correction d'erreur par retransmission des paquets de données manquants. Il convient de noter qu'ici, la mise en oeuvre d'une correction d'erreur sans voie de retour est d'autant plus avantageuse après la correction d'erreur basée sur la retransmission de paquets de données que les seconds paquets de données, correspondant à l'information redondante de correction, ont déjà été reçus dans le flux de paquets de données initialement transmis. Ainsi, la consommation de la bande passante dans le réseau de transmission n'augmente pas pour cette étape de correction d'erreur sans voie de retour, ce qui ne serait pas le cas si on prévoyait de corriger des erreurs de transmission à cette étape, par retransmission des paquets de données manquant. En effet, ici, les paquets de données retransmis perdus ne sont pas à nouveau retransmis. L'étape de correction sans voie de retour qui suit l'étape de correction par retransmission permet d'augmenter la qualité de la vidéo reçue tout en étant effectuée rapidement et sur la base de seconds paquets de données mémorisés. Ces dispositions sont aisées à mettre en oeuvre dès lors que l'on prévoit de sauvegarder les seconds paquets de données reçus en vue de les réutiliser le cas échéant au niveau de l'étape /3/, lorsque des premiers paquets de données sont encore manquants. Un tel procédé de réception peut avantageusement être mis en oeuvre dans tous les contextes de transmission de contenu vidéo. On peut notamment citer, sans qu'aucune limitation ne soit attachée à cette liste, la transmission d'un contenu vidéo dans le cadre d'un service de vidéo à la demande, ou encore dans le contexte de la multidiffusion d'un contenu vidéo comme dans le cadre d'un service de type IP N. Dans un mode de réalisation de la présente invention, à l'étape /1/, les seconds paquets de données sont mémorisés au moins jusqu'à l'issue de l'étape /3/. Ainsi, on peut avantageusement se baser sur les seconds paquets de données déjà reçus pour mettre en oeuvre l'étape /3/ de correction. Les paquets de données retransmis peuvent être des premiers et/ou des seconds paquets de données. En effet, dans certains contextes de transmission, il peut être avantageux de retransmettre uniquement des premiers paquets de données, alors que dans d'autres contextes, il est préférable de ne retransmettre que des seconds paquets de données ou encore un mélange de ces deux types de paquets de données. En effet, dans certains cas, il peut être avantageux de requérir la retransmission de seconds paquets, notamment lorsque la retransmission de N seconds paquets de données permet de générer P premiers paquets de données, N et P étant des nombres entiers tels que N est inférieur à P. Lorsque des paquets de données retransmis sont des seconds paquets de données, l'étape /3/ peut en outre être réalisée sur la base des seconds paquets de données retransmis. Les seconds paquets de données peuvent être issus d'un encodage de type FEC COP#3. Avantageusement ce type d'encodage est adapté pour la transmission de contenu vidéo. Un deuxième aspect de la présente invention propose une entité de traitement 20 adaptée pour la mise en oeuvre d'un procédé de réception selon le premier aspect de la présente invention. Un troisième aspect de la présente invention propose un terminal de réception de contenu vidéo comprenant une entité de traitement selon le deuxième aspect de la présente invention. 25 Un tel terminal de réception peut correspondre notamment à un terminal mobile adapté pour communiquer dans un réseau de télécommunication mobile, une Set Top Box dans le cadre de I'IPTV, un PC, etc. Un quatrième aspect de la présente invention propose un boitier décodeur comprenant une entité de traitement selon le deuxième aspect de la présente 30 invention. Un tel boitier décodeur peut correspondre à une STB ou `Set Top Box' en anglais. Un cinquième aspect de la présente invention propose un système de réception comprenant un boitier décodeur selon le quatrième aspect de la présente invention et 35 un écran adapté pour afficher le contenu vidéo reçu. Un sixième aspect de la présente invention propose un programme d'ordinateur, destiné à être stocké dans une mémoire d'une entité de traitement selon le deuxième aspect de la présente invention, ou sur un support mémoire amovible et destiné à coopérer avec un lecteur de ladite entité de traitement, ledit programme d'ordinateur comprenant des instructions pour la mise en oeuvre de tout ou partie des étapes du procédé selon le premier aspect de la présente invention. Un septième aspect de la présente invention propose un support d'enregistrement sur lequel est stocké le programme d'ordinateur selon le quatrième aspect de la présente invention. D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : la figure 1 illustre les principales étapes d'un procédé de réception selon un mode de réalisation de la présente invention ; la figure 2 illustre une architecture de réseau de transmission adaptée pour diffuser un contenu vidéo via un réseau de transmission selon un mode de réalisation de la présente invention ; et la figure 3 illustre une entité de traitement selon un mode de réalisation de la présente invention. La figure 1 illustre les principales étapes d'un procédé selon un mode de réalisation de la présente invention. II est prévu de transmettre un contenu vidéo sous la forme d'un flux de paquets de données via un réseau de transmission par paquets. Ce flux de paquets de données peut correspondre à un contenu vidéo encodé selon un format de type MPEG. En outre, des paquets de données transportant l'information redondante de correction sont associés aux paquets de type MPEG afin de permettre la mise en oeuvre d'une correction d'erreur sans voie de retour. A cet effet, on peut prévoir de générer les paquets de données transportant l'information redondante de correction selon une méthode de correction d'erreur sans voie de retour telle que le FEC COP #3. Il est prévu ici d'appliquer, le cas échéant, sur le flux de paquets de données, successivement, une correction d'erreur sans voie de retour de type FEC, telle que le FEC COP #3 à une étape 11, suivie d'une correction d'erreur basée sur une retransmission de paquets perdus à une étape 12, elle-même, suivie ensuite d'une correction d'erreur sans voie de retour à une étape 13 effectuée sur la base des seconds paquets de données. Dans un mode de réalisation de la présente invention, la correction d'erreur appliquée à l'étape 12 repose sur la retransmission de premiers paquets de données manquants dans le flux de paquets de données reçus et qui n'ont pas pu être générés à partir des seconds paquets de données. Dans ce cas, à l'étape 13, on détermine s'ils manquent encore des paquets de données parmi les paquets de données retransmis qui ont été reçus. Si tel est le cas, on applique à nouveau une correction d'erreur de type FEC en utilisant les seconds paquets de données reçus dans le flux de paquets de données initial pour générer certains premiers paquets de données. On complète alors le flux de paquets de données avec les premiers paquets de données qui ont pu être générés à l'étape 13. Alternativement, il est possible de prévoir que, dans certains cas, lorsque cela apparait plus avantageux, la retransmission de paquets de données à l'étape 12 corresponde à une retransmission de seconds paquets de données. Tel peut être le cas, lorsque des seconds paquets de données sont perdus au cours de la transmission du flux de paquets de données. Dans ce cas, ces seconds paquets de données sont mémorisés pour compléter les seconds paquets de données précédemment reçus dans le flux de paquets de données. L'étape de retransmission peut par exemple être mise en oeuvre en utilisant un serveur auquel l'entité de traitement ou encore le terminal récepteur comprenant une telle entité de traitement, fait une requête de retransmission de paquets de données, le serveur étant alors adapté pour retransmettre, en unicast et/ou en multicast, les paquets de données requis. Puis, à l'étape 13, on est alors en mesure d'appliquer une correction d'erreur de type FEC sur la base à la fois des seconds paquets de données initialement reçu dans le flux et des seconds paquets de données retransmis, et de ce fait, il est ainsi possible de générer des premiers paquets de données qui n'avaient pas pu être générés précédemment, à l'étape 11. Dans un mode de réalisation de la présente invention, on peut envisager une combinaison des deux modes de réalisation ci-avant, afin de retransmettre à la fois des premiers et des seconds paquets de données à l'étape 12 selon le contexte de transmission et les premiers paquets de données manquants. On peut prévoir de mettre en oeuvre un mode de réalisation de la présente invention dans le contexte applicatif des services de type IPTV. Toutefois, aucune limitation n'est attachée à l'application dans laquelle ce procédé de réception peut avantageusement être mis en oeuvre. A partir des sections suivantes, il est aisé d'en déduire une mise en oeuvre dans d'autres contextes applicatifs. La figure 2 illustre une architecture de réseau adaptée pour diffuser un contenu vidéo via un réseau de transmission par paquet selon un mode de réalisation de la présente invention. Un contenu vidéo 25 est tout d'abord encodé au niveau d'un encodeur 24 selon un format vidéo donné, qui peut par exemple correspondre au format MPEG-2. Ensuite, des paquets de données transportant une information redondante de correction sont générés selon une méthode de correction d'erreur sans voie de retour telle que le FEC COP #3 à partir du contenu vidéo issu de l'encodeur 24. Ceci permet la mise en oeuvre en réception d'une correction éventuelle d'erreur sans voie de retour en cas de perte ultérieure de paquets de données. Dans un mode de réalisation de la présente invention, en sortie de l'encodeur 24, on obtient donc un contenu vidéo encodé 21 adapté pour être transmis dans un réseau de type IP 23, sous la forme d'un premier flux de paquets de données qui contient des paquets de données directement relatifs au contenu vidéo et d'un deuxième flux de paquets de données qui sont relatifs à l'information redondante à transporter permettant la correction d'erreur sans voie de retour au niveau de la réception du premier flux. Il convient de noter que l'on peut prévoir que l'encodeur 24 fournisse le flux encodé au format MPEG par exemple et que l'encodage de type FEC soit mis en oeuvre par une entité séparée située en sortie de l'encodeur 24. Aucune limitation n'est attachée à la présente invention au regard de cet aspect. II est possible que les paquets de données directement relatifs au contenu vidéo et les paquets de données qui sont relatifs à l'information redondante à transporter soient transmis dans un unique flux. Puis, ce flux de paquets de données 21 est reçu au niveau d'un terminal 22, qui peut être une 'Set Top Box', ou STB, ou encore un terminal de téléphonie mobile, ou un ordinateur, ou tout autre terminal adapté pour recevoir un tel contenu vidéo ainsi encodé. Le traitement en réception du contenu vidéo au niveau de ce terminal peut fournir à un utilisateur le contenu vidéo sur un écran. Dans un mode de réalisation de la présente invention, un tel terminal comprend une unité de traitement adaptée pour traiter le flux de paquets de données reçus de sorte à distinguer les premiers paquets de données des seconds paquets de données. Dans certains contextes d'encodage, la distinction entre ces deux types de paquets de données est plus aisée à mettre en place que dans d'autres. Par exemple, dans le cas où l'encodage FEC appliqué par l'encodeur 24 est de type FEC COP#3, il est très simple de faire cette distinction puisqu'il est prévu de recevoir les premiers paquets de données sur un port UDP (pour `User Datagram Protocol' en anglais) distinct de celui sur lequel sont reçus les seconds paquets de données. Cette unité de traitement est adaptée pour détecter si des paquets de données sont manquants dans ce flux de paquets de données reçu. Si tel est le cas, il est alors prévu d'appliquer les étapes de correction successives 11-13 décrites ci-avant. La figure 3 illustre une architecture d'une entité de traitement selon un mode de réalisation de la présente invention. Une telle entité de traitement 30 comprend une interface de réception 301 adaptée pour distinguer, d'une part, les premiers paquets de données et, d'autre part, les seconds paquets de données dans le flux de paquets de données. Elle comprend également une mémoire 302 adaptée pour mémoriser les seconds paquets de données. En effet, les seconds paquets de données peuvent être utilisés non seulement lors de la correction de type FEC appliquée au flux reçu, mais aussi suite à la correction basée sur la retransmission des paquets de données. II convient de sauvegarder ces seconds paquets de données reçus. Cette entité de traitement comprend en outre une première unité de détection 303 adaptée pour détecter si des paquets de données sont manquants dans le flux de 20 paquets de données reçu. Elle comprend en outre une première unité de correction 304 adaptée pour générer des premiers paquets de données perdus du flux de paquets de données, sur la base des seconds paquets de données mémorisés et pour fournir un flux de paquets de données complété. Ici, les premiers paquets de données du flux reçu sont 25 complétés par les premiers paquets de données générés. Puis, une deuxième unité de détection 305 est adaptée pour détecter si des paquets de données sont manquants dans le flux de paquets de données complété fourni par la première unité de correction. En effet, comme énoncé ci-avant, il est possible que des paquets de données n'aient pas pu être générés par la première 30 unité de correction. L'entité de traitement 30 comprend en outre une unité de gestion de retransmission 306 de paquets de données qui est adaptée pour recevoir des paquets de données retransmis et pour fournir un flux de paquets de données complété. A ce stade il convient de noter que l'unité de gestion de retransmission peut être 35 adaptée pour requérir la retransmission de premiers paquets de données et/ou de seconds paquets de données. En effet, suivant la structure des pertes au sein du flux de paquets de données, il peut être avantageux de compléter les seconds paquets de données pour être en mesure d'appliquer par la suite une correction FEC plus efficace. L'entité de traitement comprend en outre une troisième unité de détection 307 qui est adaptée pour détecter si des paquets de données sont manquants dans le flux de paquets de données complété fourni par l'unité de gestion de retransmission. Dans un mode de réalisation de la présente invention, les première, deuxième et troisième unités de détection sont adaptées pour détecter à la fois une perte de premiers paquets de données et une perte de seconds paquets de données. L'entité de traitement 30 comprend encore une seconde unité de correction 308 adaptée pour générer des premiers paquets de données perdus du flux de paquets de données, sur la base des seconds paquets de données mémorisés. La correction de type FEC appliquée par cette seconde unité de correction 308 peut avantageusement être mise en oeuvre sur la base de tous les seconds paquets de données initialement reçus dans le flux de paquets de données, mais également éventuellement sur la base de seconds paquets de données retransmis dans le cas où l'unité de gestion de retransmission a requis la retransmission de tels seconds paquets de données. L'unité de gestion de retransmission 306 peut être adaptée pour gérer la retransmission de paquets de données qui sont des premiers et/ou des seconds paquets de données, les seconds paquets de données éventuellement retransmis étant stockés dans la mémoire 302.25 REVENDICATIONS1. Procédé de réception, au niveau d'une entité de traitement (30), d'un contenu vidéo via un réseau de transmission par paquets, ladite entité de traitement recevant ledit contenu vidéo selon un flux de paquets de données (21) comprenant des premiers paquets de données relatives au contenu vidéo et des second paquets de données relatives à une correction d'erreur sans voie de retour ; ledit procédé de réception comprenant, au niveau de l'entité de traitement, les étapes suivantes : /1/ si des paquets de données sont manquants dans le flux de paquets de données, compléter ledit flux de paquets de données avec des premiers paquets de données générés sur la base des seconds paquets de données (11) et ; /2/ si des paquets de données sont manquants dans le flux de paquets de données obtenu à l'étape /1/, compléter le flux de paquets de données avec des paquets de données retransmis via ledit réseau de transmission (12) ; /3/ si des paquets de données sont manquants dans le flux de paquets de données obtenu à l'étape /2/, compléter le flux de paquets de données avec des premiers paquets de données générés sur la base des seconds paquets de données (13). 2. Procédé de réception selon la revendication 1, dans lequel, à l'étape /1/, les seconds paquets de données sont mémorisés au moins jusqu'à l'issue de l'étape /3/. 3. Procédé de réception selon la revendication 1, dans lequel les paquets de données retransmis sont des premiers et/ou des seconds paquets de données. 4. Procédé de réception selon la revendication 3, dans lequel, lorsque des paquets de données retransmis sont des seconds paquets de données, l'étape /3/ est en outre réalisée sur la base desdits seconds paquets de données retransmis. 5. Procédé de réception selon la revendication 1, dans lequel les seconds paquets de données sont issus d'un encodage de type ProMPEG Forum COP#3. 6. Entité de traitement (30) adaptée pour recevoir un contenu vidéo via un réseau de transmission par paquets selon un flux de paquets de données comprenant des premiers paquets de données relatives au contenu vidéo et des second paquets de données relatives à une correction d'erreur sans voie de retour ; ladite entité de traitement comprenant : une interface de réception (301) adaptée pour distinguer, d'une part, les premiers paquets de données et, d'autre part, les seconds paquets de données dans le flux de paquets de données ; une mémoire (302) adaptée pour mémoriser les seconds paquets de données ; une première unité de détection (303) adaptée pour détecter si des paquets de données sont manquants dans le flux de paquets de données reçu ; une première unité de correction (304) adaptée pour générer des premiers paquets de données perdus du flux de paquets de données, sur la base des seconds paquets de données mémorisés et pour fournir un flux de paquets de données complété ; une deuxième unité de détection (305) adaptée pour détecter si des paquets de données sont manquants dans le flux de paquets de données complété fourni par la première unité de correction ; une unité de gestion de retransmission (306) de paquets de données adaptée pour recevoir des paquets de données retransmis et pour fournir un flux de paquets de données complété ; une troisième unité de détection (307) adaptée pour détecter si des paquets de données sont manquants dans le flux de paquets de données complété fourni par l'unité de gestion de retransmission ; une seconde unité de correction (308) adaptée pour générer des premiers paquets de données perdus du flux de paquets de données, sur la base des seconds paquets de données mémorisés. 7. Entité de traitement (30) selon la revendication 6, dans laquelle l'unité de gestion de retransmission (306) est adaptée pour gérer la retransmission de paquets de données qui sont des premiers et/ou des seconds paquets de données ; et dans laquelle les seconds paquets de données éventuellement retransmis sont stockés dans la mémoire (302). 8. Terminal de réception de contenu vidéo via un réseau de transmission comprenant une entité de traitement (30) selon la revendication 6. 9. Boitier décodeur comprenant une entité de traitement (30) selon la revendication 6. 10. Système de réception (40) comprenant un boitier décodeur selon la revendication 9 et un écran (41) adapté pour afficher le contenu vidéo reçu. 11. Programme d'ordinateur, destiné à être stocké dans une mémoire d'une entité de traitement (30) selon la revendication 6, ou sur un support mémoire amovible et destiné à coopérer avec un lecteur de ladite entité de traitement, ledit programme d'ordinateur comprenant des instructions pour la mise en oeuvre de tout ou partie des étapes du procédé selon la revendication 1. 12. Support d'enregistrement sur lequel est stocké le programme d'ordinateur selon la revendication 11.