WO2017098177A1 - Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos - Google Patents

Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos Download PDF

Info

Publication number
WO2017098177A1
WO2017098177A1 PCT/FR2016/053293 FR2016053293W WO2017098177A1 WO 2017098177 A1 WO2017098177 A1 WO 2017098177A1 FR 2016053293 W FR2016053293 W FR 2016053293W WO 2017098177 A1 WO2017098177 A1 WO 2017098177A1
Authority
WO
WIPO (PCT)
Prior art keywords
improving
reception
video data
reliability
information
Prior art date
Application number
PCT/FR2016/053293
Other languages
English (en)
Inventor
Pierre KEIFLIN
Christophe CARNIEL
Daniel DEDISSE
Original Assignee
Vogo
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 Vogo filed Critical Vogo
Publication of WO2017098177A1 publication Critical patent/WO2017098177A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0057—Block codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0093—Point-to-multipoint

Definitions

  • the present invention relates to the improvement of the transmission reliability and the reception quality of video data streams in a digital wireless network, governed by a communication protocol, for example WIFI type.
  • a communication protocol for example WIFI type.
  • the operating context of the invention may for example be the following: a public event taking place in one place is broadcast to spectators who are on site and want to view particular sequences on their personal receiver (smartphone, tablet. .), according to modes of visualization which offer besides various additional possibilities.
  • the video streams concerned are therefore multicast or multicast sent from at least one transmitter, typically based on one or more computers, to receiving devices located in the perimeter covered by the radio link, these receiving devices taking the form of said smartphones. , tablets etc. and having at least one software application for processing and viewing the information received.
  • the data processing performed in the context of the invention makes it possible to improve the quality of reception of the video streams in the presence of data losses to such an extent that it is not possible to reconstruct these data via conventional algorithms of data. error correction by redundancy. These losses are described as "burst" losses.
  • the rate of transmission errors - consisting in practice in a loss of blocks of information transmitted by said network - is between 0% and 15%, sometimes more.
  • the result of these losses is a poor quality of the videos obtained, which can be altered to prevent the broadcast of certain sequences.
  • the video data sent generally incorporate means for correcting transmission errors, for example by redundancy via algorithms known as AL-FEC algorithms (for Application Level Forward Error Correction). More precisely, the data are usually transmitted. in the form of successive data packets which obey a predetermined division for sending them, these packets very generally comprising the images to be transmitted, encoded for transmission, and additional redundancy information which, in the event of a problem of reception, are used by the reconstruction algorithms to try to restore the initial images.
  • AL-FEC algorithms for Application Level Forward Error Correction
  • the method of the invention applies to packet-coded video data streams each comprising K first data blocks and N redundancy blocks for the correction by means of a direct error correction algorithm.
  • This stream itself comprises a succession of these packets each comprising K + N blocks, transmitted in multicast by at least one transmitter towards the client's display devices. type smartphones or tablets.
  • the method is implemented as follows:
  • an intelligent negative acknowledgment message is sent by at least one client device to at least one server in the case where the error correction algorithm (TEC) can not reconstruct missing data;
  • the server constructs at least a first table containing information contained in the negative acknowledgment messages (NAKs) received from the client devices and indicating the missing data.
  • the information of each negative acknowledgment message characterizes a reception defect at at least one client device;
  • said information is organized in said first table according to a first ranking criterion
  • the missing data are returned in multicast transmission on a dedicated channel, in an order that depends on the classification performed, if the available available rate of the dedicated error channel is sufficient, and within a period of time within a predetermined time.
  • the software application that runs for this purpose on the server actually updates at least one statistical table containing, for each transmission error indicated by each client, at least one information characterizing the missing data, and therefore a defect identified by the or the information provided.
  • the application then manages the return of the missing data according to additional parameters, namely the available bandwidth on the return channel, called the error channel, and also according to the total processing time: the time required to return the missing data must remain reasonable in relation to the expectations of the owners of client visualization devices in relation to the event broadcast.
  • the transfer of the data is carried out in general broadcast (that is to say in multicast) at less in the area from which the demand emanates. An offset between the stream transmitted in real time and the visible stream of 2 to 3 seconds is accepted, or even preferable, as will be seen later. Bandwidth management must ensure that there is no avalanche effect, that is, it does not become used more for missing data referrals than for sending out data. real-time data.
  • the management of the additional parameters leads to the creation of a second table when missing data corresponding to information classified in the first table are not returned for the predetermined duration, by transfer from the first table of at least a fraction of the information from said first table corresponding to the missing data not returned, the transferred information being organized according to the same ranking criterion (for example the number of occurrences, as will be seen later), with a view to a subsequent multicast forwarding to client devices according to the available throughput on the dedicated error channel.
  • the same ranking criterion for example the number of occurrences, as will be seen later
  • the second table is no longer subject to the time constraint as the first, and it allows time-shifted management of video data streams, when the user wants, for example, to review a sequence, or to replay it in slow motion, etc. .
  • the predetermined duration during which the "real-time” processing is done is given, according to the invention, by a variable nw that can be modified in the server.
  • This variable defines the maximum time between sending the original data and returning the data in error. According to tests carried out in full size, this variable nW can define a duration of between 2s and 4s without this being detrimental to the feeling by the user of the functioning of the function.
  • a table line corresponds to a reception defect, the columns being constituted by at least one item of information characterizing this defect, and at least one criterion for classifying the rows.
  • the criterion for ranking the rows is preferably the number of occurrences of the information characterizing the same reception defect. Therefore, since a line corresponds to an identified fault, if information characterizing a reception defect received from a negative acknowledgment message is already in a row of the first array, the number of occurrences of this line is incremented by a unit, otherwise a line is created with a number of occurrences equal to one.
  • the statistical reception error handling algorithm used by the application at work in the server preferably operates in such a way that the missing data is returned in a descending order of the number of their occurrences, if the bit rate allocated on the server. error channel allows, the line corresponding to the returned data being deleted after they are returned.
  • the temporal variable being a factor taken into account in the processing of the information received in connection with the first table, which concerns the "real time” processing
  • one of the columns of the first table contains the date / time / minute / second / millisecond at which the data was originally transmitted by the sender.
  • a line is too old to correspond to what is identified as "real time”
  • the data corresponding to the defect identified in that line have not been returned within the expected time, it is transferred to the second table .
  • the information containing the date / time / minute / second / milli-second of the first transmission present in a line appearing in the first table is however not transferred. This line is deleted from the first table.
  • the information contained in the negative acknowledgment messages on the missing data inserted in the first table includes at least the number of each missing data packet.
  • this information may be taken from the following information: the physical address (MAC) of the network interface of the client device;
  • the WXFZ access point address and the channel number of this WIFI access point are The WXFZ access point address and the channel number of this WIFI access point;
  • the intelligent negative acknowledgment message is sent in unicast by each client device. Multicast forwarding is always possible, therefore without the acknowledgment that characterizes unicast transmissions.
  • FIG. 1 represents a diagram schematizing the organization of communications between the server / issuer and the client devices in case of "burst" losses;
  • FIG. 2 is a timing diagram of the data exchanges
  • Figure 3 shows an example of a statistical table for correction of the real-time data flow.
  • the video stream relating to the filmed event is transmitted from a transmitter, operating with a multicast or multicast server (4) on n video channels (1) called "VIDEO CHANNEL", the stream of video data being conventionally coded in the form of packets each comprising K first data blocks and N redundancy blocks for forward error correction (FEC).
  • FEC forward error correction
  • the client devices (5 ) concerned by the transmission failure send information in this regard to the sender / server (4).
  • a negative acknowledgment is sent by a device (5) each time it receives a FEC data packet with an error impossible to be corrected by the redundancy algorithm.
  • This sending of information is done on a channel (2) said "NAK CHANNEL" operating in unicast, therefore very low flow.
  • the client devices (5) send to the sender / server (4) a list of the missing information, for example the identifiers of the missing data packets, or the numbers of the K + N blocks that are missing, or else other data that will be specified in the following.
  • the flow on this channel is negligible.
  • the lost data is returned by the server, under certain conditions, via a channel (3) called "ERROR CHANNEL" in multicast. Missing data are not systematically sent back, a statistical processing carried out by the sender / server (4) results either in the transmission to the client devices (5) of said data or, conversely, in sending nothing. Among the parameters taken into consideration in this regard is the rate of said error channel (3).
  • time is a determining parameter, a time diagram illustrating the different exchanges that may exist in the method of the invention appearing in FIG. 2.
  • the second phase which occurs on the negative acknowledgment channel (2) and takes place in case of FEC decoding error, information on the packets, missing data blocks, are sent to and received by the server (4) which constitutes the statistical tables in order to obtain the data in default. This is done over a period d 2 .
  • the server (4) decides whether or not to send back the missing packets or blocks, depending on the bandwidth used by the error channel (3).
  • the possible return of the missing data on this last channel (3) lasts substantially as much as for the first phase, and is also carried out in multicast.
  • nW variable is very important for real-time flow management because it defines the maximum allowable time between sending the original packets and resending them after negative acknowledgment. It can be used to rebuild missing buffers in real-time processing. XI must then increase the latency, which is increased to 2 s, or 2.5 s or more.
  • a first statistical table for the management of real-time video streams is shown in Figure 3.
  • the modalities of their insertion in the table are the following: the application on the server (4) listens for the messages sent by the clients via the negative acknowledgment channel (2), which in this case return the numbers of the lost sessions. Chacrue lost FEC session is added to the table (This table is sorted down according to the number of occurrence of the error) of Figure 3 following an algorithm that treats them as follows:
  • the lost session (left column) is defined by characteristics that already appear in the table, defining a previously identified defect, the number of occurrences (right column) is incremented by 1;
  • the application scans the table according to a predetermined periodicity, and returns the lost sessions via the multicast error channel (3), starting with the ones with the most occurrences, in this case at the top of the table. When a session is returned, the corresponding row is removed from the table.
  • the application guarantees that the flow rate of this correction channel (3) is never exceeded, which means that it is not always possible to send data according to the channel (3), if the bit rate at that channel effect is insufficient.
  • This second table (knowing that the first table has priority for the occupancy of the bandwidth on the channel "Error Channel”) is also the subject of deletions of lines, on the basis of the parameter constituted by the flow rate of the channel (3 ) "ERROR CHANNEL": if the bandwidth still available does not exceed the limit that is allocated to this channel (3), the FEC sessions in this second table having the largest occurrences are returned up to the limit of the bit rate of said channel (3). Each returned session is then deleted from this second table. As long as the FEC session object of a row is not returned, that row remains in the array.
  • an optimization of burst loss management can consist in a more precise characterization of the missing data than what has been mentioned above.
  • the intelligent negative acknowledgment message includes the MAC address of the client, the video channel number and the data packet number.
  • the server returns all the K and N data of the packet in error. This solution is easy to implement, not very greedy unicast bandwidth, but some data returned on the channel (3) are redundant, which can create problem in terms of flow of the error channel.
  • the client device (5) returns to the server (4), on the same channel (2) and in addition to the previous information, the list of blocks K and N missing.
  • the server (4) can return only the K and N blocks not received from the FEC session in error. The solution is more accurate and advantageous in terms of bandwidth on the error channel (3), only the really useful data is returned.
  • new information added to those that are the subject of the previous variant the access point of the WIFI network, or more generally the network used.
  • the multicast broadcast from the server (4) on the error channel (3) is made to several multicast addresses, for example a multicast address per access point or per access point group.
  • This solution which sees the server (4) return the missing K and N blocks of a FEC session according to the network access point to which the client devices (5) which sent an error message are attached, requires parameterizing the switches of the network so as to filter the multicast addresses accessible by the different access points. It thus optimizes the bandwidth even more than the previous solution.
  • a possible variant according to the invention consists in making the negative multicast acknowledgment channel (2).
  • the first client device (5) that accesses the network and returns an error message does so in multicast, that is to say also to other client devices (5). ). Those in the same case therefore no longer have to return the message to the server address (4). Network traffic from the client devices (5) to the server (4) is lightened. However, the error message no longer receives an acknowledgment from the server (4), non-existent in multicast, and the problem encountered is no longer quantified, since most of the client devices (5) that are victims do not make it known.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Procédé d'amélioration de la fiabilité 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 communication de type WIFI. Les données vidéos sont codées 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). Le flux vidéo comprend une succession desdits paquets de données émis en multicast par an moins un émetteur en direction de dispositifs de visualisation clients (5) de visualisation de type smartphones ou tablettes. Des messages d'acquittement négatif envoyés par les dispositifs clients sont utilisés par le serveur pour construire un tableau statistique à partir duquel certaines au moins des données mandantes sont renvoyées aux dispositifs clients.

