GB2544289B

GB2544289B - Method and device for transmission of video data packets

Info

Publication number: GB2544289B
Application number: GB1519847.6A
Authority: GB
Inventors: Tocze Lionel; Halna Du Fretay Tristan
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-11-10
Filing date: 2015-11-10
Publication date: 2019-09-11
Anticipated expiration: 2035-11-10
Also published as: GB201519847D0; GB2544289A

Description

METHOD AND DEVICE FOR TRANSMISSION OF VIDEO DATA PACKETS

FIELD OFTHE INVENTION

The present invention concerns a method and a device for transmission of video data packets. In particular, it concerns a transmission method with acknowledgment messages and retransmission of data packets received with errors in the context of a limited bandwidth for retransmission and low latency requirements.

BACKGROUND OF THE INVENTION

While not limited to this technical field, the invention has been made in the context of connecting high quality video camera to a display.

For connecting High quality video camera (for example 1080p60 video source) to a display for a live event, wireless connection is a must to avoid hassle due to cable connection. Nevertheless, in that case to keep the rendering quality as high as possible, either a High bandwidth transmission medium (such as 60 GHz wireless system able to sustain 3.8 Gbps) to enable uncompressed video data transmission, either usage of lower bandwidth system (e 802.11 a,g or n able to sustain 54 or 600 Mbps) with H.264 video compression is required.

As wireless system is sensible to perturbation due to environment (such as fading, other wireless transmission), there is a need to use retransmission scheme, based on Automatic Repeat reQuest (ARQ) mechanism in order to optimize the reliability of the transmission.

However, as bandwidth resource is scarce and data transmission requirement are high, retransmission capability are limited and may not enable to handle all erroneous packets retransmission. Once a data transfer connection for video is established only a fixed limited bandwidth is reserved for retransmission. Therefore, some video data packets received with errors and not retransmitted may be missing for correct video rendering, introducing visible artefact up to full loss of video signal. Moreover, for such a live event, latency introduced by the transmission system should be reduced as much as possible. Therefore, opportunities for retransmitting a packet are also limited. This may also impact the video rendering.

SUMMARY OF THE INVENTION

The present invention has been devised to address one or more of the foregoing concerns.

One goal of the invention is to provide a video data transmission/reception method with enhanced selection to choose the most appropriate data packet(s) to retransmit in regard of the application quality requirement. These method aims at monitoring status of the data transmission, and applying different retransmission selection in function of the monitored situation. It could anticipate important data packet transmission, either when monitored situation is good, enhancing transmission reliability of the important packet, either when situation is near a critical situation, in order to avoid complete application failure (example : loss of video signal). The importance should be understood here as the importance of the video data packet for the decoding and rendering process at the receiver.

Another goal of the invention is to manage allocated bandwidth retransmission in the most efficient way, always providing during that retransmission data packet that will improve the quality of the application.

It is also one aim of the invention to implement selection method that is adaptable to several data packet application priority, by configuration of a packet priority identification function.

According to a first aspect of the invention there is provided a method of transmission of video data packets of a video from a transmitter to a receiver by using a transmission frame and a retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets which have not been correctly received by the receiver, the method comprising transmitting to the receiver at least one not yet transmitted video data packet by using the retransmission frame.

Video data packets which have not been correctly received by the receiver may comprise data packets which have not been received and/or data packets which have been received with errors.

In embodiments, the method further comprises transmitting at least one data packet which has not been correctly received, by using the retransmission frame.

In embodiments, the at least one not yet transmitted video data packet is transmitted by using the retransmission frame if at least one transmitted video data packet has not been correctly received after being transmitted to the receiver.

In embodiments, the method comprises selecting video data packets to be transmitted by using the retransmission frame as a function of priority levels associated with the video data packets.

In embodiments, the method comprises selecting video data packets to be transmitted by using the retransmission frame as a function of packet transmission latency of the transmission frame.

In embodiments, if a receiver buffer level of the receiver is less than a threshold value, the video data packets to be transmitted by using the retransmission frame are selected among not yet transmitted video data packets and among data packets which have not been correctly received.

In embodiments, if a receiver buffer level of the receiver is greater than a threshold value, the video data packets to be transmitted by using the retransmission frame are selected further based on a number of data packets which have not been correctly received.

In embodiments, if the number of data packets which have not been correctly received is lower than a given capacity of transmission of the retransmission frame, the video data packets to be transmitted by using the retransmission frame are selected so as to comprise all the video data packets which have not been correctly received and the highest priority video data packets among not yet transmitted video data packets.

In embodiments, if the number of data packets which have not been correctly received is greater than a given capacity of transmission of the retransmission frame, the video data packets to be transmitted by using the retransmission frame are selected only among the video data packets which have not been correctly received.

In embodiments, the highest priority video data packets are packets containing synchronization information.

In embodiments, the retransmission frame has a given capacity of transmission which is less than 10% of a capacity of transmission of the transmission frame.

In embodiments, the transmission frame comprises data packets corresponding to a sequence of video data packets and the retransmission frame is transmitted between transmission frames.

In embodiments, priority levels are determined according to criteria based on the importance of the video data packet in the video decoding process.

In embodiments, said criteria comprise at least one of the following: - whether the video data packet contains position information in the image; - whether the video data packet contains only pixel data information.

In embodiments, the packet transmission latency is determined by comparing a receiver buffer level of the receiver with a threshold value.

In embodiments, the method comprises to test whether the information on a filing level of the receiver buffer indicates a low buffer condition, the information on the filing level of the receiver buffer being the actual filing level and the method comprising comparing the filing level received to a predetermined threshold.

In embodiments, the information on the filing level of the receiver buffer is received within an acknowledgement message configured to indicate if at least one transmitted video data packet has not been correctly received.

According to a second aspect of the invention there is provided a method of reception of video data packets of a video by a receiver from a transmitter by using a transmission frame and a retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets not correctly received by the receiver, the method comprising receiving at least one video data packet not yet transmitted within the transmission frame, transmitted by using the retransmission frame.

Again, video data packets which have not been correctly received by the receiver may comprise data packets which have not been received and/or data packets which have been received with errors.

In embodiments, the method further comprises sending back to the transmitter an acknowledgement message indicating that at least one transmitted video data packet has not been correctly received.

In embodiments, the method further comprises monitoring a filing level of a receiver buffer of the receiver and sending back to the transmitter an information on the filing level of the receiver buffer.

In embodiments, the information is the result of the comparison of the filing level of the receiver buffer to a predetermined threshold.

According to a third aspect of the invention there is provided a transmitter device for transmission of video data packets of a video to a receiver by using a transmission frame and a retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets which have not been correctly received by the receiver, the device comprising a transmitting module configured for transmitting to the receiver at least one not yet transmitted video data packet by using the retransmission frame.

