FR 3045258 A1 20170616 FR 1562043 A 20151209 cédé d'amélioration de la fiabilité de tranemission et de la qualité de réception de flux de données vidéos présente invention concerne 1 éliortion de la fiabilité de transmission et de la alité d.e réception de flux de données vidéos dans un réseau numérique sans fil, régi par un protocole de communication par exemple type WIFI. Le contexte de fonctionnement de l'invention peut par exemple être le suivant un événe public ayant lieu en un endroit est - fusé à destinatiee, des spectateurs qui sont sur place et qui s uhaitent en visualiser dec séquences particulières sur leur récepteur personnel (smartphone,tablette.), selon des modes de visualisation qui offrent d'ailleurs diverses possibilités additionnelles. Les flux vidéos concernés sont donc envoyés en multidiffusion ou multicast à partir d'au moins un émetteur, typiquement basé sur un ou plusieurs ordinateurs, vers des dispositifs récepteurs situés dans le périmètre couvert par par la liaison rsdio. ces dispositifs récepteurs prenant la forme desdits smartphones, tablettes etc. et étant dotés d'au moins une application logicielle permettant de traiter et de visualiser l'information reçue. Le traitement des données réalisé dans le cadre de l'invention permet d'améliorer la qualité e réception des flux vidéos en présence de pertes de données dans. une mesure telle qu'il n'est pas possible de reconstituer ces données via des algorithmes classiques de correction d'erreur par redondance. Ces pertes sont qualifiées de pertes e bur ». Dans le contexte de la diffusion pratiquement en temps réel d'événements du genre rencontres sportives ou spectacles, la visualisation fluide des images vidéos est évidemment recherchée. Elle devient nécessaire s'il existe. la possibilité d:erlrichir ladite visualisation par des traitements additionnels, par exemple la revisualisation à volonté de certaines séquences, et encore plus si ces sécpences doivent pouvoir être regardées au ralenti. De tels traitements implinuent évidemment que les flux vidéos, transmis sous forme depaquets de données contenant des 3045258 2 groupes d'images, soiert réceptiorms en une qualité suffisante pour que leur visualisation et revisualistion y compris au ralenti soit confortable Cela implique que les paquets de données aient ét correctement transmis ou éventuellement récupérés en 5 cas de problème. Les éventuels traitements ultérieurs des signaux vidéos réceptionnés peuvent alors se baser sur un socle solide de données. Cr, sur les réseaux locaux sans fil, quels que soient les protocoles de communication utilisés et surtout .ie moUe. de 10 diffusion (en multicast), le taux des erreurs de transmission - consistant en pratique en une perte de blocs d'informations transmis par ledit réseau - est compris entre 0% et 157 parfois plus. Lors de transmissions de flux vidéos, le résultat de ces pertes est une mauvaise qualité des vidéos obtenues, qui peuvent 15 être altérées jusqu'à empêcher la diffusion de certaines séquences. Les données vidéos envoyées intègrent en général des moyens de correction d'erreurs de transmission, par exemple par redondance via des algorithmes connus sous le nom d'algorithmes 20 AL-FEC (pour Application Level Forward Error Correction) plus précisément, les données sont usuellement de paquets de données successifs qui obéi an-mises sous forme ent à un découpage prédéterminé en vue de, leur envoi, ces paquets comportant très généralement les images transmettre, encodées pour la 25 transmission, et des informations additionnelles de redondance qui, en cas de problème de réception, sont utilisées par les algorithmes de reconstruction pour tenter de restituer les images initiales. De fait, le procédé de l'invention s'applique à des flux de 30 données vidéos codés sous forme de paquets comportant chacun K premiers blocs de données et N blocs de redondance pour la correction au moyen d'un algorithme de correction d'erreur directe (FEC). Ce flux comprend lui-même une succession de ces paquets comportant chacun. K+N blocs, émis en muiticast par au '.oins un 35 émetteur en direction des dispositifs de visualisation clien 3045258 type smartphones ou tablettes. Selon l'ineention, le proc1dé mis el, ouvre de la manière- suivante ee message d'acquettemene négatif NAK) intelligent est eeveei par au moins un dispositif client à au moins un 5 serveur dans le cas où 1 algorithme de correction d'erreur (FwC) ne peut. reconstituer dee données manquantes le serveur construit au moins r--euc'er table contenant des informationm contenues dans les messes 10 d'acquittement négatif(NAK) reçus des dioposit clients et indiquant les données manquantes. information de chaque message dacquittement négatif caractérisent un défaut de réception au niveau d'au moins un dispositif client ; 15 lesdites informations sont organisées dans ledit premier tableau classement ; les données elon un premier critère de manquantes sont renvoyées en émission multi a t sur un canal dédié, lon un ordre qui dépend 20 du ria ement effectué, le débit alloué disponible du canal d'erreur dédié est uffi dans un laps de temps compris dans une durée prédéterminée. L'applicateen logicielle qui tourne a cet effet sur le serveur nt en fait à jour au moins un tableau statistique contenant, 25 pour chaque erreur de transmission indiquée par chaque client, au moins une information caractérisant les données manquantes, et donc un défaut identifié par la ou les informations fournies. L'application gère ensuite le reflue des paramètres additionnels, à savoir 30 sur le canal de renvoi, dit canal données manquantes selon bande passante disponible eur, et également selon le temps de, traitement total : le nécessaire au renvoi des données manquantes doit rose eonnable par rapport aux attentes des possesseurs de dispositifs de visualisation client en relati avec l'événement diffusé. Le renvoi des données 35 s'effectue en diffusion générale (c'es re en multicast) au 3045258 4 moine da' -"aire d'c mene flux transu--: ocelet c3amaude. Un décalage entre le flux vIsible de 2 à 3 secondes est accepté, voire préférable, comme en le verra dans la suite. La estion de la bande passante doit garantir qu'il n'y a pas 5 d'effet d'avalanche, c'est-à-dire qu'elle ne devient pas utilisée plus pour 1cc renvois de données manquantes que pour l'envoi des donnees en temps réel. La gestion des paramètres addi second tableau lorsque des données manquantes correspondant à des 10 informations classées dans le premier tableau renvoyées pendant la durée prédéterminée, sont pan rt à partir du premier tableau d'au moins une fraction des informations d premier tableau correspondant aux données manquantes non renvoyées, les informations transférées étant oraniées selon le 15 même critère de classemen exemple le nombre d'occurrences, comme verra dans la suite), vue d'un renvoi ultérieur en multicast aux dispositifs clients selon le débit disponible sur le canal d'erreur dédié. Le second tableau n'est plus mis à la contrainte de temps 20 comme le premier, et il permet la gestion en décalage temporel dee flux de données vidéo, lorsque l'utilisateur veut par exemple revoir une .quence, ou encore se la repasser au ralenti etc. La durée prédéterminée pendant laquelle se fait le traitement « en temps réel » est donnée, selon l'invention, par une variable 25 nW modifiable dans le serveur. Cette variable définit le temps maximal entre l'envoi des données d'origine et le renvoi des données en erreur. Selon des tests effectués en vraie grandeur, cette variable nW peut définir une durée comprise entre 2s et 4s sans que cela ne soit préjudiciable au ressenti par l'utilisateur 30 du fonctionnement de la fonction. Selon la logique de construction du premier tableau propre à l'invention, une ligne de tableau correspond à un défaut de réception, le- colonnes étant cormtituéee d'au moins une information caractérisant ce défaut, et d'au moins un critère de 35 cleosement des lignes. Plus précisément, le critère de classement des :Lignes est de préférence le nortbre d'occurrences des ne à la créatio 'un 3045258 5 infe . ations caractérisant un m&re défaut de tion. Dès lors, comme une ligne correspond é. un défaut informations caractérisent un défaut réception reçu message d'acquittement négatif se trouvent déjà dans une ligne du premier tableau, nombre d'occurrences de cette ligne est incrémenté cb une unité, sinon une li t créée avec un nombre d'occurrence un. L'algorithme de gestion statistique des défauts de réception utilisé par l'application à l'oeuvre dans le serveur fonctionne de 10 préférence de manière telle que les données manouantes renvoyées selon un ordre décroissant du nombre de leurs occurrences si si le débit alloué sur le canar d'erreur le permet, igne correspondant aux données renvoyées étant supprimée après leur renvoi. 15 De préférence encore, la variable temporelle étant un facteur pris en compte dans le traitement des informations reçues en liaison avec le premier tableau, qui concerne le traitement « en temps réel », une des colonnes du premier tableau contient les date/heure/minute/seconde/milli-seconde à laquelle les données ont été initialement transmises par l'émetteur. En d'autres termes, le moment du premier envoi par etteur des données reçues en erreur par un ou plusieurs clients. Si une ligne trop ancienne pour correspondre à ce qui est identifié e au temps réel », et que les données correspondant au défaut identifié dans 25 ladite ligne n'ont pas été renvoyée dans le laps de temps prévu, le est transférée dans le second tableau. L'information contenant les date/ heure/minute/seconde/milli-seconde du premier envol présente dans une ligne apparaissant dans le premier tableau n'est cependant pas transférée. Cette ligne est dés lors supprimée 30 du premier tableau. Selon une possibilité, les a ions contenues dans les messages d'acquittement néga sur les données manquantes sérées dans le premier bleau comportent au moins le numéro de chaque paquet de données manquant. En variante 35 additeonnellement, ces informations peuvent être prises parmi informations suivantes : le 3045258 l'adzse physique (24AC de l'interface réseau du dispositif client L'adresse du point d'accès WIFI et le numéro du canal de ce peint d'accès WIFI ; 5 is leste des blocs K et N manquants. Certaine.' de ces informations permettent, comme cela sera expliqué plus en détail dans la suite, une pics grande précision dans la description du défaut, permett1ent un renvoi sur le canal d'erreur moins encombrant, optimisant la disponibilité de 10 la bande passante. On peut d'ailleurs concevoir, l'invention, d'envoyer les données manquantes sur une adresse multicast différente selon le point draccès WIFI et son numéro de Canal. De préférence, le message d'acquittement i intelligent 15 est envoyé en unicast par chaque dispositif client. Un renvoi en multicast est toujours possibles, dès lors sans l'accusé de réception qui caractérise les transmissions en unicast. L'invention va à présent être décrite plus en détail, en référence aux figu annexées, représentant oeuvre du procédé. de l'invention montrant les des flux vidéo et des informations en retour, exemple de mise espectifs quelles la fqure 1 représente un diagramme schématisant l'orcanisation des communications entre le serveur / émetteur et les dispositifs clients en cas de pertes « burst »; la figure 2 est un diagramme temporel des échanges de données ; et la figure 3 montre un exemple de tableau statistique pour coriection du flux de données en temps réel. 30 En référence e 1, le flux vidéo relatif à événement filmé est transmis é partir d'un émetteur, fenctionnant avec un serveur (4) en multidiffusion ou multi t sur n canaux vidéo (1) dénommés « VIDEO CHANNEL », le flux de données vidéos étant classiquement codé sous forme de paquets comportant chacun K 3045258 7 premiers bloc e , données et N blocs de reJendance pour la correction d' erceuc directe (FEC). En cas de tes « burst », concernant plusieurs paquets de données par exemple succefs et dans 1hypothse où l'algorithme de redondance FFC ne peut récupérer es données manquantes malgré l'existence des N blocs de redondance, les dispositifsclients: (5) concee défaut de transmission au émetteur serveur (4). st envoyé par un dispositif (5) paquet de données FEC avec une ible à corriger par l'algorithme de redondance. Cet envoi d'informations se fait sur un canal « NAK CHANNEL » fonctionnant en unicast, au débit par conséquent trèsfaible. Les dispo ' ifs clients envoient au émetteur / serveur (4) une 15 liste des informations manquantes, par exemple les identifiants des paquets de données manquants, ou les numéros des blocs KeN manquants, ou encore d'autres données qui seront précisées dans la suite. Le débit sur ce canal est négligeable. Les données perdues ont renvoyées par serveur, certaines 20 conditions, a un canal dit « ERROR CHANNEL », en multica Les données manquantes ne sont en effet pas systématiquement renvoyées, un traitement statistique effectué par 1 émetteur / serveur aboutit soit à l'émission vers les dispositifs clients (5) desdites données soit, au contraire, à ne rien envoyer. Parmi 25 les paramètres pris en considération à cet égard figure le débit. dudit canal d'erreur. L'application installée à cet sur le émetteur serveur(4) est en pratique chargée : - de récupérer les informations sur les paquets de données 30 perdus, en provenance des dispositifs client (5) ; - de gére H.ANNeee. e passante allouée au canal (3) « ERROR - de gérer les deux tableaux statistiques concernant le tem réel et ie décalé ; et En fait, un acquittement néga 10 à chaque fois qu'il reçoi erreur impo envoient des infermatio 3045258 - d'appliquer l'algorithme de renvoi des paquets de données FEC. Il s'agit en p de reconstruire d tampons ou buffers des dispositifs clients avec données manquantes et de les renvoyer via le canal d'erreur . A cet égard, le temps est un paramètre déterminant, un diadramme t. ore. illustrant ister dans procédé de l'invention apparaissant en figure 2. 'envoi en temps dure au 10 mieux d = 0,7 s, temps de latence, requis pour que lesdits flux soient réceptionnés sur les tablettes, smartphones etc. Selon la seconde phase, qui se passe négatif et a lieu en cas de d'erreur de décodage FEC, des informations sur les paquets, blocs de données manquantes, sont 15 envoyées vers et reçues par le serveur qui constitue les ableaux statistiqu vue d'obtenir les données en défaut. Cela s'effectue sur une durée somme des deux durées ci-dessus constitue une variable de n tionnement du système, un paramètre d l'application : au bout de nW ms, d2, le serveur (4) 20 décide. de renvoyer ou non le ou les paquets ou blocs manquants, selon la bande passante utilisée par canal (3) d'erreur. Le renvoi éventuel des données manquantes ur ce dernier canal (3) dure senîblement autant que pour la première phase, et s'effectue également multi ast. 25. La variable nW est très importante pour la gestion des flux en temps réel, car elle définit le temps maximal admissible entre l'envoi des paquets d'origine et leur réenvoi après acquittement gatif. Elle peut être utilisée pour reconstruira les buffers manquants dans le traitement en temps réel. Il faut alors les différen échanges q ont susceptibles réel des flux vidée en multicast via Yes canaux y canal (2) diacq7littement. 30 augment ou plus. Un premae en temps réel est montré en figure 3. Ce temps de latence, qui être porté à 2 s, voire 2,5 s tableau statistique pour la gestion des flux vidéo ier tableau ne contient tue des paquets ou sessions perdus qui ont été 35 initialement envoyés il y a moins de m (colonne cen,rale). Les modalités de leur insertion dans le tableau sont les 3045258 9 ivantes plication sur le serveur (4) e,,cou nages s par les clients eelee le canal d'acquittement négatif (2), retournent en occurrence des sessions perdues. Chaque session perdue est ajoutée au tableau (Ce tableau 5 trié de manière décroissante suivant le nombre d'occurrence de l'erreur) la figure 3 suivant un algorithme qui les traite de la marnière suivante : si la session perdue (colonne de gauche) est définie par des caractéristiqu CI apparaissent déjà -ans le tableau, 10 définissant un défaut déjà identifié, le nombre d'occurrences (colonne de droite) est incrémenté de 1 ; si elle n'est pas encore contenue dans le tableau, une ligne est créée colonne Date/Time est initialisie avec date/heure inute seconde/milli-seconde correspondant à la date 15 initiale d'envoi de ce paquet par l'émetteur) dans ce premier tableau avec un nombre d'occurrences égal 1. L'application scrute le tableau selon une périodicité prédéterminée, et renvoi les sessions perdues via le canal (3) multicast d'erreur, en commençant par celles qui ont le plus 20 d'occurrences, l'occurrence situées en haut de tableau. Lorsqu'une session. est renvoyée, la ligne correspondante est pprimée du tableau. L'application garantie que le débit de ce canal (3) de correction n'est jamais dépassé, ce qui veut dire qu'il n'est pas toujours possible de renvoyer des données suivant 25 le canai (3), si le débit cet effet est insuffisant. Si une ligne est trop ancienne, c'est-à-dire que ce qui apparaît (date/time) en colonne centrale est supérieur à date courante - nW sans que les données manquantes correspondantes aient été renvoyées, du fait d'une contrainte de débit (débit 30 inauffisant), elle est supprimée de ce tableau de la fie re 3 et envoyée dans un second tableau statistique (non représenté). Ce second tableau est similaire au premier, mains la colonne centrale temporelle qui permet la gestion des décalages temporels, le temps n'étant plus un. critère de gestion au. sens 'an 'cation 35 serveur. C'est cette application qui procide au transfert 'un tableau a l'autre. L'insertion s'y lai ,v au selon le nombre 3045258 10 eccu n es, e vereble de classement possible, la e3e5. ate il est vrai. Ce eecond tabïemSachant que 1, premier ableau est prioritaire pour l'occupation de la barde passante sur la canal «Error Channel également l'objet de suppressions de lignes, sur la base du paramètre constitue par le débit du canal ERROR CHANNEL » si la bande passante encore disponible 'excède pas la limite qui est allouée à ce canal (3), les sessions FEC econd -tableau ayant les plus grandes occurrences. sont 10 renvoyées à concurrence de. la limite de débit dudit canal (3). Chaque session renvoyée est ensuite effacée de ce second tableau. Tant que session FEC objet d'une ligne n'est pas renvoyée, ladite ligne reste dans le tableau. Selon 'invention, une optimisation de la gestion des pertes 15 « burst » peut consister en une caractérisation plus précise des données manquantes que ce cfui n été évoqué ci-dessus, Ainsi, dans l'hypothèse dont il n ét question jusqu'ici, le message d'acquittement négatif intelligent comporte l'adresse MAC du client, le N° du canal vidéo et le- N° de paquet de données. Dans 20 ce cas, le serveur retourne le cas échéant toutes les données K et N du paquet en erreur.. Cette solution est facile à mettre en oeuvre, peu gourmande en bande passante unicast, mais certaines données retournées sur le canal (3) sont redondantes, ce qui peut. créer problème en termes de débit du. canal d'erreur. 25 Selon une variante possible, le dispositif client (5) retourne au serveur (4), sur le même canal (2) et en plus des informations précédentes, la liste des blocs K et N manquants. Avec cette information supplémentaire, le serveur (4) peut ne renvoyer que les K et N blocs non reçus de 1 ion FEC en erreur. La solution 30 est précise et avantageuse en termes de bande passante sur le d'erreur, seules les données vraiment utiles sont renvovee n une autre variante encore, une nouvelle information en ajoutée à celles qui font l'onjet de la variante. pr&sédente : le 35 point d'acces du réseau WIFI, ou plue généralement du réseau employé. D- e cas, la diffusion en multnast de la part du 3045258 11 ssiveur (4) sur anal d'e-reur (3) -'effectue à destination de plusieurs adresses multicast, une adresse multicast par pointccee oa par groupe de point accès. Cette solution, qui it. le serveur (4) retourner les blocs K et N menquant d'une 5 session FEC selon le point d au auxque_s les dispos clients (5) qui ont envoyé un message d'erreur sont rattachés, nécessite de paramétrer les commutateurs réseau de rsanière à adresses multicest accessibles par les différents point aces. Elle optimise 1-ait encore plus la bande 10 pansante que la solution précédente. l'our toutee solutions, une variante possible, selon l'invention, con-. rendre le canal ) d'acquittement négatif multica défaut de réception survient, le premier dispositif client. (5) qui accède au réseau et renvoie un message d'erreur le fait dès lors en 15 multidif u ion, c'est-à-dire également à destination des autres dispositifs clients () Ceux qui sont dans le même cas n'ont par conséquent plus à renvoyer le message à l'adresse du serveur (4). Le trafic réseau des dispositifs clients vers le serveur (4) s'en trouve allégé. Le message d'erreur ne bénéficie cependant 20 plus d'un accusé de réception de la part du serveur (4), inexistant en muiticast, et le problème rencontré cd est plus art des dispositifs clients (5) qui n sont victimes ne le font pas savoir. L'invention ne se limite bien entendu pas aux exemples décrits 25 et expl en référence aux figures, mais elle englobe les variantps versions qui entrent dans la portée des revendications. REVENDICATIONS1. Procédé d'amélioratien de la fiablîcé de transmission et de la qualité de réception de flux de données vidéos sur un réseau sans fil régi par des protocoles de remunication de type WIFI, les données ridécs étant codé sous forme de paquets comportant chacun Y premiers blocs de données et N blocs de redondance pour correction au moyen d'un algorithme de correc d'erreur directe(FEC), le flux 10 vidéo comprenant une succession desdits paquets de données émis en multicast par au moins un émetteur en direction des dispositifs de visualisation clients (5) de visualisation de type smartphones ou tablettes, caractérisé en ce que 15 un message d'acquittement négatif (NAK) intelligent est envoyé par. au moins un dispositif client au. moins un serveur (4) dans le sas où l'algorithme de correction d'erreur (FEC) ne peut reconstituer données manquantes ; 20 - le serveur construit au moins un. premier tableau contenant des informations contenues dans les messages d'acquittement négatif (NAK) reçus des d po-it clients et indiquant les données manquantes, nes informations d. chaque message d'acquittement Li 25 caractérisant défaut de réception u niveau d'au moins un dispositif client (5) ; - lesdites informations sont organisées dans ledit premier tableau selon un premier critère de classement 30 données manquantes sont renvoyées en émission multicast sur un canal dédié du classement effectué, un ordre qui dépend ébit alloué disponible du canal d'erreur (3) dédié ess suffisant, et dans un laps de temps compris dans une durée prédéterminée. 3045258 13 2. Procédé d'amélioration fisbilite ri de 1a aralité réception de flux de données vidéos sur un réseau local ans fil, revendics on précédente, caractérisé en ce 'il y a création d'un second tableau lorsque de dorures manquantes correspondant a des informations classées dans premier tableau ne sont pas renvoyées pendant la durée prédétereenée, par transfert à pa ir du premier tale7._- au moins une fracticn de luf .1ns dudit mien ableau correspondant aux dcnnées s non renvoyées, les informations transférées étant organisées selon le même critère de clasetdenL, en vue d'un renvoi ultérieur en molei ast aux dispositifs clients (4) selon le débit disponible sur le canal d'erreur (3) dédié. 3. Procédé d'amélioration de la fiabilité et de la qualité de réception de flux de données vidéos sur un réseau sans 1 selon l'une des revendications précédentes, caractérise en ce que la durée prédéterminée est donnée par une variable nW modifiable le serveur. 4. Procédé d'amélioration de la fiabilité et de ité de réception de flux de données vidéos sur un réseau selon la revendication précédente, caractér 1 e la variable nW définit une durée comprise entre 2s et 4s. 5. Procédé d'amélioration de la fiabilité et de la qualité de réception de flux de données vidéos sur un réseau sans fil selon l'une des revendications précédentes, caractérisé ce qu'une ligne de tableau correspond àun unique défaut de réception, les colonnes constituées d'au moins une information caractérisant ce défaut, et d'au moins un critère de classement des lignes. 6. Procédé d'amélioration iasilité et de la qualité de réception de flux données vidéos aur un réseau sa selon. la revendication précédente. caractérisée en ce le critère de classement des lignes est le nombre d'occurrences informations caractérisant un. même défaut 'de réception. 3045258 14 7. Pioceldê' d'ami4inrat réception de fiabilité et de la qualité de canées vidéos sur ans fil selcla revendication précédente caractérisé ce que, si des informations caractérisant: un défaut de réception 5 reçues d'un message d'acquittement négatif se trouvent dans une ligne du premier tableau, le nombre d'occurrence de nette ligne est ncrémenti d'une unité, sinon une ligne est créée avec un nombre d'occurrences égal un- 10 8. Procédé d'amélioration de la fiabilité et de la a .-ité de réception de flux de données vidéos sur un réseau sans fil selon l'une des revendications précédente, caractérisée en ce que les données manquantes sont renvoyées selon un ordre décroissant du nombre de leurs occurrences, si le débit 15 alloué sur le canal d'erreur 1 le permet, la ligne correspondant aux données renvoyées étant supprimée après leur renvoi. 9. Procédé dnamélioration de la fiabilitéet de la qualité de réception de flux de données vidéos sur un réseau sans fil 20 selon l'une des revendications 5 à 8, caractérisé en ce qu'une des colonnes du premier tableau contient / heure. / minute f seconde / milli-seconde à laquelle les données ont été initialement transmises par l'émetteur. 10.Procédé d'amélioration de la fiabilité et de la qualité de 25 réception de flux de données vidéos sur un réseau sans fil selon la revendication précédente, caractérisé en ce que l'information contenant les date / heure / minute / seconde / milli-seconde du premier envoi préserte dans une ligne apparaissant dans le premier tableau n'est pas transférée 30 au second tableau. 11.Precéd'd'amélioration de la fiab±ldté et de la qualité de réception de tiux de données vidéos sur un réseau sans fil l'une des revendications 2 à 10, caractérisée en ce que les informations sur les données manouantes 35 transfé ées du premier au second tableau sont supprimées du premier tabieautableau 3045258 15 Srcédé oration de la fiabilité et -JE la qualité de recept ux de données vidéos sur un reeam si,ro fil selon l'une des revendications précédentes, caractérisée en ce que les informations contenues dans es messages 5 d'acquittement négatli sur 1e données manquantes insérées dans le premier tableau comportent au moins le numéro de chaque, paquet de données manquant. 13.Procédé lioration de la fiabilité et de la qualité :récept±oe d flux de données vidéos sur un rése pans 10 55100 la revendication précédente, car rise que informations additionnelles sur les données manquantes sLn., prises parmi les informations suivantes : l'adresse physique (MAC) de l'interface réseau du dispositif client ; 15 L'adresse du point d'accès WIFI et le numéro du canal de ce point d'accès WIFI ; la liste des blocs K et N manquants. 14.Procéd d'amélioration de la fiabilité et de la. qualité de réception de flux de données vidéos sur un réseau local 20 sans fil selon la revendication précédente, caractérisée que les données manquantes sont envoyées sur une adresse multicast différente selon le point d'accès WIFI et son numéro de Canal. 15.Procédé d'amélioration de la fiabilité et de la qualité de 25 réception de flux de données vidéos sur un réseau, local sans fil selon l'une des revendications préo dentes, caractérisée en ce e,ment négact e le message d'ac intelligent est envoyé en unicast par chaque dispositif client (5). 30