Description

Procédé d'amélioration de la fiabilité de transmission et de la qualité de réception de flux de données vidéos
La présente invention concerne l'amélioration de la fiabilité de transmission et de la qualité de 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 de type WIFI. Le contexte de fonctionnement de 1 ' invention peut par exemple être le suivant : un événement public ayant lieu en un endroit est diffusé à destination des spectateurs qui sont sur place et qui souhaitent en visualiser des 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 la liaison radio, 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é de 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 « burst ».
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'enrichir ladite visualisation par des traitements additionnels, par exemple la revisualisation à volonté de certaines séquences, et encore plus si ces séquences doivent pouvoir être regardées au ralenti. De tels traitements impliquent évidemment que les flux vidéos, transmis sous forme de paquets de données contenant des groupes d'images, soient réceptionnés en une qualité suffisante pour que leur visualisation et revisualisation 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 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 .
Or, sur les réseaux locaux sans fil, quels que soient les protocoles de communication utilisés et surtout le mode de 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 15%, 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 ê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 AL-FEC (pour Application Level Forward Error Correction) plus précisément, les données sont usuellement transmises sous forme de paquets de données successifs qui obéissent à 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 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 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 multicast par au moins un émetteur en direction des dispositifs de visualisation clients de type smartphones ou tablettes. Selon l'invention, le procédé est mis en œuvre de la manière suivante :
un message d'acquittement négatif (NAK) intelligent est envoyé par au moins un dispositif client à au moins un serveur dans le cas où l'algorithme de correction d'erreur (TEC) ne peut reconstituer des données manquantes ;
le serveur construit au moins un premier tableau contenant des informations contenues dans les messages d'acquittement négatif (NAK) reçus des dispositifs clients et indiquant les données manquantes. Les informations de chaque message d'acquittement négatif caractérisent un défaut de réception au niveau d'au moins un dispositif client ;
- lesdites informations sont organisées dans ledit premier tableau selon un premier critère de classement ;
les données manquantes sont renvoyées en émission multicast sur un canal dédié, selon un ordre qui dépend du classement effectué, si le débit alloué disponible du canal d'erreur dédié est suffisant, et dans un laps de temps compris dans une durée prédéterminée.
L'application logicielle qui tourne à cet effet sur le serveur tient en fait à jour au moins un tableau statistique contenant, 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 renvoi des données manquantes selon des paramètres additionnels, à savoir la bande passante disponible sur le canal de renvoi, dit canal d'erreur, et également selon le temps de traitement total : le temps nécessaire au renvoi des données manquantes doit rester raisonnable par rapport aux attentes des possesseurs de dispositifs de visualisation client en relation avec l'événement diffusé. Le renvoi des données s'effectue en diffusion générale (c'est-à-dire en multicast) au moins dans l'aire d'où émane la demande. Un décalage entre le flux transmis en temps réel et le flux visible de 2 à 3 secondes est accepté, voire préférable, comme on le verra dans la suite. La gestion de la bande passante doit garantir qu'il n'y a pas d'effet d'avalanche, c'est-à-dire qu'elle ne devient pas utilisée plus pour les renvois de données manquantes que pour l'envoi des données en temps réel.
La gestion des paramètres additionnels amène à la création d'un second tableau lorsque des données manquantes correspondant à des informations classées dans le premier tableau ne sont pas renvoyées pendant la durée prédéterminée, par transfert à partir du premier tableau d'au moins une fraction des informations dudit premier tableau correspondant aux données manquantes non renvoyées, les informations transférées étant organisées selon le même critère de classement (par exemple le nombre d'occurrences, comme on le verra dans la suite), en 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 soumis à la contrainte de temps comme le premier, et il permet la gestion en décalage temporel des flux de données vidéo, lorsque l'utilisateur veut par exemple revoir une sé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 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 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, les colonnes étant constituées d'au moins une information caractérisant ce défaut, et d'au moins un critère de classement des lignes. Plus précisément, le critère de classement des lignes est de préférence le nombre d'occurrences des informations caractérisant un même défaut de réception. Dès lors, comme une ligne correspond à un défaut identifié, si des informations caractérisant un défaut de réception reçues d'un message d'acquittement négatif se trouvent déjà dans une ligne du premier tableau, le nombre d'occurrences de cette ligne est incrémenté d'une unité, sinon une ligne est créée avec un nombre d'occurrences égal à un.
L'algorithme de gestion statistique des défauts de réception utilisé par l'application à l'oeuvre dans le serveur fonctionne de préférence de manière telle que les données manquantes sont renvoyées selon un ordre décroissant du nombre de leurs occurrences, si le débit alloué sur le canal d'erreur le permet, la ligne correspondant aux données renvoyées étant supprimée après leur renvoi .
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 l'émetteur des données reçues en erreur par un ou plusieurs clients . Si une ligne est trop ancienne pour correspondre à ce qui est identifié « au temps réel », et que les données correspondant au défaut identifié dans ladite ligne n'ont pas été renvoyée dans le laps de temps prévu, elle est transférée dans le second tableau. L'information contenant les date/ heure/minute/seconde/milli-seconde du premier envoi 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 du premier tableau.
Selon une possibilité, les informations contenues dans les messages d'acquittement négatif sur les données manquantes insérées dans le premier tableau comportent au moins le numéro de chaque paquet de données manquant. En variante ou additionnellement, ces informations peuvent être prises parmi les informations suivantes : l'adresse physique (MAC) de l'interface réseau du dispositif client ;
L'adresse du point d'accès WXFZ et le numéro du canal de ce point d'accès WIFI ;
la liste des blocs K et N manquants .
Certaines de ces informations permettent, comme cela sera expliqué plus en détail dans la suite, une plus grande précision dans la description du défaut, et permettent un renvoi sur le canal d'erreur moins encombrant, optimisant la disponibilité de la bande passante.
On peut d'ailleurs concevoir, selon l'invention, d'envoyer les données manquantes sur une adresse multicast différente selon le point d'accès WIFI et son numéro de Canal.
De préférence, le message d'acquittement négatif intelligent 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.
I,'invention va à présent être décrite plus en détail, en référence aux figures annexées, représentant un exemple de mise en œuvre du procédé de l'invention montrant les trajets respectifs des flux vidéo et des informations en retour, pour lesquelles : la figure 1 représente un diagramme schématisant l'organisation 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 la correction du flux de données en temps réel.
En référence à la figure 1, le flux vidéo relatif à événement filmé est transmis à partir d'un émetteur, fonctionnant avec un serveur (4) en multidiffusion ou multicast 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 premiers blocs de données et N blocs de redondance pour la correction d'erreur directe (FEC) .
En cas de pertes « burst », concernant plusieurs paquets de données par exemple successifs, et dans l'hypothèse où l'algorithme de redondance FEC ne peut récupérer les données manquantes malgré l'existence des N blocs de redondance, les dispositifs clients (5) concernés par le défaut de transmission envoient des informations à cet égard au émetteur / serveur (4) . En fait, un acquittement négatif est envoyé par un dispositif (5) à chaque fois qu'il reçoit un paquet de données FEC avec une erreur impossible à corriger par l'algorithme de redondance. Cet envoi d'informations se fait sur un canal (2) dit « NAK CHANNEL » fonctionnant en unicast, au débit par conséquent très faible. Les dispositifs clients (5) envoient au émetteur / serveur (4) une liste des informations manquantes, par exemple les identifiants des paquets de données manquants, ou les numéros des blocs K+N 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 sont renvoyées par le serveur, à certaines conditions, via un canal (3) dit « ERROR CHANNEL », en multicast. Les données manquantes ne sont en effet pas systématiquement renvoyées, un traitement statistique effectué par le émetteur / serveur (4) aboutit soit à l'émission vers les dispositifs clients (5) desdites données soit, au contraire, à ne rien envoyer. Parmi les paramètres pris en considération à cet égard figure le débit dudit canal (3) d'erreur.
L'application installée à cet effet sur le émetteur / serveur(4) est en pratique chargée :
de récupérer les informations sur les paquets de données perdus, en provenance des dispositifs client (5) ;
de gérer la bande passante allouée au canal (3) « ERROR CHANNEL » ;
de gérer les deux tableaux statistiques concernant le temps réel et le décalé ; et d'appliquer l'algorithme de renvoi des paquets de données
FEC.
Il s'agit en pratique de reconstruire des mémoires tampons ou buffers des dispositifs clients avec les données manquantes et de les renvoyer via le canal d'erreur (3). A cet égard, le temps est un paramètre déterminant, un diagramme temporel illustrant les différente échanges qui sont susceptibles d'exister dans le procédé de l'invention apparaissant en figure 2. L'envoi en temps réel des flux vidéo en multicast via les canaux vidéo (1) dure au mieux di = 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 sur le canal (2) d'acquittement 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 envoyées vers et reçues par le serveur (4) qui constitue les tableaux statistiques en vue d'obtenir les données en défaut. Cela s'effectue sur une durée d2. La somme des deux durées ci-dessus constitue une variable de fonctionnement du système, un paramètre de l'application : au bout de nW ms, nW = dx + d2, le serveur (4) décide de renvoyer ou non le ou les paquets ou blocs manquants, selon la bande passante utilisée par le canal (3) d'erreur. Le renvoi éventuel des données manquantes sur ce dernier canal (3) dure sensiblement autant que pour la première phase, et s'effectue également en multicast.
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 négatif. Elle peut être utilisée pour reconstruire les buffers manquants dans le traitement en temps réel . XI faut alors augmenter le temps de latence, qui être porté à 2 s, voire 2,5 s ou plus .
Un premier tableau statistique pour la gestion des flux vidéo en temps réel est montré en figure 3. Ce premier tableau ne contient que des paquets ou sessions perdus qui ont été initialement envoyés il y a moins de d = nW ms (colonne centrale) . Les modalités de leur insertion dans le tableau sont les suivantes : l'application sur le serveur (4) écoute les messages envoyés par les clients via le canal d'acquittement négatif (2), qui retournent en l'occurrence les N° des sessions perdues. Chacrue session FEC perdue est ajoutée au tableau (Ce tableau est trié de manière décroissante suivant le nombre d'occurrence de l'erreur) de la figure 3 suivant un algorithme qui les traite de la manière suivante :
si la session perdue (colonne de gauche) est définie par des caractéristiques qui apparaissent déjà dans le tableau, 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 (La colonne Date/Time est initialisée avec date/heure/minute/seconde/milli-seconde correspondant à la date 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 d'occurrences, en l'occurrence situées en haut de tableau. Lorsqu'une session est renvoyée, la ligne correspondante est supprimé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 le canal (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 insuffisant), elle est supprimée de ce tableau de la figure 3 et envoyée dans un second tableau statistique (non représenté) . Ce second tableau est similaire au premier, moins la colonne centrale temporelle qui permet la gestion des décalages temporels, le temps n'étant plus un critère de gestion au sens de l'application serveur. C'est cette application qui procède au transfert d'un tableau à l'autre. L'insertion s'y fait à nouveau selon le nombre d'occurrences, qui est une variable de classement possible, la plus immédiate il est vrai .
Ce second tableau (Sachant que le premier tableau est prioritaire pour l'occupation de la bande passante sur la canal «Error Channel ») fait également l'objet de suppressions de lignes, sur la base du paramètre constitué par le débit du canal (3) « ERROR CHANNEL » : si la bande passante encore disponible n'excède pas la limite Qui est allouée à ce canal (3), les sessions FEC dans ce second tableau ayant les plus grandes occurrences sont 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 la session FEC objet d'une ligne n'est pas renvoyée, ladite ligne reste dans le tableau.
Selon l'invention, une optimisation de la gestion des pertes « burst » peut consister en une caractérisation plus précise des données manquantes que ce qui a été évoqué ci-dessus. Ainsi, dans l'hypothèse dont il a é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 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 œuvre, 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.
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 la session FEC en erreur. La solution est plus précise et avantageuse en termes de bande passante sur le canal (3) d'erreur, seules les données vraiment utiles sont renvoyées.
Selon une autre variante encore, une nouvelle information en ajoutée à celles qui font l'objet de la variante précédente : le point d'accès du réseau WIFI, ou plus généralement du réseau employé. Dans ce cas, la diffusion en multicast de la part du serveur (4) sur le canal d'erreur (3) s'effectue à destination de plusieurs adresses multicast, par exemple une adresse multicast par point d'accès ou par groupe de point d'accès. Cette solution, qui voit le serveur (4) retourner les blocs K et N manquants d'une session FEC selon le point d'accès réseau auxquels les dispositifs clients (5) qui ont envoyé un message d'erreur sont rattachés, nécessite de paramétrer les commutateurs du réseau de manière à filtrer les adresses multicast accessibles par les différents points d'accès. Elle optimise de ce fait encore plus la bande passante Que la solution précédente. Pour toutes ces solutions, une variante possible, selon l'invention, consiste à rendre le canal (2) d'acquittement négatif multicast. Dès qu'un 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 multidiffusion, c'est-à-dire également à destination des autres dispositifs clients (5) . 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 (5) vers le serveur (4) s'en trouve allégé. Le message d'erreur ne bénéficie cependant plus d'un accusé de réception de la part du serveur (4), inexistant en multicast, et le problème rencontré n'est plus quantifié, puisque la plupart des dispositifs clients (5) qui en sont victimes ne le font pas savoir.
L'invention ne se limite bien entendu pas aux exemples décrits et expliqués en référence aux figures, mais elle englobe les variantes et versions qui entrent dans la portée des revendications .

Claims

REVENDICATIONS 1. Procédé d'amélioration de la fiabilité 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 communication de type WIFI, les données vidéos étant codé 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) , le flux 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 :
un message d'acquittement négatif (ΝΆΚ) intelligent est envoyé par au moins un dispositif client (5) à au moins un serveur (4) dans le cas où l'algorithme de correction d'erreur (FEC) ne peut reconstituer des données manquantes ;
le serveur construit au moins un premier tableau contenant des informations contenues dans les messages d'acquittement négatif (ΝΆΚ) reçus des dispositifs clients et indiquant les données manquantes, les informations de chaque message d'acquittement négatif caractérisant un défaut de réception au niveau d'au moins un dispositif client (5) ;
lesdites informations sont organisées dans ledit premier tableau selon un premier critère de classement ;
les données manquantes sont renvoyées en émission multicast sur un canal dédié, selon un ordre qui dépend du classement effectué, si le débit alloué disponible du canal d'erreur (3) dédié est suffisant, et dans un laps de temps compris dans une durée prédéterminée.
2. 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 sans fil selon la revendication précédente, caractérisé en ce qu'il y a création d'un second tableau lorsque des données manquantes correspondant à des informations classées dans le premier tableau ne sont pas renvoyées pendant la durée prédéterminée, par transfert à partir du premier tableau d'au moins une fraction des informations dudit premier tableau correspondant aux données manquantes non renvoyées, les informations transférées étant organisées selon le même critère de classement, en vue d'un renvoi ultérieur en multicast 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 fil selon l'une des revendications précédentes, caractérisé en ce que la durée prédéterminée est donnée par une variable nW modifiable dans le serveur.
4. 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 la revendication précédente, caractérisé en ce que 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é en ce qu'une ligne de tableau correspond à un unique défaut de réception, les colonnes étant 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 de la fiabilité et de la qualité de réception de flux de données vidéos sur un réseau sans fil selon la revendication précédente, caractérisée en ce que le critère de classement des lignes est le nombre d'occurrences des informations caractérisant un même défaut de réception.
7. 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 la revendication précédente, caractérisé en ce Que, si des informations caractérisant un défaut de réception reçues d'un message d' acquittement négatif se trouvent déjà dans une ligne du premier tableau, le nombre d'occurrence de cette ligne est incrémenté d'une unité, sinon une ligne est créée avec un nombre d'occurrences égal à un.
8. 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é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 alloué sur le canal d'erreur (3) le permet, la ligne correspondant aux données renvoyées étant supprimée après leur renvoi.
9. 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 5 à 8, caractérisé en ce qu'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.
10. 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 la revendication précédente, caractérisé en ce que l'information contenant les date / heure / minute / seconde / milli-seconde du premier envoi présente dans une ligne apparaissant dans le premier tableau n'est pas transférée au second tableau.
11. 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 2 à 10, caractérisée en ce que les informations sur les données manquantes transférées du premier au second tableau sont supprimées du premier tableau.
12. 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ée en ce eue les informations contenues dans les messages d'acquittement négatif sur les 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é 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 la revendication précédente, caractérisée en ce que des informations additionnelles sur les données manquantes sont prises parmi les informations suivantes :
l'adresse physique (MAC) de l'interface réseau du dispositif client ;
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 sans fil selon la revendication précédente, caractérisée en ce 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 réception de flux de données vidéos sur un réseau local sans fil selon l'une des revendications précédentes, caractérisée en ce que le message d'acquittement négatif intelligent est envoyé en unicast par chaque dispositif client ( 5) .
PCT/FR2016/053293 2015-12-09 2016-12-09 Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos WO2017098177A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562043A FR3045258B1 (fr) 2015-12-09 2015-12-09 Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos
FR1562043 2015-12-09

Publications (1)

Publication Number Publication Date
WO2017098177A1 true WO2017098177A1 (fr) 2017-06-15

Family

ID=55862883

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053293 WO2017098177A1 (fr) 2015-12-09 2016-12-09 Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos

Country Status (2)

Country Link
FR (1) FR3045258B1 (fr)
WO (1) WO2017098177A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116017201A (zh) * 2022-12-06 2023-04-25 远峰科技股份有限公司 基于蓝牙车钥匙系统的无损信息监听方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1722506A1 (fr) * 2005-05-10 2006-11-15 Harris Corporation Méthode et réseau pour la transmission de données en multicast
EP2058970A1 (fr) * 2007-11-06 2009-05-13 Thomson Licensing Procédé, appareil et système d'adaptation du taux de données de multidiffusion

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1722506A1 (fr) * 2005-05-10 2006-11-15 Harris Corporation Méthode et réseau pour la transmission de données en multicast
EP2058970A1 (fr) * 2007-11-06 2009-05-13 Thomson Licensing Procédé, appareil et système d'adaptation du taux de données de multidiffusion

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116017201A (zh) * 2022-12-06 2023-04-25 远峰科技股份有限公司 基于蓝牙车钥匙系统的无损信息监听方法及装置
CN116017201B (zh) * 2022-12-06 2023-07-18 远峰科技股份有限公司 基于蓝牙车钥匙系统的无损信息监听方法及装置

Also Published As

Publication number Publication date
FR3045258B1 (fr) 2017-12-22
FR3045258A1 (fr) 2017-06-16

Similar Documents

Publication Publication Date Title
FR2916600A1 (fr) Procede et dispositif de transmission de donnees
FR2908576A1 (fr) Procede,dispositif et application logicielle d'ordonnancement d'une transmission de paquets d'un flux de donnees
FR2949931A1 (fr) Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants.
EP1074099A1 (fr) Procede de transmission dans un reseau de communication domestique comportant un canal sans fil
CN101286976A (zh) 一种基于数据拆分技术实现p2p流媒体系统的方法
FR2906428A1 (fr) Procede, dispositif et application logicielle pour la transmission de paquets de donnees dands un systeme de communication.
EP1418698A1 (fr) Procédé de transmission de données en mode acquitté
FR2927749A1 (fr) Procede et dispositif de transmission de donnees, notamment video.
FR2863130A1 (fr) Dispositif et procede de preparation de donnees d'emission et produits correspondants
EP2471206B1 (fr) Procédé d'égalisation de la taille des paquets de données par blocs d'un flux multimedia
FR2939994A1 (fr) Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
WO2016083740A1 (fr) Procédé de traitement d'une requête de livraison de données
WO2016162639A1 (fr) Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
WO2019185552A1 (fr) Procede de communication
FR2998125A1 (fr) Procede de transmission de paquets de donnees entre deux modules de communication ainsi que module emetteur et module recepteur
WO2017098177A1 (fr) Procede d'amelioration de la fiabilite de transmission et de la qualite de reception de flux de donnees videos
CA2031039C (fr) Procede et dispositif de transmission numerique d'informations, avec demande automatique de retransmission, ou "arq"
WO2017055771A1 (fr) Procédé d'encodage de flux de données vidéo basées sur des groupements d'images (gop)
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d'un serveur unique
EP3777308A1 (fr) Procede de communication
EP3840335B1 (fr) Réception d'un contenu numérique en mode truque
FR2534753A1 (fr) Systeme d'etablissement de circuits de transmission de donnees a debit constant entre une pluralite de stations
CA2998865C (fr) Procede d'optimisation de transmission de flux de donnees video dans un reseau sans fil
EP2469793B1 (fr) Dispositif de transmission de paquets de données, et procédé, programme d'ordinateur et moyens de stockage correspondants
WO2008096086A2 (fr) Procede de traitement de perte de paquets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16826371

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16826371

Country of ref document: EP

Kind code of ref document: A1