In embodiments, the transmitting module is configured for transmitting at least one data packet which has not been correctly received by using the retransmission frame.

In embodiments, the transmitting module is configured for transmitting at least one not yet transmitted video data packet by using the retransmission frame if at least one transmitted video data packet has not been correctly received after being transmitted to the receiver.

In embodiments, the transmitter device comprises a selecting module configured for selecting, as a function of priority levels associated with the video data packets, video data packets to be transmitted by using the retransmission frame.

In embodiments, the selecting module is configured for selecting, as a function of packet transmission latency of the transmission frame, video data packets to be transmitted by using the retransmission frame.

In embodiments, the selecting module is configured for selecting, as a function of a comparison of the number of data packets which have not been correctly received with a given capacity of transmission of the retransmission frame, video data packets to be transmitted by using the retransmission frame.

According to a fourth aspect of the invention there is provided a receiver device for reception of video data packets of a video from a transmitter by using a transmission frame and a retransmission frame, the retransmission frame being usually reserved for retransmitting video data packets not correctly received by the receiver, the device comprising a receiving module configured for receiving at least one video data packet not yet transmitted within the transmission frame, transmitted by using the retransmission frame.

In embodiments, the receiver device further comprises a verification module configured to determine if at least one transmitted video data packet has not been correctly received, and to send back to the transmitter an acknowledgement message indicating that at least one transmitted video data packet has not been correctly received.

In embodiments, the receiver device further comprises a filing level monitoring module configured to monitor a filing level of a receiver buffer of the receiver, and to send back to the transmitter an information on the filing level of the receiver buffer.

In embodiments, the filing level monitoring module generates the information by comparing the filing level of the receiver buffer with a predetermined threshold.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium, and in particular a suitable tangible carrier medium or suitable transient carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 illustrates an example of system, where the invention may be used;

Figure 2 is a functional block diagram of wireless external adapters according to an example of the invention;

Figures 3a and 3b illustrate an example of a typical sequence of transmission for supporting video transmission;

Figure 4 illustrates main functions to support selection method in an example of the invention;

Figure 5 illustrates an algorithm performed on video receiver adapter in an example ofthe invention;

Figure 6a illustrates an algorithm performed on video transmitter for the transmission in an example of the invention;

Figure 6b illustrates a general algorithm performed on video transmitter for selecting the most appropriate packet;

Figure 7 illustrates the selection method according to an example of the invention, where latency estimation value is performed based on information provided by receiver;

Figure 8 is a schematic block diagram of a computing device for implementation of one or more embodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the context of video transmission over the air as contemplated, the channel of transmission is a wireless channel used to transmit in real time data representing the video, typically under the form of a stream of data packets. We consider that the transmission channel provides a bandwidth at least sufficient for the transmission of the video in real time. This means that the available bandwidth of the transmission channel is greater than the minimum bandwidth required for the transmission. This means that the transmission channel could be analysed as two different channels. A first channel corresponds to the bandwidth required for the transmission of the video data packets, while the second channel corresponds to the reminder of available bandwidth. This second channel can therefore be used for retransmission of packets received with errors according to the well-known ARQ scheme and will be called in the following the retransmission channel. According to the ARQ scheme, the receiver sends back to the transmitter some acknowledgment messages to indicate the data packets received with errors. The transmitter uses the information of the acknowledgment message to retransmit video data packets received with errors through the retransmission channel.

At the receiver, the video data packets are used to render the video according to a decoding process depending on the kind of encoding used at the transmitter. It appears that video data packets do not have the same importance regarding the decoding process depending on the kind of data they carry on.

This is true whatever the kind of encoding being actually used. Even considering raw video encoding without any kind of compression, the importance of video data packets varies. For example, some video data packets may contain some synchronization information, meaning that the loss of the video data packets leads to the loss of all video data packets until receiving the next one also containing synchronization information. While the loss of a video data packet containing only pixel information leads to the loss of only a little part of an image and will have a small impact on the quality of the rendered video. It is therefore possible to set up some priority level which will be attributed to video data packets according to their importance at decoding, in other words to the impact of the loss of the packet to the rendered video. The actual number of priority levels and their attribution depends on the actual encoding used for the transmission.

In the case where few or no video data packets are transmitted with errors, the full available bandwidth of the retransmission channel may not be used. It remains available bandwidth in the retransmission channel which is unused. According to a first embodiment of the invention, this available bandwidth is used to early transmit some video data packets that have not yet been transmitted. This may be seen as a retransmission for the sake of precaution. It is worth noting that this early transmission in the retransmission of a video data packet does not prevent the regular transmission of the same packet using the regular transmission channel later on according to the transmission scheme. By doing so, if the regular transmission of the packet fails, a retransmitted version of the packet is already available at the receiver for the decoding.

The video data packets chosen for early transmission comes from a set of video data packets at the transmitter that have not yet been transmitted but are ready for transmission. By using the priority level attributed to the video data packets, it is possible to select for early transmission, the video data packets of highest priority. Accordingly, we safeguard the transmission of the most important video data packets for the decoding process.

Especially in the context of low latency transmission, it is important to detect latency issue in order to prevent a break in the decoding. As an example, a break in the decoding may occur when the filing level of the receiver input buffer gets empty. In order to prevent the receiver input buffer to get empty, it is safe to keep its filing level above a low threshold. In addition to monitoring the good reception of incoming video data packets, the receiver can monitor the filing level of the receiver input buffer. When the filing level of the receiver input buffer gets lower than the predetermined threshold, the system raises a low buffer condition. It is worth noting that the comparison of the filing level of the receiver input buffer and the threshold may be done in the receiver or in the transmitter. In the first case the receiver sends back the result of the comparison as information on the filing level of the buffer to the transmitter. In the second case the receiver sends back the actual filing level of the buffer as information on the filing level of the buffer to the transmitter. The information on the filing level of the receiver input buffer may be sent back to the transmitter within the acknowledgment message.

Under a low buffer condition, it may be more advantageous to privilege the transmission of the highest priority video packets available instead of retransmitting low priority video data packets received with errors. According to an embodiment of the invention, it is proposed that, under low buffer condition, the retransmission channel (denoted hereafter also as ’’retransmission frame”) is used for the transmission of the highest priority video data packets among the not yet transmitted packets and the packets transmitted with errors.

Figure 1 illustrates an example of system, where the invention may be used.

The system 100 is a wireless point to point communication system composed of two devices. Device 105 is a video source device, such as a PC, a SetTopBox or a HD camcorder, able to provide 1080p60 (1920*1080) video format. Device 105 is either connected through video connection 135 (H DM I (RTM) or DisplayPort(RTM)) to a wireless adapter 125 in order to communicate in the wireless network 100 using for example standard interface such as WiGig(RTM), 802.11 ad or specific 60 GHz wireless interface, either wireless adapter is integrated in device 105, providing wireless connection to the display. Bandwidth requirement for raw video transmission of 1080p60 video format is therefore 2.98 Gigabit per second (Gbps), corresponding to (1920*1080*60*24), where 24 is the number of bits to represent the 3 main colours of the video.

Device 110 is a display device, such as video-projector or Television set. This device is either connected through video connection 130 (H DM I (RTM) or DisplayPort(RTM)) to a wireless adapter 120 in order to communicate with the wireless network using for example standard interface such as WiGig(RTM), 802.11 ad or specific 60 GHz wireless interface, either wireless adapter is integrated in device 110, providing wireless connection with video source device. The display device is able to support a standard video format up to 1920*1080 pixels at 60 frames per second (fps). 60 GHz Wireless connection of the system 100 is able to sustain a maximum global throughput up to 3.8 Gbps data rate (using 16QAM modulation). In such a wireless communication system, proportion of bandwidth available for retransmission is therefore limited to maximum (3.8-2.98)/3.8 * 100 = 21 %. Taking into account protocol overhead due to wireless mechanism to maintain node synchronised or to transmit data such as interframe gap, FEC, this ratio is further reduced and is in the range of 5 to 10%. Moreover, since the system aims at providing a low latency transmission scheme, opportunities for retransmitting erroneous data packet before dropping these packets are restricted. Also such opportunities should be used for transmission of the most important packet when the system is about to reach a critical state and transmission problems occur. Such transmission problem may induce a delay in the transmission latency and therefore a time lag for important packets. In such a case the packet arrives too late and cannot be considered any more. This may happen for example for packets containing synchronisation information.

It should be noted that the method could apply to video of higher resolution such as 4k2kp30 (3840*2160 pixels at 30 fps). In that case, wireless adapter may use two 60 Ghz channels and aggregate their bandwidth to provide sufficient data throughput and dispatch video data on the two links available. In each link, method described hereafter may apply as each link should support a data bandwidth traffic of (3840*2160*24*30)/2, meanings 2.98 Gbps per link). Moreover, even though the example of a communication between a PC for display on a video projector or on a TV set has been described, it may also apply to transmission of non-compressed video between an X-Ray capture device and a monitoring display. For example such a transmission may be performed for diagnosis purposes. The transmission may also be performed for a Mixed Reality system, where transmission from the initial captured video between the device and the processing device, and then the transmission of the enhanced video after processing to displaying device should be performed with a low latency requirement.

Figure 2 shows the functional block diagram of wireless external adapters 120 or 125 according to an example of the invention. These adapters are connected either to display device, either to source device (or integrated in these devices) as illustrated on Figure 1.

An adapter comprises a main controller 201, and at least one physical layer unit 211, able to provide 60 GHz wireless transmission/reception communication means, following or not standard implementation such as WiGig(RTM) (or 802.11 ad).

It also comprises a video output 239 enabling the connection of a display device such as video projector 110, and a video input 240 enabling connection of a video source device 105, as for example an HD camcorder or a PC, through HDMI(RTM) connection.

The main controller 201 comprises a Random Access Memory (denoted RAM) 233, and an Electronically-Erasable Programmable Read-Only Memory (denoted EEPROM) 232, that will store program implementing algorithms described in Figures 5, 6 or 7.

The main controller 201 also comprises a micro-controller or Central Processing Unit (denoted CPU) 231, a medium access controller (denoted MAC) 238, and a video application processing controller 235. CPU 231, MAC 238, video application processing controller 235 exchange control information for configuration via a communication bus 244, on which is also connected RAM 233, and EEPROM 232. CPU 231 controls the overall operation of the adapter as it is capable of executing, from the memory RAM 233, instructions pertaining to a computer program, once these instructions have been loaded from the memory EEPROM 232.

Adapter 125, with the help of video application processing unit 235 will receive video signal connected to the video input 240 (HDMI(RTM) for example), as for example a 1080p60 video. This video will then be divided in data packets of fixed size, that are provided to wireless Medium Access Controller 238 through data interface 237 for transmission on wireless medium. As explained in regards of Figure 3a and 3b, data packet format will enable to identify which part of the video signal the data it contains is issued from.

For example, a packet may contain video synchronisation information, such as start of a new image from the top left corner or start of a new packet from a specific line position. For a 60 fps image, new image packet is present once every 16.6 ms period. This packet enables to refresh with correct frequency the display. Some packets are data only packets that may be for some of them padded to fit fixed size of the packet.

Adapter 120, with the help of video application processing unit 235 will be able to generate for the video-projector a Video-output signal on interface 239, by reception of data packets from MAC 238 through path 236. Using data packet format information as described later in Figure 3, video application processing unit, will be able to identify position on the display where the data it contains should be displayed and to identify when new image should be started, to reproduce image at its original frequency (from new image packet). MAC 238 is in charge of controlling the emission and reception of MAC frames conveying control data and/or video data, on the 60 Ghz PHY module 211. Control data will be used for protocol management such as capacity link determination or transmission scheme determination and announcement between the devices of the system. They are also used to keep devices synchronised on a regular basis (for example by beacon transmission every 2 ms) and to adjust antenna direction for keeping devices in connection.

For data communications between devices, the MAC 238 can rely to a physical layer unit 211. The physical layer unit is for example a wireless unit, operating in the 60 GHz band, with a typical useful throughput in the order of up to 3.8 Gbps, for best transmission condition. Moreover, MAC will enable the communication between the devices in the system by using Time Division Multiple Access (TDMA) allocation scheme.

The wireless type physical layer unit 211 embeds a modem, a radio module and antennas. The radio module is responsible for processing a signal output by the modem before it is sent out by means of the antenna. For example, the processing can be done by frequency transposition and power amplification processes. Conversely, the radio module is also responsible for processing a signal received by the antenna before it is provided to the modem.

The modem is responsible for modulating and demodulating the digital data exchanged with the radio module. For instance, the modulation and demodulation scheme applied is of Orthogonal Frequency-Division Multiplexing (OFDM) type. Antennas, for both transmission and reception, can be set either with quasi omni-directional pattern (For control data sharing for example), either with quasi omni-directional or directional radiation pattern antennas, for video data transmission, enabling either broadcast of common video data, either long range connection and better spatial reuse. Radio module also provides means to measure RSSI (Radio Signal Strength Indication) to identify positions of antennas that enable the best signal reception.

Figures 3a and 3b describe an example of a typical sequence of transmission for supporting video transmission between adapters 120 and 125.

Figure 3a describes the periodic transmission sequence. This transmission sequence contains a beacon period 305, enabling adapter 120 to initiate and manage wireless network system. This beacon is regularly transmitted (for example each 2 ms) by adapter 120 and enables to initiate association and data connection setup, using state of the art protocol technique. Beacon duration period is in our example 25 ps.

Then transmission sequence also contains several data stream transmission sequences 310 (here 4), detailed in Figure 3b, that enables in our example raw video data transmission with a limited retransmission capacity (less than 10 %). Each of this transmission sequence 310 is of duration 492 ps, including interframe gap duration to enable device to prepare for each transmission/reception of data transmission sequence.

Figure 3b, which describes data transmission sequence 310, is composed of 3 frames. A data block frame 320, is transmitted from adapter 125 to adapter 120, and contains of a frame header field 325, which may contain information such as Frame Id, Type of frame (Here “Data_Frame" type) and length of frame (in number of data packets “Nb_Data" for example). This frame header is added before transmission by MAC 238. When receiving this type of frame, adapter 120 should then reply by a feedback frame 340. A data block frame 320 also contains “Nb_Data" data packets 330. Each of the data packet is composed of a: - data packet Header 331, that contains information to identify to which part of the video (location in image, image number) the data packet is issued and should be render on display device 110. It also contain fields to identify type of data packet found in the data payload field 332, such as (in their ascending order of importance): o “Video_Only_Packef’ : for packet that contains only video pixel information. o "Pos_Adjust_Packet” : for packet that contains video pixel information and additional position information to recover to which part the video data is issued. o “ Synch ro_Packef’ : for packet that contains video pixel information and synchronization packet information, which enables video synchronization signal reconstruction. - the data payload field 332. - A checksum field 333, enabling to check integrity of data packet 330, added by MAC 238.

For example, for support of throughput for 1080p video transmission on a single 60 GHz PHY, data packet is of size 8224 bytes, where useful data payload field is 8192 bytes. Each data block is composed of “Nb_Data” = 24 data packets. Therefore, the 4 periods 320, during communication exchange 300 (which duration is 2 ms), enables to transmit up to (4*24*8192*8/0.002) = 3.15 Gbps, which is sufficient to sustain the 2.98 Gbps of the video application.

Moreover, with a 60 GHz wireless throughput of 3.8 Gbps, transmission of a data packet of 8224 bytes takes 17 ps. Duration of data block frame 320 is then (24*17+18)=426 ps, where 18ps is including interframe gap and transmission of header 325.

In such a system, a “Synchro_Packef’ is present each 1/60 s, meanings each 32 data block frames (around 32*24=768 data packets) and a “Pos_Adjust_Packet” (composed of 16 lines) is present each 12 data packets.

It should be noted that other type of packet such as Audio data packet may be taken into account regarding their importance for audio/video system rendering.

Order of priority will be later used to select which packet should be retransmitted. This order of priority is function of the importance of the packet to reproduce the transmitted signal. Here, when missing “Video_Only_Packef’ data blocks, receiver is able to introduce blank pixels, creating little, quasi no visible artifact on video display. When missing “Pos_Adjust_Packet”, video receiving application is not able to know where the pixels data should be reproduced, therefore impacting up to several lines (artifact is much more visible as it is on a bigger area). Then, last missing of “Synchro_Packef’, is much more impacting as synchronization rhythm to update video display is possibly lost. A feedback frame 340 is then transmitted from adapter 120 to adapter 125, and composed of a frame header field 341, which may contain information such as Frame Id, type of frame (Here “ACK_Frame" type) and length of frame.

This frame header is added before transmission by MAC 238. The feedback frame 340 also comprises a feedback information field 345, reporting status of the reception from the previous data block frame. This feedback frame comprises “Nb_Data" number of status information 346 that reports correct or incorrect reception of each data packet of data blocks 320. It also typically comprises an information on the filing level of the receiver input buffer 347, which represents the quantity of data blocks the receiver is in possession for video rendering.

For example, duration of feedback frame 340 is here supposed to be 28 ps (including interframe gap and transmission of header 325). A limited data block retransmission frame 350, fixed by allocated Nb_ReTx_Budget (here supposed 1), is then transmitted from adapter 125 to adapter 120. It comprises: - A frame header field 355, which may contain information such as Frame Id, the type of frame (Here “Retx_Frame" type) and length of frame. This frame header is added before transmission by MAC 238. When receiving this type of frame, adapter 120 knows that current data transmission sequence 310 is finished. - Nb_ReTx_Budget number of data packet 330, as described in data block frame 320.

For example, with remaining time from data transmission sequence 310 for retransmission frame equals to (492 - 426 - 28) = 38 ps, once interframe gap is subtracted, data packet retransmission is limited to 1 packet. Therefore, in this system, retransmission capacity is less than 5% (exactly 1/24). Moreover, in order to maintain a low latency transmission time (ex :1ms), it makes it possible to retransmit packet(s) only once before being dropped to take into account new data packet.

When errors occur, such limited retransmission bandwidth requires selecting accurately data packet to improve or safeguard video rendering.

Figure 4 describes main functions to support selection method in an example of the invention. These functions are typically performed by MAC 238 of the adapter 120 or 125.

Block 400 and 405 are memories, used in a FIFO style, storing data packets provided by application 235. Memory 400 stores “Nb_Data" data packets transmitted in the data block frame 320 of the current data transmission sequence 310 used by TX data function 410.

Memory 405 stores other data packets to be transmitted on further following transmission sequence, including data packets provided by application between the start of current data transmission sequence 310 and the end of the reception of the feedback frame 340. These other data packets are the data packets already obtained by the transmitter but not yet transmitted.

After each transmission of a data block frame 320, memory 400 corresponds to buffer data available for retransmission, which is used for state of the art ACK retransmission algorithm. Memory 405 provides means to store data block not yet transmitted but that, in regards of their importance and the limited retransmission capability of the system, may be selected as payload for limited data block retransmission frame 350. Before each new data transmission sequence, memory 400 is updated with the first “Nb_Data" stored in memory 405, which are the data blocks of the next data block frame 320.

Block 420 provides function to identify data packet priority. It manages two lists of data packet priority “Prio_Tx_Lisf’ and “Prio_Other_Lisf’, which will contain up to Nb_ReTx_Budget elements. Each element of the list will store the priority of the data block and its location in the memory. “Prio_Tx_Lisf’ is updated at the same time as memory 400 and identify data packet priority of the “Nb_Data” data packets of each data block frame 320. It contains the highest priority data packets already transmitted and available for retransmission in a number corresponding to the retransmission frame budget. “Prio_Other_Lisf’ is also updated when memory 400 is updated, taken into account that “Nb_Data" are removed from the memory 405, and is modified each time a new data packet is written into memory 405. Update of the list is performed by checking the type of data packet contained in the header information 331 of each data packet now stored in memory and keep track of the most important(s) priority packets. It contains the highest priority data packets not yet transmitted and available for transmission in a number corresponding to the retransmission frame budget.

For example, supposing “Nb_Data" = 10, Nb_ReTx_Budget = 2 and using packet type “Video_Only_Packef’ as PrioO (Low priority), “Pos_Adjust_Packet” as Priol (Middle priority) and “Synchro_Packet” as Prio2 (High priority) as defined previously, a data block frame: - composed of 10 PrioO data packet will result in an “Prio_Tx_Lisf’ empty list, as no packet is of higher priority than another. - composed of 8 PrioO data packet, 1 Priol data packet in memory index 2, and 1 Prio 2 data packet in memory index 6 will result in an “Prio_Tx_Lisf’ of 2 elements {(Prio2,index 6),(Priol, index2)}. - composed of 6 PrioO data packet, 2 Priol data packet in memory index 2 and 4, and 2 Prio2 data packet in memory index 1 and 9 will result in an “Prio_Tx_Lisf’ of 2 elements {(Prio2,index 1 ),(Prio2, index9)}.

More generally, Packet Priority identification block 420 is configurable to adapt to data priority application.

Block 430 provides an ACK analyser function, which after reception of a feedback frame 340 from received data block 460, uses the “Nb_Data" number of status information 346 to identify data packet that encounters transmission problem. When status information for the data packet / reports incorrect reception, the data packet of index / in memory 400 is requested to be sent again. The block 430 after each ACK analysis, creates a “ReTx_Requesf’ list of “Nb_Retx_Elf’ (where number of elements is at most equals to “Nb_Data"), storing index of packet that is requested for retransmission. When a data block frame 320 is received with no error, then this list is empty and “Nb_Retx_Elf’=Q. ACK analyser may also extract from feedback frame 340 additional information 347 regarding receiver adapter 120 butter reception level. This buffer level gives an idea of the capability of the receiver to continue to recreate video output signal, in order to provide continuous display without interruption.

Block 440 provides selection of the “Nb_ReTx_Budget” data packet (s) transmitted in the retransmission frame 350 of the current data transmission sequence 310 used by ReTx data function 450.

The block implements algorithm of Figure 6b or Figure 7 as will be described later, in order to select the most appropriate data packet(s) from memory 400 or 405, taking into account packet priority information from 420 and retransmission request from 430. This selection aims at keeping synchronization and maintaining continuous video with lowest degradation as possible.

Block 470 provides data packet reception checking function. For each data packet 330 received in a data block frame 320, it performs CRC calculation on all data in header 331 and payload 332, and compares it with the received CRC field 333. In simple case, we suppose that if CRC calculation and CRC field are different, packet (of number /) is considered as erroneous and its data block status is set as incorrect in the (/th index) corresponding field 346 of the feedback frame.

It should be noted that such CRC is for illustration only. More efficient FEC could be used in order to recover data when few errors occurred, reducing by the way the retransmission need. When data packet is correct, it is then written in a data packet reception buffer 490, to be provided to the application.

Finally, block 480 provides function to monitor the reception buffer level of the receiving adapter 120. Once application is started, it could then count the number of data packets that the buffer 490 contains. Measurement of this level is then used to create buffer level reception information 347, included in the feedback frame 340. This information may be either the number of data blocks itself, either the result of comparison with a critical threshold value (1 if superior to threshold, 0 if equal or less for example).

Figure 5 describes algorithm performed on video receiver adapter 120 in an example of the invention. This algorithm aims at transmitting feedback frame 340. It should be noted that for simplicity of the explanation algorithm does not explain treatment performed on beacon frame, dealing mainly with network synchronisation and setup of connection as it is well known technics. It focus on treatment of frame inside data transmission sequence 310.

In step 500, adapter is waiting for a frame reception indication from PHY module 211.

Once received, a first frame identification operation 505, which consists in checking the content ofthe type of frame information of frame header 325 (or 355) is performed. For a video receiver adapter 120, the two values possible are “Data_Frame” or “Retx_Frame”.

When frame is of type “Data Frame", step 510 extracts “Nb_Data" information from header 325. This information enables to perform the correct number of data packet status check and to identify the number of status information required in the feedback frame. At this step, an internal counter nb_check_performed is set to value 0.

Then step 520 verifies if CRC checking is done for all data packets. For that purpose, it will compare if the internal counter nb_check_performed is less than “Nb_Data" value.

If this is the case, using CRC checker 470, integrity of the (nb_check_performed +1 )th data packet received is checked in step 530. For each check, result of the data block status is stored (step 540) in the corresponding index of the internal table DP_Status (for data packet status), composed of “Nb_Data" index. As example, it may store a single value 0 if data packet CRC check failed, identifying data packet that encounters errors during the wireless transmission process. Otherwise, value is set to 1. After storage of the status information, the nb_check_performed counter is incremented.

When nb_check_performed is equal to “Nb_Data", the result of check 520 is positive. Then, receiver adapter may retrieve additional information (550), such as the one provided by buffer level mastering block 480 (further named “Rx_Buffer_Levet’). In order to take into account correct data packet received in the last “Data_Frame” transmission, the “Rx_Buffer_Levet’ is increased by the number of correct data packet identified in the DP_Status table.

Step 560 then performs operation to format the data in the feedback frame 340, such as: - add of the header 341 with the correct type of frame (“ACK_Frame"), - create status informations 346, by parsing in their index order the “Nb_Data" element of the DP_Status table, - add the content of the “Rx_Buffer_Lever information in the additional information packet 347.

Once format is done, packet is then transferred to PHY for further transmission on the wireless medium. It should be noted that status information 346 corresponds to state of the art block acknowledgement.

Step 570 is then performed to provide correct data packet(s) received in the last “Data_Frame” transmission to Video application layer. As stated in step 550, this packet is known by the DP_Status table. If the DP_Status of index i is set to 1, the ith data packet received is then copy to the buffer 490. Other packets are discarded.

When the result of test 505 determines that the frame is of type “ReTx_Frame", step 580 (as step 530) used CRC Checker to verify if the data packet received is correct. If not, then packet is discarded and process is finished (590), otherwise packet is provided to application layer in step 570. It should be noted that for the simplicity of description, here the “ReTx_Frame" is supposed to contain only one data packet. If this frame contains more than one data packet, same type of operation as described in 510 to 540 should be performed in place of single step 580.

Figure 6a describes the algorithm performed on video transmitter for the transmission in an example of the invention. It may be implemented by the adapter 125, in order to perform data packet transmission and select data packet for limited data block retransmission frame 350.

Steps 600 to 670 are performed for each data transmission sequence 310

Step 600 performs identification and classification of data packets in regards of their priority, prior to the start of transmission. This function as explained previously is performed by block 420, and provides two lists “Prio_Tx_Lisf’ (for data packet in memory 400) and “Prio_Other_List” (for data packet in memory 405). “Prio_Tx_Lisf’ corresponds to data that are currently transmitted. “Prio_Other_Lisf’ corresponds at that time to data waiting for transmission.

In step 610, using the “Nb_Data" data packets stored in memory 400, transmission of data block frame 320 is done by adding the header 325 with the correct type of frame (“Data_Frame"), and length of frame (set to “Nb_Data"), copying the “Nb_Data” data packets in payload fields 330 in their order from memory, and providing all this data to PHY for transmission on wireless medium.

From that moment, device adapter 125 is waiting for two possible events. One is the reception of a feedback frame 340 from PHY, the other is the arrival of new data packet from application 235.

Feedback frame reception corresponds to a positive ACK reception in checking step 620. If this event is not present, checking step 630 verifies if an arrival of new data packet from video application occurred (Event is a writing operation in memory 405). In case of negative test 630, these two steps are repeated until encountering one of the two events.

In case of positive check 630, a new data packet should be analysed by algorithm. Step 640 by the way of block 420 proceeds to identification of priority of this data packet added to memory 405. The packet is added to “Prio_Other_Lisf’ in following cases: o “Prio_Other_Lisf’ is not full and data packet is of level priority, either Priol or Prio2, o “Prio_Other_Lisf’ is full, but priority of new data packet is higher than priority of one of the list member. Then, it takes that place.

This process enables to take into account data packets that were not present at the transmission time, but could improve video rendering if used in retransmission frame 350. When analyse is done, device adapter 125 is still waiting for the two possible events and then step 620 is performed once again.

When PHY provides a feedback frame, check 620 is then positive and will stop waiting events loop. From now on, device adapter will perform its data packet selection for the retransmission frame 350.

In step 650, analysis of the feedback frame content is performed by block 430. It results (as explains before) in a “ReTx_Request” list of “Nb_Retx_Elt” elements, that contains information about data packet(s) from memory 400 that encounters error on transmission. Moreover, additional information is extracted. Here “Rx_Buffer_Lever information is read and stored in internal memory 233 for further usage.

Then step 660, which is further described in the general algorithm of Figure 6b (and more specifically detailed on a specific embodiment in regards of Figure 7), proceeds to selection of “Nb_ReTx_Budget” data packet(s) for retransmission among all data packets stored either in current transmission memory 400 and all data packets in memory 405 that includes packets received during transmission.

Once selection is done, step 670 using the “Nb_ReTx_Budgef’ data packet(s) identified in selection step 660, performs transmission of data retransmission frame 350 by: o adding of the header 355 with the correct type of frame (“ReTx_Frame”), and length of frame (set to “Nb_ReTx_Budget”, here supposed 1). o copying the “Nb_ReTx_Budgef’ data packets in payload fields from their location in memory 400 or 405. o providing all this data to PHY for transmission on wireless medium.

It may be noted that loss of any frame is handled by classical timeout mechanism, and treatment are not represented for clarity. For example, a loss of feedback frame will result in identifying in step 650 of the current algorithm, all “Nb_Data" packets of the data block frame as erroneous.

Figure 6b is general algorithm performed on video transmitter for selecting the most appropriate packet to retransmit. This algorithm takes into account retransmission request as received through ACK feedback frame 340 and the latency for the transmission of the packet.

In a first step 675, it is checked whether a retransmission request is received after the last data block frame transmission 320.

In case no retransmission is necessary, step 680 is performed to take advantage of the reserved limited retransmission bandwidth for anticipating transmission of the most important and not yet transmitted data packet. As mentioned previously, the retransmission frame has a capacity of transmission which is, for example, in the range of 5 to 10% of a capacity of transmission of the transmission frame.

Such limited capacity of transmission of the retransmission frame is conventionally fully dedicated to the use of retransmitting video data packets which have been received with errors by the receiver. However, the inventors have observed that the bandwidth occupied by retransmission of erroneous transmitted data packets is not necessarily equal to the whole capacity of transmission ofthe retransmission frame, in particular when few errors happen.

According to embodiments of the invention (e.g. the one which is described by reference Figure 7 for example), the rest of the capacity of transmission of the retransmission frame may be utilised for sending not yet transmitted data packets, for example not yet transmitted data packets which have highest priority levels, for example in order to improve the display rendering quality or at least to maintain a minimal display rendering as well as to allow the future transmission of data packets to have more bandwidth (capacity of transmission) to use.

Still according to embodiments of the invention, the maximum bandwidth that may be occupied by retransmission of erroneous transmitted data packets is determined as a function of a loss rate of transmitted data packets and/or the occurrence of a critical transmission latency and the capacity of transmission of the retransmission frame itself.

When retransmission is required, it is checked in step 685 the criticality of the transmission latency. In this step, a value is estimated of the latency that is introduced on the transmission of data packet. It is also identified if it reaches a critical state. Latency is critical when loss of data packets detected that is important and that retransmitting all non-priority data packet will add time lag to the delivery of the most important packet. This may potentially introduce loss of synchronisation due to latency transmission that is too high.

When latency is critical, then step 690 is performed and the highest priority data is selected. It may be selected along data not yet transmitted in place of the requested retransmission data in order to use the retransmission frame. This makes it possible to improve its time delivery to the receiver and to reduce the risk of visible effect on video rendering. This is of particular importance for packets containing synchronisation information that, when lost, may generate a total break of the video.

In case latency is not critical, then during step 695, classical retransmission policy such as full retransmission as requested or selective retransmission inside reported packet errors are performed. These steps are described with reference to Figure 7.

After steps 680, 690 or 695, the algorithm performs retransmission of selected packet during step 670.

Figure 7 illustrates the selection method according to an example of the invention, where latency estimation information is provided by specific information retrieved in the receiver as explained from Figure 5 - step 550.

In a step 700, algorithm check if any errors have been encountered during data block frame 320 transmission. This test uses the “Nb_Retx_Elt” number provided by ACK analyser block.

If this number value is 0, no data packet is erroneous. In that case, during operation 710, the data packet selection chooses “Nb_ReTx_Budgef’ data packet(s) inside packets stored in memory 405. This selection is further performed using “Prio_Other_Lisf’, to select the highest priority data packets among not yet transmitted data packets.

Here, this operation enables to anticipate transmission of important data packets, which will be later transmitted in a data block frame 320. Therefore, it enhances the reliability transmission of this packet (by providing time diversity transmission) and at the same time the video rendering behavior. Moreover, it enables to always use fixed allocated retransmission frame without bandwidth loss. When “Prio_Other_List” is empty, the first “Nb_ReTx_Budget” data packet(s) in memory are selected.

If in step 700, there are some errors, then step 720 is processed. In that step, additional information of “Rx_Buffer_Levet’ is compared with a threshold value, representing critical criteria for guarantee of a low latency transmission scheme. The threshold may correspond in our example to at least a buffer size of “Nb_Retx_Budget + Nb_Data” and less than “Nb_Data_Latency”, where the: o “Nb_Retx_Budget + Nb_Data” corresponds to the minimal budget corresponding to a transmission period, here 25 data packets. o “Nb_Data_Latency” corresponds to the number of packet introduced by transmission scheme latency. For example, for 1080p transmission scheme, a 1 ms latency scheme represents approximatively 50 data packets.

For example, the margin is 10% and the “Rx Buffer Level” threshold is 28 data packets.

If in step 720, “Rx_Buffer_Levet’ is below the threshold, meanings that device receiver may encounter some buffering issues. Then algorithm will select the most important video data packet(s) in all data that can be transmitted in the retransmission frame 350, in order to maintain a minimal display rendering (step 730). Therefore, it will use information from the “Prio_Other_Data" list, from the “Prio_Tx_Lisr and from the “ReTx_Requesf’ list to choose the more relevant data packets. These more relevant packets are the video data packets among not yet transmitted video data packets and video data packets received with errors. For example, for a “Nb_ReTx_Budgef’ equals to 1, it will select: o Data packet in memory 400 if the highest priority packet is found in “ReTx_Requesr and in the “Prio_Tx_Lisf’, even if “Prio_Other_Data" contains same priority data packet. o Data packet in memory 405 if the highest priority packet is found in the “Prio_Other_Data" list, even if any “ReTx_Requesf’ exists for lower priority data in “Prio_Tx_Lis(’. In that way, it doesn’t take into account the ARQ but nevertheless provide the most important data packet in regards ofthe application. Moreover, it may select a packet that when starting transmission was not already present in MAC block 238 (added by process of steps 620 to 640).

If “Nb_ReTx_Budgef’ is greater than one, the selection may either select the “Nb_ReTx_Budgef’ data packets in memory 400, either in memory 405, either in both memories.

In case test of step 720 is positive, meanings “Rx_Buffer_Lever is above the threshold, then device adapter is not in a critical situation in regards of latency. In that case, another checking step 740 is performed to verify if the reported “Nb_Retx_Elf’ of transmission errors on the previous data block transmission 320 is higher than the “Nb_ReTx_Budgef’ allocated for retransmission frame 350.

If test is negative, then step 750 is performed.

In case “Nb_ReTx_Budget” equals 1, it selects data packet as reported by the “ReTx_Requesf’ list. It therefore corresponds to a traditional ARQ, where policy is to retransmit packet as requested by the receiver.

In case “Nb_ReTx_Budgef’ is higher than 1, two cases are possible.

Either “Nb_Retx_Elf’ =“Nb_ReTx_Budgef’, then all reported erroneous data packets are retransmitted. Either “Nb_Retx_Elf’ < “Nb_ReTx_Budgef’, therefore all reported erroneous data packet(s) are retransmitted as before, but additional data packet(s) could be selected in memory 405. The additional data packet(s) is (are) selected from the highest priority data packet(s) using the “Prio_Other_Data" list. As for step 710, it enables to enhanced reliability transmission of important data packet(s).

If test 740 is positive, corresponding to situation where more errors are reported than retransmission capability, and moreover when no critical latency of transmission occurs for the receiver, then step 760 applies a strict selective ARQ scheme retransmission policy selection. This selection is performed in step 760, by using the data packet(s) in memory 400, corresponding to the highest priority packet (s) found in “ReTx_Requesf’ and in the “Prio_Tx_Lisf’.

In another embodiment performed only by analysis of the ACK frame (without additional information), the step 720 may be performed by the transmitter by estimation of receiver buffer reception level.

During an initial transmission period corresponding to the transmission of “Nb_Data Latency” packets (set as 50 for 1ms latency), transmitting device 125 estimates the initial buffer level by retrieving the erroneous packet to the initial “Nb_Data Latency” budget. For example, during the initial transmission, 3 data packets may be returned as errors. Therefore the initial buffer level is set to 47. Then, after this step, on each new data stream transmission sequences 310, after receiving feedback, estimation is adjusted by addition of the “Nb_Retx_Budget + Nb_Data” minus the number of errors reported in the ACK. Then, when this value is found to be less than the threshold value (as set in step 720), then step 730 is performed.

Figure 8 is a schematic block diagram of a computing device 800 for implementation of one or more embodiments of the invention. The computing device 800 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 800 comprises a communication bus connected to: - a central processing unit 801, such as a microprocessor, denoted CPU; - a random access memory 802, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method for encoding or decoding at least part of an image according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; - a read only memory 803, denoted ROM, for storing computer programs for implementing embodiments of the invention; - a network interface 804 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 804 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 801; - a user interface 805 may be used for receiving inputs from a user or to display information to a user; - a hard disk 806 denoted HD may be provided as a mass storage device; - an I/O module 807 may be used for receiving/sending data from/to external devices such as a video source or display.

The executable code may be stored either in read only memory 803, on the hard disk 806 or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 804, in order to be stored in one of the storage means of the communication device 800, such as the hard disk 806, before being executed.

The central processing unit 801 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 801 is capable of executing instructions from main RAM memory 802 relating to a software application after those instructions have been loaded from the program ROM 803 or the hard-disc (HD) 806 for example. Such a software application, when executed by the CPU 801, causes the steps of the flowcharts shown in Figures 5 to 7 to be performed.

Any step of the algorithm shown in Figure 5 to 7 may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC (“Personal Computer”), a DSP (“Digital Signal Processor”) or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”).

The description of the present invention takes examples of raw video transfer using 60 GHz wireless interface as example. Nevertheless, invention may apply to lightly compress video scheme, using data priority provided by application layer such B (for “Bi-predictive Picture”), P (for “Predicted Picture”) or I (for “Intra-coded picture) frames for H.264 encoded data on wireless interface such as 802.11a,g or n (Lower bandwidth (54Mbps/600Mbps) - different frequency (2.4 or 5 GHz)). Such usage may be useful for a system such as a Video-Surveillance system.

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A method of transmission of video data packets of a video from a transmitter to a receiver by using a transmission frame and a > retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets which have not been correctly received by the receiver, the method comprising transmitting to the receiver at least one not yet transmitted video data packet by using the retransmission frame. I

2. The method of claim 1 further comprising, transmitting at least one data packet which has not been correctly received, by using the retransmission frame. >

3. The method of claim 1 or claim 2 wherein the at least one not yet transmitted video data packet is transmitted by using the retransmission frame if at least one transmitted video data packet has not been correctly received after being transmitted to the receiver.

4. The method of any of claims 1 to 3 comprising selecting video data packets to be transmitted by using the retransmission frame as a function of priority levels associated with the video data packets.

5. The method of any of claims 1 to 4 comprising selecting video data > packets to be transmitted by using the retransmission frame as a function of packet transmission latency of the transmission frame.

6. The method of claim 5 wherein if a receiver buffer level of the receiver is less than a threshold value, the video data packets to be transmitted by i using the retransmission frame are selected among not yet transmitted video data packets and among data packets which have not been correctly received.

7. The method of claim 5, wherein if a receiver buffer level of the receiver is greater than a threshold value, the video data packets to be transmitted by using the retransmission frame are selected further based on a > number of data packets which have not been correctly received.

8. The method of claim 7 wherein if the number of data packets which have not been correctly received is lower than a given capacity of transmission of the retransmission frame, the video data packets to be i transmitted by using the retransmission frame are selected so as to comprise all the video data packets which have not been correctly received and the highest priority video data packets among not yet transmitted video data packets. >

9. The method of claim 7 wherein if the number of data packets which have not been correctly received is greater than a given capacity of transmission of the retransmission frame, the video data packets to be transmitted by using the retransmission frame are selected only among the video data packets which have not been correctly received. I

10. The method of any one of claims 4 to 9, wherein the highest priority video data packets are packets containing synchronization information.

11. The method of any one of the preceding claims, wherein the > retransmission frame has a given capacity of transmission which is less than 10% of a capacity of transmission of the transmission frame.

12. The method of any one of the preceding claims, wherein: - the transmission frame comprises data packets corresponding to a i sequence of video data packets; and - the retransmission frame is transmitted between transmission frames.

13. The method of any one of claims 4 to 12, wherein: - priority levels are determined according to criteria based on the importance of the video data packet in the video decoding > process.

14. The method of claim 13, wherein said criteria comprise at least one of the following: - whether the video data packet contains position information in the i image; - whether the video data packet contains only pixel data information.

15. The method of any one of the claims 5 to 14 wherein the packet > transmission latency is determined by comparing a receiver buffer level of the receiver with a threshold value.

16. The method of claim 15, wherein the method comprises to test whether the information on a filing level of the receiver buffer indicates a i low buffer condition, the information on the filing level of the receiver buffer being the actual filing level and the method comprising comparing the filing level received to a predetermined threshold.

17. The method of claim 15 or claim 16, wherein the information on the > filing level of the receiver buffer is received within an acknowledgement message configured to indicate if at least one transmitted video data packet has not been correctly received.

18. A method of reception of video data packets of a video by a receiver i from a transmitter by using a transmission frame and a retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets not correctly received by the receiver, the method comprising: - receiving at least one video data packet not yet transmitted within the transmission frame, transmitted by using the retransmission > frame.

19. The method of claim 18 further comprising sending back to the transmitter an acknowledgement message indicating that at least one transmitted video data packet has not been correctly received. I

20. The method of claim 18 or claim 19 further comprising: - monitoring a filing level of a receiver buffer of the receiver; and - sending back to the transmitter an information on the filing level of the receiver buffer. I

21. The method of claim 20, wherein the information is the result of the comparison of the filing level of the receiver buffer to a predetermined threshold. i

22. A transmitter device for transmission of video data packets of a video to a receiver by using a transmission frame and a retransmission frame, and the retransmission frame being usually reserved for retransmitting video data packets which have not been correctly received by the receiver, the device comprising: > - a transmitting module configured for transmitting to the receiver at least one not yet transmitted video data packet by using the retransmission frame.

23. The transmitter device of claim 22 wherein the transmitting module is i configured for transmitting at least one data packet which has not been correctly received by using the retransmission frame.

24. The transmitter device of claim 22 or claim 23 wherein the transmitting module is configured for transmitting at least one not yet transmitted video data packet by using the retransmission frame if at least one transmitted video data packet has not been correctly received after being transmitted > to the receiver.

25. The transmitter device of any of claims 22 to 24 comprising a selecting module configured for selecting, as a function of priority levels associated with the video data packets, video data packets to be i transmitted by using the retransmission frame.

26. The transmitter device of claim 25, wherein the selecting module is configured for selecting, as a function of packet transmission latency of the transmission frame, video data packets to be transmitted by using the > retransmission frame.

27. The transmitter device of claim 26, wherein the packet transmission latency is determined by comparing a receiver buffer level of the receiver with a threshold value. I

28. The transmitter device of claim 26 or claim 27, wherein the selecting module is configured for selecting, as a function of a comparison of the number of data packets which have not been correctly received with a given capacity of transmission of the retransmission frame, video data > packets to be transmitted by using the retransmission frame.

29. The transmitter device of any one of claims 25 to 28, wherein the highest priority video data packets are packets containing synchronization information. I

30. The transmitter device of any one of claims 22 to 29, wherein the retransmission frame has a given capacity of transmission which is less than 10% of a capacity of transmission of the transmission frame. >

31. A receiver device for reception of video data packets of a video from a transmitter by using a transmission frame and a retransmission frame, the retransmission frame being usually reserved for retransmitting video data packets not correctly received by the receiver, the device comprising: a receiving module configured for receiving at least one video data i packet not yet transmitted within the transmission frame, transmitted by using the retransmission frame.

32. The receiver device of claim 31 further comprising a verification module configured to determine if at least one transmitted video data > packet has not been correctly received, and to send back to the transmitter an acknowledgement message indicating that at least one transmitted video data packet has not been correctly received.

33. The receiver device of claim 31 or claim 32 further comprising a filing i level monitoring module configured to monitor a filing level of a receiver buffer of the receiver, and to send back to the transmitter an information on the filing level of the receiver buffer.

34. The receiver device of claim 33, wherein the filing level monitoring > module generates the information by comparing the filing level of the receiver buffer with a predetermined threshold.

35. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for i implementing a method according to any one of claims 1 to 21, when loaded into and executed by the programmable apparatus.

36. A computer-readable storage medium storing instructions of a computer program for implementing a method according to any one of claims 1 to 21.