GB2505225A - Retransmission of video packets at time-varying compression levels - Google Patents

Retransmission of video packets at time-varying compression levels Download PDF

Info

Publication number
GB2505225A
GB2505225A GB1215045.4A GB201215045A GB2505225A GB 2505225 A GB2505225 A GB 2505225A GB 201215045 A GB201215045 A GB 201215045A GB 2505225 A GB2505225 A GB 2505225A
Authority
GB
United Kingdom
Prior art keywords
packet
sending
packets
buffer
compression level
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB1215045.4A
Other versions
GB201215045D0 (en
GB2505225B (en
Inventor
Pascal Lagrange
Julien Sevin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to GB1215045.4A priority Critical patent/GB2505225B/en
Publication of GB201215045D0 publication Critical patent/GB201215045D0/en
Publication of GB2505225A publication Critical patent/GB2505225A/en
Application granted granted Critical
Publication of GB2505225B publication Critical patent/GB2505225B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805Controlling the feeding rate to the network, e.g. by controlling the video pump
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637Control signals issued by the client directed to the server or network components
    • H04N21/6375Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60General implementation details not specific to a particular type of compression
    • H03M7/6047Power optimization with respect to the encoder, decoder, storage or transmission
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60General implementation details not specific to a particular type of compression
    • H03M7/6064Selection of Compressor
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60General implementation details not specific to a particular type of compression
    • H03M7/6064Selection of Compressor
    • H03M7/6076Selection between compressors of the same type
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146Data rate or code amount at the encoder output
    • H04N19/152Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

In a High Definition (HD) video packet streaming network (fig. 1) incorporating Automatic Repeat Request (ARQ) of blocks of uncompressed packets, packet copies are stored in a resending buffer (4040, fig. 4) and retransmitted following a negative acknowledgement (NACK) at a compression level which varies according to available bandwidth (4540, fig. 7) and the time for which the packet has been stored. One buffer portion is for recently stored packets (800, fig. 8) and a second is for older packets (810, fig. 8). When the first buffer portion is full, its oldest copy packet is compressed and sent to the second portion, allowing a receiving device (450, fig. 7) to determine when a stored packet has reached a target compression level (4550). When both buffer portions are full, the compression level is increased to prevent overflow, and both buffers emptied when a block ACK is received.

Description

I
METHOD OF COMMUNICATING VIDEO DATA OVER A COMMUNICATION
NETWORK, ASSOCIATED DEVICES AND SYSTEM
FIELD OF THE INVENTION
The present invention relates in general to network communications, and in particular, to communications of video data over a communication network.
BACKGROUND OF THE INVENTION
Recent multimedia applications require sending or transmission of uncompressed video data over a communication network for display at a displaying device. The communication network can be either a wired network or a wireless network.
Today video data are often high-definition audio/video content, thus requiring communication at high data rate of several Gigabits per second (0bps) with low latency for comfortable display.
For instance, a video transmission system in which high definition (MD) video (i.e., 60 Hz frames of 1920 vertical lines and 1080 horizontal lines corresponding to 1920 X 1080 pixels of 24 bits) must be transmitted has to provide a channel bandwidth of about 3 0bps to support uncompressed HD video data only.
Such bitrate of 3Gbps is not achievable in current 802.11 wireless systems using the 2.4 0Hz and 5 GHz radio bands. It is necessary to use higher frequencies, for instance the 57-66 0Hz millimetre wave unlicensed spectrum, referred to as 60 GHz millimetre wave technology, to obtain such high bitrate.
Transmission systems relying on that wireless technology are widely studied, as shown through the amount of standards in process: IEEE 802.11 Task Group, IEEE 802.15.3c standard, Wireless ND, WiGiG, etc. It results that the research community proposes several solutions and methods to ensure the uncompressed audio and video data to be transmitted with the desired quality of service.
However, the transmission systems based on the 6OTGHZ millimetre wave technology are highly sensitive to perturbations such as shadowing or interferences, or to fading phenomena, which phenomena may be due to the presence of an unexpected obstacle on the transmission path. Given these perturbations and phenomena, the transmission error rate, i.e. the ratio of transmitted packets that are actually received with error by a receiving device compared to the number of transmitted packets, may increase substantially.
Mechanisms have thus been implemented to improve the number of packets ultimately received without error, when interference or fading phenomena degrade the communication network performance.
A well-known mechanism, the Automatic Repeat reQuest (ARQ) mechanism, allows retransmission of packets by the transmitting device if erroneously received by the receiving device.
In practice, ARQ mechanism requires the transmitting device to add a Cyclic Redundancy Check (CRC) inside each packet transmitted to the receiving device. The latter uses the embedded CRC to determine the reception status of each received packet: error-free packet or erroneous packet.
A feedback acknowledge message or signal (ACK) embedding the reception status of received packet or packets is then sent to the sending device. In embodiments, an individual ACK message is sent for each received packet.
Based on the reception status embedded within the ACK message, the sending device may retransmit all or part of the packet(s) if erroneously received.
The ARQ mechanism thus significantly increases the quality of the video data transmission and consequently the quality of its display.
However, it increases bandwidth consumption since ACK messages and packet retransmissions use part of the bandwidth that could be allocated for transmitting video packets for first time.
Typically, the ARQ mechanism allows recovering up to a fixed packet error rate, referred to as the capacity of the ARQ scheme, which depends on the maximum channel bandwidth that can be assigned to packet retransmission while keeping video data throughput.
For example, IEEE 802.15.3c or wireless HO standards define an ARQ scheme that allows recovering a Packet Error Rate (PER) up to 2%. In these examples, the channel bandwidth available for retransmitting packets corresponding to erroneous received packets is fixed and depends on several network configuration parameters negotiated previously: acknowledge scheme, aggregation scheme, etc. If the PER exceeds the capacity of the ARQ scheme (i.e. the channel bandwidth available for retransmitting packets), the packets corresponding to erroneous received packets are no longer retransmitted. This results in an area of the video that is not displayed, and thus in a poor video rendering from the user's point of view.
Publication US 20081037466 discloses a system for wireless communication of uncompressed video having acknowledged messages that seeks to enhance the accuracy and quality of video data being transmitted. Transmitted packets comprise a plurality of sub-packets, and one or more bits in the ACK message are used to indicate the reception status of the most significant bits (MSBs) of the sub-packets, i.e. of the video components (typically four MSBs of each component).
That means that the transmitting device will only retransmit the MSBs when erroneously received, thus avoiding retransmitting the least significant bits (LSBs). At constant ARC scheme capacity, this reduces the amount of video areas liable to be not displayed due to PER exceeding the ARC scheme capacity.
However, depending on the PER, the disclosed system may under-use the available channel bandwidth (if PER is low) while the whole video component information could be retransmitted, or may still generate non displayed video areas (if PER is high).
This is an object of the invention to address that issue and to provide an improved use of the channel bandwidth available for resending packets corresponding to erroneous received packets, in particular when unexpected perturbations or fading phenomena may occur.
Packet sending and resending should preferably be performed with low latency, typically about or less than 10 ms for video data, to provide an immersive experience to the user.
This is also an object of the invention to provide a high quality display of videos regardless the channel network conditions (e.g. regardless PER).
There are several known strategies to manage error detection, data sending (selective repeat, go back, etc.) and acknowledge message generation (cumulative, selective...).
A typical acknowledgement technique used for high data rate sending is the block acknowledgement (BIk-ACK) where, instead of sending an individual ACK message for each received packet, the receiving device acknowledges a plurality of packets within a single acknowledge message.
Block acknowledgement thus reduces use of the wireless channel bandwidth since the overhead is reduced compared to a plurality of ACK messages.
However, block acknowledgement impacts memory of the sending device since the latter needs to buffer all the sent packets as long as they have not been acknowledged by the receiving device. The amount of memory used for buffering, i.e. of a resending buffer at the sending device, may thus substantially increase.
This is also an object of the invention to provide an improved use of such resending buffer memory of the sending device. This is to make it possible to involve low memory resource devices.
Above explanations are provided with reference to a wireless communication network. However, network perturbations, fading phenomena or acknowledge mechanism can also exist in wired communication networks. Therefore, the invention in its broadest scope encompasses both wired and wireless technologies.
The present invention has been devised to address at least one of the foregoing concerns.
SUMMARY OF THE INVENTION
In this context, according to a first aspect of the invention, there is provided a method of communicating video data over a communication network, the method comprising, at a sending device: sending packets of video data to a receiving device; storing a copy of each sent packet in a resending buffer of the sending device while waiting for an acknowledge message thereof from the receiving device; further to receiving a negative acknowledge message from the receiving device for at least one sent packet, resending said at least one sent packet to the receiving device; wherein at least one copy packet in the resending buffer is compressed, and the compression level of the at least one packet copy varies over time during its or their storage in the resending buffer.
Correspondingly, according to a second aspect of the invention, there is provided a communication device comprising: a sending module for sending packets of video data to a receiving device over a communication network; a resending buffer for storing a copy of each sent packet therein while waiting for an acknowledge message thereof from the receiving device; a resending module for resending at least one sent packet to the receiving device, further to receiving a negative acknowledge message from the receiving device for said at least one sent packet; wherein at least one copy packet in the resending buffer is compressed, and the compression level of the at least one packet copy varies over time during its or their storage in the resending buffer.
The present invention improves the use of the resending buffer (or retransmission buffer in wireless networks) as well as the use of the network bandwidth available for resending packets corresponding to erroneous received packets.
This is achieved by implementing a time-dependent compressed storage of the packets sent by the sending device as long as their respective acknowledges are not received.
This is because as the number of sent packets increases (i.e. as time goes), the compression level for storage can also increase, thus limiting the amount of additional memory required for storage. As explained below, the invention makes it possible to implement a fixed-size transmission buffer driving the compression level as the number of sent packets increases.
This is also because the time-dependent compression level applied to the stored packets may thus reduce the channel bandwidth for resending them if needed.
As explained below, the right time at which the compression level of a packet to resend is compliant with the available channel bandwidth may be selected. Efficient use of the channel bandwidth is thus obtained.
According to a third aspect of the invention, there is provided a method of communicating video data over a communication network, the method comprising, at a receiving device: determining a target compression level for a sending device to send at least one packet of video data to the receiving device, said determining being based on transmission bandwidth available in the communication network; determining a sending time point for the sending device to send the at least one packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in a buffer of the sending device; scheduling the sending of a message requesting the sending device to send the at least one packet, at a requesting time based on the determined sending time point; and following the sending of the message, receiving the at least one packet from the sending device.
Correspondingly, according to a fourth aspect of the invention, there is provided a communication device comprising: a compression level determining module for determining a target compression level for a sending device to send at least one packet of video data to the communication device over a communication network, said determining being based on transmission bandwidth available in the communication network; a sending time point determining module for determining a sending time point for the sending device to send the at least one packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in a buffer of the sending device; a scheduler for scheduling the sending of a message requesting the sending device to send the at least one packet, at a requesting time based on the determined sending time point; and a receiver for receiving, following the sending of the message, the at least one packet from the sending device.
While the above first and second aspects define the invention from the sending device's perspective, the third and fourth aspects define the invention from the receiving device's perspective.
The method at the receiving device improves the use of the network bandwidth available for resending packets, in particular for resending packets corresponding to erroneous received packets. The buffer as defined here may thus correspond to the resending (or retransmission) buffer defined above.
This is achieved by determining the compression level at which the packet should be resent by the sending device and then by requesting the sending device at the appropriate time so that the packet to send is compressed according to said compression level when receiving and processing the request.
The receiving device can thus control the use of the bandwidth available for retransmission according to the actual PER in the communication network, by selecting appropriate compression levels. A high quality display without non displayed areas may thus be obtained.
According to a fifth aspect of the invention, there is provided a video communication system comprising a communication network and at least one sending device as defined above and one receiving device as defined above that communicate together over the communication network, wherein the receiving device further comprises: a receiver for receiving the packets of video data sent by the sending device; a check module for identifying at least one erroneous received packet amongst the received packets; an acknowledgment module for sending an acknowledge message requesting the sending device to resend the packet corresponding to the at least one erroneous received packet; wherein the determining by the compression level determining module and the sending time point determining module is performed for the at least one erroneous received packet so that the sending device resends the packet corresponding to the at least one erroneous received packet, wherein the available transmission bandwidth is a channel bandwidth available for resending packets corresponding to erroneous received packets, and the scheduled message is an acknowledge message.
The system of the invention thus combines the advantages as set out above, namely the improvement of use of memory resources, of network bandwidth and a higher quality display of the video data.
Other features of embodiments of the invention are further defined in the dependent appended claims.
According to embodiments of the invention, the buffer at the sending device comprises a first buffer portion to store uncompressed copy packets and a second buffer portion to store compressed copy packets at the compression level varying over time. One may thus understand that the compression level may depend on the filling level of the buffer: the more the copy packets to store, the higher the compression level. This provision makes it possible to limit the memory resource required by the sending device.
In particular, the first buffer portion is used to store copy packets of the packets the most recently sent by the sending device and the second buffer portion is used to store copy packets of older sent packets. That means that as soon as the first buffer portion is full, it flows into the second buffer portion when storing a newly sent packet. Such mechanism makes it possible for the receiving device, as soon as it knows the mechanism, to efficiently determine when a stored packet reaches a target compression level.
Such buffer structure can be used when implementing the ARO scheme with block acknowledgment since the sent packets are stored in the buffer waiting for their acknowledgement from the receiving device.
According to a particular feature, the method further comprises, if the first buffer portion is full when a new packet is sent by the sending device, moving the oldest copy packet of the first buffer portion to the second buffer portion to free space for storing a copy packet of the newly sent packet, said moved oldest copy packet being compressed at the compression level for storage in the second buffer portion.
This reflects the above-described memory management scheme of buffer flowing.
According to another particular feature, the method further comprises, if the second buffer portion is full when a new copy packet is to be stored in the second buffer portion, increasing the compression level used for the storage of the compressed copy packets therein. This provision avoids the buffer from being overflown. This improves the use of a resending buffer implemented with an ARQ scheme involving the block acknowledgment while ensuring the video rendering to be without missing video area. This is because video information is kept for each packet (even if it is a small amount of information) that can be resent for display if erroneously received by the receiving device when sent for first time.
In particular, the method may further comprise, when the compression level is increased, modifying the compression of the copy packets already stored in the second buffer portion to the increased compression level. This is to free memory space to receive the new compressed copy packet to store.
In embodiments of the invention, the compression level varying over time is selected from a set of compression levels corresponding to the removal of a respective number of least significant bits in components of the video data making the packets.
For example, the first compression level may correspond to the removal of the first LSB from each video component; the second compression level to the removal of the two LSBs; and so on.
In a variant, components of the video data may be removed to form the compression levels. For example, pixel components can be removed (for instance chroma subsampling) to produce 4:2:2, 4:2:1, 4:2:0 (and so on) video data for corresponding compression levels.
In another variant, a combination of LSB removal and chroma subsampling can be implemented to offer a larger number of compression levels.
In embodiments of the invention, the time-varying compression level depends on a size of the buffer and on the number of video data packets sent for first time by the sending device since a last reset of the compression level and stored in the buffer. This reflects the progressive filling of the (sending) buffer. Knowing the buffer size and the frequency of packet sending, the receiving device is also able to estimate the compression function defining the time-varying compression level, and thus to determine the above-defined (re)sending time point.
In embodiments of the invention, the communication network is a 60 GHz-based wireless network.
From the sending device's perspective, embodiments of the invention further comprise upon receiving an acknowledge message from the receiving device, resetting the compression level to an initial compression level. Preferably the initial compression level is the lowest compression level since an efficient design of the buffer makes that the buffer portion storing compressed copy packets as defined above is emptied by a block acknowledge message.
In particular, a copy packet of a sent packet positively acknowledged in the acknowledge message is removed from the resending buffer; and a copy packet of a sent packet negatively acknowledged in the acknowledge message is moved from a buffer portion of the resending buffer to a third buffer portion of the resending buffer.
This provision makes it possible for the sending device to temporarily store the packets to be resent (possibly in a compressed form) waiting for the next access to the communication network for resending, while having the main buffer portion ready for processing the new packets to send.
From the receiving device's perspective, embodiments of the invention provide that the access to the communication network by the sending device is driven by a medium access scheme defining a plurality of superframes, each superirame comprising a defined number of frames for sending packets of video data for first time (i.e. excluding a retransmission); and the method comprises calculating the bandwidth defined between the superIrame and the number of frames therein, less the bandwidth used for sending acknowledge messages and for resending packets already sent during the current superframe, to obtain the available transmission bandwidth. This efficiently defines the bandwidth that is available for packet resending that the receiving device intends to remotely drive at the sending device.
This is because the bandwidth available for packet resending is generally fixed for a given superframe. Therefore, there is a need to monitor how this bandwidth is progressively used during the superirame in order to adapt and control the usage of its remaining portion for the next packet resending.
According to other embodiments of the invention, the determining of a target compression level is also based on a Packet Error Rate measured by the receiving device on packets received from the sending device. This is because as the PER increases, the number of packet resending also increases. Therefore the packets should be more compressed when resent to ensure that information on every video data (every packet) is ultimately received and can be displayed.
According to other embodiments of the invention, the requesting time point is computed from the determined sending time point and an estimate of a sending delay for the requesting message (typically an acknowledge message) to be sent from the receiving device to the sending device. This is to ensure that the requested message will be actually compressed at the target compression level when the request is processed by the sending device.
According to other embodiments of the invention where the at least one packet corresponds to an erroneous packet received from the sending device, the sending of the requesting message is postponed as long as a ratio between a number of erroneous received packets and a number of received packets is above a predefined threshold. This is to avoid sending an acknowledge message each time an erroneous packet is received, which would lead to an overconsumption of the available retransmission bandwidth.
According to embodiments of the invention, the compression level determining module, the sending time point determining module, the scheduler and an estimator of the sending delay for the requesting message are separate hardware components.
Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a communication device of a communication network, causes the communication device to perlorm the steps of any of the above-defined methods.
The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the methods of communicating video data, in particular that of improving the use of the network bandwidth and of the memory at the sending device.
Another aspect of the invention relates to a method of communicating video data substantially as herein described with reference to, and as shown in, Figures 1 Oa and lob; Figure 11 of the accompanying drawings.
Another aspect of the invention relates to a communication device substantially as herein described with reference to, and as shown in, Figure 7a; Figures 7a and 8; Figure 7b of the accompanying drawings.
At least parts of the method according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects which may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.
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, for example a tangible carrier medium or a 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 a typical video streaming system; Figure 2 illustrates a timeline of a wireless medium access scheme for embodiments of the invention; Figure 3 is a block diagram illustrating components of a communication device in which embodiments of the invention may be implemented; Figure 3a illustrates a random access memory of the communication device of Figure 3; Figure 4 illustrates other function blocks of such communication device; Figure 5 illustrates the structure of uncompressed video pixels made of associated video components and pixel information dropping operation based on most significant bits and less significant bits of each pixel: Figure 6 illustrates another pixel information dropping operation based on sub-sampling schemes; Figure 7 illustrates yet other function blocks of the same communication device: Figure 8 illustrates an example of implementation of the retransmission buffer according to embodiments of the invention: Figure 9 iilustrates the context of packet acknowledgment for implementing embodiments of the invention; Figure 10 is a flowchart illustrating general steps of a communication method at a transmitting device according to embodiments of the invention; and Figure 11 is a flowchart illustrating general steps of a communication method at a receiving device according to embodiments of the invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
The invention provides methods and devices for communicating video data over a communication network.
In the examples below, it is a wireless communication network operating according to the unlicenced 60 0Hz frequency band. However, the invention may apply to any kind of communication network, be wireless or wired, that may suffer from unexpected perturbations or fading phenomena.
As illustrated below, the invention may come within the scope of live video streaming in wireless communication systems.
A typical video streaming system 100 is shown in Figure 1 with a single transmitting device 140 (i.e. sending device) and a single receiving device 120, interconnected through the communication network 101. In embodiments of the invention, the video streaming system may comprise a greater number of devices that share the access to the communication network 101.
The receiving device 120 may be a video projector for displaying video data received from the transmitting device 140. In an example where a plurality of receiving device 120 is implemented, they form a tiled display area of a multi-projector display system, each receiving device 120 receiving video data from a respective transmitting device 140.
The transmitting device 140 comprises a source communication device 110 storing video data such as HO video and a wireless adapter device 130 that interfaces the source communication device 110 to the communication network 101.
Communication of HO video data between the source communication device 110 and the wireless adapter device 130 can be performed through wireless or wired link 102 (e.g. 60 GHz based wireless link or HDMI wired link). Both devices may be embedded into a single transmitting device 140 as it is considered in the following description, but may also be implemented through separated hardware devices.
The wireless adapter device 130 thus transmits the HD video data received from the source communication device 110 to the receiving device 120 via the communication network 101.
In the Figure, communication link 102 is wired while communication network 101 is wireless. The wireless communication network is subject to unexpected perturbations or fading phenomena, thus resulting in the invention being implemented for the link between 120 and 140 in the communication network 101.
Access to the communication network 101 is shared between the several devices that can be implemented in the video streaming system 100. The access can be time shared, i.e. according to a Time Oivision Multiplexing Access (TDMA).
A device coordinator (not shown) may be provided in the communication network 101 to statically define the parameters for the TOM access. Such device coordinator may be one of the transmitting/receiving devices.
Figure 2 illustrates a timeline of a wireless medium access scheme for embodiments of the invention.
The time is split into successive superirames having each a period Tsuperframe The period Tsuperframe is predefined by the device coordinator.
Each superframe comprises a plurality of N1 transmission time slots frames allocated to respective communication devices of the system 100 according to the TOMA allocation, for the devices to transmit data. The same time slot allocation is applied for successive superframes until a new allocation is defined (for instance dynamically).
In the example of Figure 1, all the time slots are allocated to transmitting device 140 which is the only communication device transmitting video data. N1 may be predefined by the device coordinator in order to ensure NTX time slots to be available for video data transmission.
Only two time slots of superframe N are shown in the Figure. A first time slot 201 starts at time 221 and ends at time 222 when a second time slot 202 starts.
And so on.
A transmission time slot is made of a transmission frame 251/252 for transmitting video data and of an optional guard interval 241 for the purpose of safe medium access. The guard interval 241 has a predefined period T902 defined between time 231 and time 222 while the transmission frame 251 has a predefined period T'1 defined between time 221 and time 231. Preferably the transmission frames have the same period T'1-.
Each time slot has thus normally a period T-1-= T'TX + Tguard.
Each transmission frame 251/252 is made of a plurality of transmission subframes 210,211,212,220,221,222 for transmitting packets of video data from a transmitting device, such as 140, to a receiving device, such as 120.
Where the ARQ scheme is implemented with acknowledge messages, Tsuperrrame > N--X * T--. That means that the remaining bandwidth between the superirame and the number of frames (i.e. TReIX = Tsupe,trame -N1 * TTX) can be devoted to acknowledgment signalling as well as to retransmission of packets, as further described below. This bandwidth is referred to as the retransmission bandwidth available in the communication network. As it is used during the course of a current superirame, the available retransmission bandwidth progressively decreases.
In embodiments, the transmitting device 140 uses the guard interval 241 for detecting the potential transmission of an acknowledge message 203, by the receiving device 120 (in case the latter has received data packets with errors). Such acknowledge message 203 is detected after a short guard interval 242 (the length of which is Tsuard between time 232 and time 223) shorter than T9 of the guard interval 241.
Such acknowledge message 203 is used by the receiving device 120 to notify an erroneous subframe it has received from the transmitting device 140.
If no acknowledge message 203 is detected after a maximum Tsuard interval 242, the transmitting device 140 waits until the completion of the Tgua interval 241 before transmitting the next subframe (i.e. data packets) issued by the source communication device 110.
If an acknowledge message 203 is detected during the Tssuard interval 242, the transmitting device 140 retransmits the data packets of the subframes notified as erroneous by the receiving device 120 in the acknowledge message 203. The retransmission happens in a retransmission frame 204 that occurs after a retransmission guard interval 243 of length TReTXUaId between time 233 and time 224.
Of course a new Tguard interval 241 may be monitored after the retransmission frame 204, for the transmitting device 140 to access the communication network 101 for a new transmission frame 251/252.
The guard interval 242, the acknowledge message 203, the retransmission guard interval 243 and the retransmission frame 204 use part of the available retransmission bandwidth TReTx* According to embodiments of the invention, the transmitting device 140 performs the following steps: sending packets of video data to the receiving device 120; storing a copy of each sent packet in a retransmission (or resending) buffer of the transmitting device while waiting for an acknowledge message thereof from the receiving device; further to receiving a negative acknowledge message from the receiving device for at least one sent packet, resending said at least one sent packet to the receiving device (this is generally done using the copy stored in the retransmission buffer); wherein at least one copy packet in the retransmission buffer is compressed, and the compression level of the at least one packet copy varies over time during its or their storage in the retransmission buffer.
This makes it possible to reduce the size of some packets to be retransmitted, so to reduce the use of the available retransmission bandwidth. It also reduces the memory (retransmission buffer) required for storing the packets while waiting their acknowledge.
To take fully advantage of this retransmission buffer, the retransmission of the packets may be remotely driven by the receiving device 120. This is another aspect of the invention which provides, according to embodiments, at the receiving device: determining a target compression level for the transmitting device to retransmit at least one packet of video data (corresponding to erroneous received packets) to the receiving device, said determining being based on transmission bandwidth available in the communication network; determining a sending time point (or retransmission time point) for the sending device to retransmit the at least one packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in the retransmission buffer of the sending device; scheduling the sending of a message requesting the sending device to send the at least one packet (preferably an acknowledge message), at a requesting time based on the determined retransmission time point; and following the sending of the message, receiving the at least one packet from the sending device.
That means that the receiving device 120 may decide to postpone an acknowledgement of an erroneous packet to a later time in such a way that packet is compressed (up to the target compression level) in the retransmission buffer of the transmitting device 140 when the acknowledge message is actually sent and processed by that transmitting device.
By doing so. the receiving device 120 can thus control the use of the retransmission bandwidth TReIX.
Figure 3 schematically illustrates a communicating device 300, either the transmitting device 140 or the receiving device 120, or a device embedding both functionalities, configured to implement embodiments of the present invention. The communicating device 300 may be a device such as a micro-computer, a workstation or a light portable device. The communicating device 300 comprises a communication bus 313 to which there are preferably connected: -a central processing unit 311, such as a microprocessor, denoted CPU; -a read only memory 307, denoted ROM, for storing computer programs for implementing the invention; -a random access memory 312, denoted RAM, for storing the executable code of embodiments of the invention as well as registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the Invention. It may for example comprise the retransmission buffer according to the invention, as described with more details below; and -a communication interface 302 connected to the communication network 101 over which video data packets or frames are transmitted, for example a wireless communication network according to the 802.lln protocol. The communication interface 302 may comprise one or several network interfaces, for instance wired and wireless interfaces or different kind of wired or wireless interfaces. The data are written to the network interface for transmission or read from the network interface for reception under the control of a software application running in the CPU 311.
A random access memory (RAM) is a type of computer memory that provides large quantities of temporary storage in a computer system.
As shown in Figure 3a, the RAM 312 can store many multiple-bit data words (e.g. 32 bits, 64 bits) 3121, 3122, 3123, 3124, 3125, 3126 or 3127. Each data word is stored, or written", and further retrieved, or read", at a respective memory address.
The RAM can be seen as an array of data. The corresponding memory address serves as an array index, each memory address referring to one word of data.
A data can be read or modified at any given memory address.
There are different types of RAM: one type is known as DRAM (standing for Dynamic Random Access Memory), another is known as SRAM (standing for Static Random Access Memory). These two types of RAM differ in the technology they use to hold data, with DRAM being the more common type. DRAM needs to be refreshed periodically while SRAM does not need to be refreshed, which makes SRAM faster than DRAM.
Back to Figure 3, optionally, the communicating device 300 may also include the following components: -a data storage means 304 such as a hard disk, for storing computer programs for implementing methods of one or more embodiments of the invention; -a disk drive 305 for a disk 306, the disk drive being adapted to read data from the disk 306 or to write data onto said disk; -a screen 309 for displaying video data and/or serving as a graphical interface with a user, by means of a keyboard 310 or any other pointing means.
The communicating device 300 can be connected to various peripherals, such as for example a digital camera 308 as source communication device 110, each being connected to an input/output card (not shown) so as to supply video data to the communicating device 300.
The communication bus provides communication and interoperability between the various elements included in the communicating device 300 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communicating device 300 directly or by means of another element of the communicating device 300.
The disk 306 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.
The executable code may be stored either in read only memory 307, on the hard disk 304 or on a removable digital medium such as for example a disk 306 as described previously. According to a variant, the executable code of the programs can be received by means of the communication network 101, via the interface 302, in order to be stored in one of the storage means of the communicating device 300, such as the hard disk 304, before being executed.
The central processing unit 311 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 304 or in the read only memory 307, are transferred into the random access memory 312, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.
In this embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).
Figure 4 illustrates, through functional blocks, the same communicating device either operating as a sending device (left part of the Figure) or operating as a receiving device (right part of the Figure).
Each of them comprises a physical (PHY) layer 435/485, a Medium Access Control (MAC) layer 425/475, a Protocol Adaptation Layer 415/465 and an upper application layer 405/455, all being controlled by the CPU and memory 440/490.
The transmitting or sending device 400 (for example corresponding to the transmitting device 140 of Figure 1) comprises a video application module 405 that supplies a 4:4:4 uncompressed high definition video stream (for instance, 60 Hz frames of 1920 vertical lines and 1080 horizontal lines corresponding to 1920 X 1080 pixels of 24 bits -4:4:4 scheme).
The sending device 400 also has a communication module 410 which is made of the Protocol Adaptation Layer (PAL) 415, the Medium Access Control (MAC) layer 425 and the physical (PHY) layer 430.
In operation, the video application module 405 sends video data, such as video frames, to the Protocol Adaptation Layer (PAL) 415.
The Protocol Adaptation Layer (PAL) 415 applies a specific processing, for instance data alteration such as video components information dropping. to the pixels belonging to each video frame it receives from the Application module 405.
Data alteration is a way of compressing video data. Various levels of data alteration may provide various levels of compression as disclosed with more details below. The storage of some video packets in the retransmission buffer according to the invention may implement such video data compression.
Figure 5 illustrates the structure of uncompressed video pixels made of associated video components and pixel information dropping operation based on most significant bits and less significant bits of each pixel.
Usually, an uncompressed HD video image contains 1920 vertical lines and 1080 horizontal lines corresponding to 1920 X 1080 pixels.
The 1920 X 1080 pixels of an uncompressed HD video image can be seen as an array of pixels. In Figure 5, only one pixel 500 is shown.
Each pixel of the uncompressed video frame is defined by three video colour components Y, Cb and Cr, where Y is brightness pixel information 530, known as luminance video component (or luma component) and represents the brightness of the image, i.e. the achromatic or "black & white" portion of the image; Cb 540 and Cr 550 are colour pixel information, known as chroma components and represent the colour information of the pixel -the blue information minus the brightness for Cb and the red information minus the brightness for Cr.
Each pixel component may be displayed with various component depths, which means that the information relating to a pixel component may be coded over 8 bits, 12 bits, 16 bits or 32 bits, for instance.
For the purposes of illustration below, a pixel component will be assumed to be coded over 8 bits (i.e. I byte). An uncompressed pixel is thus made of 24 bits of pixel components.
In this context, each pixel video component, like video component 530, is coded over 8 bits 517. 516, 515, 514, 513, 512, 511 and 510. The numeric value Vof video component 530 is given by: V = b517 x 128 + b515 x 64 + b51 x 32 + b514 x 16 + b513 x 8 + 512 X 4 + b511 x 2 + b510 x 1 where b1 is the value of bit I, with I e [517; 516; 515; 514; 513; 512; 511; 510) and b E {0; 1}.
From this formula, it is easily understood that each bit of a video component has a different weight, i.e. contributes differently to the overall value of the video component and its display.
Data alteration by dropping out one or more least significant bits (or LSB) of one or more 8-bit video components may thus be implemented to provide several levels of video data compression.
Dropping out one LSB (i.e. bit 310) per video component gives a compression ratio of 1/8. Dropping out two LSB5 per video component gives a compression ratio of 1/4. Thus four compression levels may be obtained by dropping out respectively 1 LSB, 2 LSBs, 3 LSBs and 4 LSBs. Preference is given to keep at least half the bits.
Of course, LSB dropping may affect only one pixel component or may drop out a different number of LSBs from one pixel component to the other. This is to provide a higher number of possible compression levels.
Figure 6 illustrates another pixel information dropping operation based on sub-sampling schemes.
The 1920 X 1080 pixels of an uncompressed I-ID video image may be seen as an array of blocks of pixels. A pixel block is made of a plurality of adjacent pixels. It is formed by n x m pixels, n rows and m columns pixels.
For the purposes of illustration, let the pixel blocks be made of 2 x 2 pixels in order to reduce the in-chip buffer size and processing latency, each pixel being represented by a base 8-bit luma component Y and two enhancement 8-bit chroma components Cr and Cb as explained above.
Several sub-sampling schemes, or pixel information dropping operations, have been standardized, such as 4:4:4, 4:2:2, 4:2:0 or 4:1:1 (the level of sub-sampling is often expressed by using a string of three integers separated by colons, the first integer representing the luminance sampling frequency while the other two integers represent the chroma sampling frequencies).
In Figure 6, only one pixel block is shown according to three levels of sub-sampling, corresponding to three respective levels of compression: 4:4:4 (i.e. uncompressed pixel block), 4:2:2 (compression ratio of 1/3) and 4:2:0 (compression ratio of 1/2).
Of course, data alteration may combine sub-sampling and LSB dropping to provide more compression levels.
Back to Figure 4, PAL 415 then sends the processed video frame to the MAC layer 425.
Protocol Adaptation Layer (PAL) 415 may also be connected to physical (PHY) layer 430 in order to retrieve information on quality of the communication network, such as a Radio Signal Strength Indication (RSSI) or a Signal-to-Noise Ratio (SNR).
The MAC layer 425 packetizes the video data received from the Protocol Adaptation Layer (PAL) 415 into data packets and sends them to the physical (PHY) layer 430 for sending.
The MAC layer 425 also provides addressing and channel access control mechanisms as mentioned above.
The physical (PHY) layer 430 sends the packets over the communication network 101 to the receiving device 450.
In 60 GHz-based wireless network or any network relying on millimeter wave frequency bands, the physical (PHY) layer 430 uses a smart antenna 435 to transmit the video data packets over the wireless medium.
The receiving device 450 (for example corresponding to device 120 of Figure 1) also comprises a video application module 455 and a communication module 460 which contains the Protocol Adaptation Layer (PAL) 465, the MAC layer 475 and the physical (PHY) layer 480.
The receiving device receives the sent packets through its smart antenna 485, itself connected to the physical (PHY) layer 480.
The physical (PHY) layer 480 processes the packets up to the MAC layer 475, which then processes the received data packets up to the Protocol Adaptation Layer (PAL) 465.
The Protocol Adaptation Layer (PAL) 465 reconstructs the received video frames. Such reconstruction may consist in replacing altered data with more efficient data. For example if data alteration at the sending device consists in discarding some information such as LSBs, the reconstruction may consist in reforming those least significant bits by using an appropriate number of is and/or Os without significantly impacting the visual rendering of the pixel.
The Protocol Adaptation Layer (PAL) 465 then provides the video application module 455 with reconstructed video frames.
The video application module 455 is in charge of decoding the video frames to make it possible to display the video to a user.
To enable bidirectional communication to be implemented between the devices of the video streaming system 100, embodiments of the invention provide that both transmitting device 140 and receiving device 120 implement the sending device 400 and the receiving device 450. In embodiments of the invention, the wireless adapter device 130 implements both the sending device 400 and the receiving device 450.
Figure 7 illustrates, through functional blocks, the same devices from another perspective.
The sending or transmitting device 400 comprises: a video data obtaining module 4010 for obtaining video data frame from a communication source device 110; a packetizer 4020 for packetizing the video data according to transmission frames of the communication network 101; a sending module 4030 for sending packets of video data to a receiving device 450 over the communication network 101. The sending is according to a medium access scheme that provides for example the sending device with time slots to send the packets; a resending buffer 4040 for storing a copy of each sent packet therein while waiting for an acknowledge message thereof from the receiving device 450. The resending buffer is controlled by a buffer controller 4050 that provides at least one copy packet to be compressed in the resending buffer 4040 wherein the compression level of the at least one packet copy varies over time during its or their storage in the resending buffer. The compression of copy packets may involve the data alteration means of PAL 415; a resending module 4060 for resending at least one sent packet to the receiving device 450, further to receiving a negative acknowledge message from the receiving device 450 for said at least one sent packet; an acknowledgement receiving module 4070 for receiving such acknowledge messages from the receiving device 450.
The receiving device 450 comprises: a receiver 4510 for receiving packets of video data sent by the sending device 400; a check module 4520 for identifying at least one erroneous received packet amongst the received packets; an acknowledgment module 4530 for sending an acknowledge message requesting the sending device to resend the packet corresponding to the at least one erroneous received packet; an available retransmission bandwidth determining module 4540 for determining the remaining retransmission bandwidth available in current superframe.
This may be done by calculating the bandwidth defined between the superframe and the number of frames therein, less the bandwidth used for sending acknowledge messages and for resending packets already sent during the current superframe; a compression level determining module 4550 for determining a target compression level for the sending device 400 to resend the packet of video data to the receiving device 450 over the communication network 101, said determining being based on the retransmission bandwidth available in the communication network as determined by module 4540; a resending or retransmission time point determining module 4560 for determining a resending/retransmission time point for the sending device 400 to resend/retransmit the packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in the retransmission buffer 4040 of the sending device 400; and a scheduler 4570 for scheduling the sending of the acknowledge message requesting the sending device 400 to resend/retransmit the packet, at a requesting time based on the determined sending time point.
Figure 8 shows an example of implementation of the retransmission buffer 4040 in the RAM 312.
The retransmission buffer 4040 comprises three buffer portions: a first buffer portion 800 having a given size to store uncompressed copy packets 801,802,803,804 that are waiting to be acknowledged (either positively or negatively) by the receiving device 120; a second buffer portion 810 having a given size to store compressed copy packets 811,812,813,814,815,816 at the compression level varying overtime, that are waiting to be acknowledged (either positively or negatively) by the receiving device 120; a third buffer portion 820 having a given size to store copy packets (compressed or uncompressed) 821,822,823 that are to be retransmitted.
The sizes of the buffer portions may be prefixed. However, in some embodiments, the sizes may evolve as time goes. For example, the size of the first buffer portion may depend (in particular decrease) on the amount of available retransmission bandwidth remaining in the current superframe. This is to trigger earlier the compression of stored copy packets.
Similarly, the size of the second buffer portion may depend (in particular decrease) on the amount of available retransmission bandwidth remaining in the current superframe. This is to artificially increase the compression level and thus to earlier obtain copy packets the compression level of which meets the requirements for the remaining available retransmission bandwidth.
In embodiments, several second buffer portions may be provided corresponding to several compression levels.
A management of the retransmission buffer 4040 provides that the first buffer portion 800 is used to store copy packets of the packets that are the most recently sent by the sending device and the second buffer portion 810 is used to store copy packets of older sent packets. Here the sent packets are those that have been sent only once, i.e. without retransmission.
In case of several second buffer portions, the oldest sent packets are stored in the second buffer portions having the highest compression levels.
As exemplified above, the compression level at the second buffer portion may be obtained from data alteration of the copy packets as sent by the sending device 400: e.g. LSB dropping, sub-sampling scheme (Chroma component dropping), etc. If the first buffer portion 800 becomes full when a new packet is sent by the sending device 400, the oldest copy packet of the first buffer portion in moved to the second buffer portion 810 to free space for storing a copy packet of the newly sent packet. That means that the copy packets are regularly transferred from the first buffer portion 800 to the second buffer portion 810. In addition, said moved oldest copy packet is compressed at the current compression level for storage in the second buffer portion 810.
The first buffer portion 800 may thus be implemented through a circular memory to avoid moving each of the copy packets it stores when a new packet is to be stored.
The compression level to be applied to the second buffer portion 810 depends on the number of copy packets to be stored therein (the portion has a given size). For example, several compression levels are available as defined above. The best compression level is thus selected based on the number of copy packets to be stored and on the buffer portion size.
As time goes, the number of sent packets increases, so the compression level also varies to enable those sent packets to be stored in the buffer 4040 having a given size.
In operation, if the second buffer portion is full when a new copy packet is to be stored in the second buffer portion (i.e. available space therein is not sufficient to store said new copy packet), the compression level used for the storage of the compressed copy packets therein is increased to the next level, so to enable all the copy packets to fit into the memory provided by said second buffer portion 810. That means that the compression of the copy packets already stored in the second buffer portion is modified to the increased compression level. The above examples of compression (LSB or Chrome dropping) are suitable for gradually increasing the compression level of already stored copy packets. This is because it only requires removing or dropping out another LSB or Chroma component from those still stored at the previous compression level.
The third buffer portion 820 is used to store copy packets (compressed or uncompressed) 821,822,823 that are to be retransmitted. That means that upon receiving an acknowledge message from the receiving device, the copy packets of sent packets that are negatively acknowledged in the acknowledge message are moved from the first or second buffer portion 800/810 to the third buffer portion 820. The third buffer portion 820 may thus comprise both compressed old copy packets (from 810) and uncompressed more recent copy packets (from 800).
In the same time, the copy packets of sent packets positively acknowledged in the acknowledge message are removed from the first and second buffer portions. This makes it possible to empty those first and second buffer portions 800/810 at each new acknowledge message, generally a block acknowledgement (BIk-ACK).
In that situation, since the first and second buffer portions are empty to receive new copy packets to be sent for first time by the transmitting device 140, the compression level for the second buffer portion 810 is reset to an initial compression level, preferably to the lowest compression level of predefined compression levels (possibly including an initial uncompressed level, i.e. a compression level equal to 0).
One may thus understand that the time-varying compression level depends on the number of video data packets sent for first time by the sending device since the last reset of the compression level and stored in the second buffer portion.
The buffer portions may be sized depending on the communication network parameters, such as the available retransmission bandwidth TReTX, an expected PER, the parameters of block acknowledgment (how many packets can be acknowledged by a single message?), a desired latency, etc. Conventional mechanisms such as considering any packet that is not acknowledge within a predefined time (for example because of the loss of the acknowledge message) as a packet to be retransmitted can also be implemented.
Again, the predefined time may be set depending on the desired latency for displaying video data.
An idea of the invention is to use such management of the retransmission buffer 4040 to trigger retransmission of some copy packets at appropriate time for them to be compressed according to a target compression level. This is to control the use of the available retransmission bandwidth TReTX.
Such control is driven by the receiving device 120 which is for example able to adapt the strategy based on a Packet Error Rate measured by the receiving device on packets received from the transmitting device 140.
Figure 9 illustrates the context of packet acknowledgment for implementing this approach.
The receiving device 120 is given the ability to decide when to request the transmitting device 140 for retransmitting video data packets, based on knowledge of the retransmission buffer management scheme as described above.
The transmitting device 140 transmits a sequence of frames 910, 920, 930, 940, 950, each frame being made of a plurality of concatenated packets, some packets being received without any error, like packet 900, while other packets are received with errors, like packet 901.
The receiving device 120, depending on the currently remaining available retransmission bandwidth TReTX, decides the time point for the transmitting device 140 at which the latter should retransmit the copy packet corresponding to the erroneous packet it received. The receiving device 120 can do that way for every packet received since the last acknowledgement message it has sent to the transmitting device 140.
By doing so, the receiving device 120 is able to control the compression ratio applied by the transmitting device 140, and therefore the size of the retransmitted data and the use of the available retransmission bandwidth.
For instance, if enough retransmission bandwidth is available to retransmit data without compression, early acknowledge of the received packets is performed ensuring the requested data to be still stored in the first buffer portion 800.
If less bandwidth is available, due to former retransmission requests during the current superframe, the acknowledge message 203 is sent at a time when the packet to be retransmitted is currently stored in the second buffer portion 810 with the appropriate target compression ratio.
If the acknowledge message is a block acknowledgment, the calculation of target compression ratio should take into account all the packets negatively acknowledged, in such a way their overall retransmission uses a targeted bandwidth amongst the available retransmission bandwidth.
Of course, the transmission delay (including the processing delay) of the acknowledge message must be taken into account so as to reliably predict the actual compression ratio currently applied to the copy packets in the second buffer portion 810 when retransmitted. In other words, the requesting time point at which the receiving device sends the acknowledge message is computed from the determined sending time point at which it is desired that the copy packet be retransmitted and an estimate of a sending delay for the acknowledge message to be sent from the receiving device 120 to the transmitting device 140.
In embodiments of the invention, the receiving device 120 detects a burst of erroneous packets received from the transmitting device 140. That means that the receiving device 120 checks whether or not the ratio of erroneous received packets versus (non-erroneous) received packets is greater than a predefined ratio, e.g. 5 erroneous packets out of 20 received packets. The receiving device 120 waits until the burst of erroneous packets has ended (i.e. the above ratio falls under the predefined ratio) before sending the acknowledgement message 203. However a maximum wait may be implemented, depending on a desired latency.
By doing so, the receiving device 120 avoids transmitting an acknowledgement message each time a received frame comprises an erroneous packet. Not doing so would result in an overconsumption of the overall retransmission bandwidth, which initial value is TReTX* Figure 10 illustrates, in flowcharts, general steps of a communication method at the transmitting device 140. Figure ba is a flowchart illustrating the process when transmitting video data for first time, and Figure lOb is a flowchart illustrating the process when receiving an acknowledge message 203.
Referring to Figure ba, starting from an initial state 1000, the transmitting device 140 determines whether or not new video data are obtained, at step 1010. This may consists for the wireless adapter device 130 to detect whether or not new video data are received from the source communication device 110. Step 1010 takes place in module 4010.
When new video data are received, they are packetized into one or more packets at step 1020 by module 4020. The size of each video data packet depends on the communication network characteristics.
At step 1030, the generated packet of video data is transmitted for first time over the communication network 110 by the sending module 4030, using the PHY layer 430. The transmission is performed during the next time slot 501 allocated to the transmitting device 140. If needed, the packet to be transmitted can be temporarily stored in a transmission buffer until the next time slot is reached.
At step 1040, it is determined whether or not the first buffer portion 800 of the transmission buffer 4040 is full. i.e. is there enough remaining memory space in 800 to store a copy of the packet just transmitted.
If 800 is not full, an uncompressed copy of the packet is stored in that first buffer portion 800 at an appropriate memory address (keeping the order of the packet copies according to their age), at step 1050.
If 800 is full, step 1060 consists in selecting the oldest packet copy currently stored in the first buffer portion 800. Step 1060 is followed by step 1070 where it is determined whether or not the second buffer portion 810 of the transmission buffer 4040 is full, i.e. is there enough remaining memory space in 810 to store the selected oldest packet copy using the current compression level.
If 810 is not full, the selected oldest packet copy is compressed according to the current compression level and stored in the second buffer portion 810, at step 1080. As explained above, the compression may only consist in data alteration such as LSB dropping or sub-sampling.
An initial compression level amongst a plurality of predefined compression levels is used when starting the method. The initial level can be an uncompressed scheme or not.
If 810 is full, step 1090 is performed during which: the compression level applied to the second buffer portion 810 is increased to the next compression level amongst the predefined compression levels; and 810 is updated, meaning that the copy packets already stored in 810 are further compressed to comply with that new compression level. This may be done by dropping out LSBs or Chroma components from pixel information, corresponding to the difference between the previous compression level and the new compression level.
This operation frees some memory space in 810.
Step 1090 is followed by step 1080 already explained: the selected oldest packet copy is compressed according to the current compression level (i.e. the new one as selected at step 1090) and stored in the second buffer portion 810 together with the further-compressed copy packets.
StepslO6O-1090 makes it possible to move the oldest packet copy stored in 800 to 810 in order to free some memory space in 800 for receiving a copy of the packet just transmitted at step 1030.
Next to step 1080, step 1050 is performed during which such uncompressed copy of the packet just transmitted at step 1030 is stored in the first buffer portion 800 at an appropriate memory address.
Referring to Figure lOb, starting from an initial state 1100, the transmitting device 140 determines whether or not an acknowledge message 203 is received from the receiving device 120 over the communication network 101, at step 1110.
When an acknowledge message 203 is received from the receiving device 120, each packet referred to in the acknowledge message 203 is successively processed through step 1120 and the loop back to that step.
For each packet that is acknowledged in message 203, step 1130 consists in determining whether the corresponding acknowledge is positive or negative.
In case of positive acknowledge, the copy packet corresponding to the positively acknowledged packet is removed from the retransmission buffer 4040 at step 1140, i.e. from the first or second buffer portion 800/810 depending on whether it is a packet sent recently or not. The process then loops back to step 1120.
In case of negative acknowledge, the copy packet corresponding to the negatively acknowledged packet is transferred from the first or second buffer portion 800/810 (depending on whether it is a packet sent recently or not) to the third buffer portion 820 storing the copy packets to be retransmitted, at step 1150. The copy packet as stored in 820 has the same compression level as the copy packet as stored in 800 or 810 before the transfer. Next to step 1150, the process loops back to step 1120.
Once all the packets referred to in the acknowledge message 203 have been processed, the first and second buffer portions 800/810 have been freed of the corresponding copy packets. The process then continues at step 1160 where the compression level to apply to the second buffer portion 810 is reset to the initial compression level.
An efficient design of the buffer portions may ensure the second buffer portion to be empty when finishing the processing of each acknowledge message. In other words, the first buffer portion should be able to contain at least the number of uncompressed packets that are sent between the time at which the acknowledge message is generated by the receiving device and the time at which step 1160 is performed (that is, sent messages that are not acknowledged in message 203).
The process then loops back to step 1110, waiting for a new acknowledge message from the receiving device 120.
In parallel to the process, the transmitting device 140 uses the retransmission frame 204 provided after the acknowledge message 203 to retransmit the copy packets stored in the third buffer portion 820.
Figure 11 illustrates, in a flowchart, general steps of a communication method at the receiving device 120.
Starting from an initial state 1200, the receiving device 120 determines whether or not new video data are received from the transmitting device 140 over the communication network 101. This is step 1210 performed by module 4510.
When a new packet of video data is received, the receiving device 120 performs error detection on the received packet to determine whether or not it has been received with error. This is step 1220 performed by module 4520.
If it has been received without error, step 1230 consists in transferring the received packet to an upper layer to decode it with the view of displaying the video data. The process then loops back to step 1210 for processing the next received packet.
If it has been received with error, the process continues at step 1240 where the receiving device 120 determines a retransmission time point at which the transmitting device 140 should retransmit the copy packet corresponding to the erroneous received packet based on a target compression level as well as possibly on the number of erroneous packets that are detected (burst approach as explained above). This step is performed by module 4560.
Knowing the retransmission buffer management of the transmitting device (as explained above with reference to Figure 8), the receiving device is able to determine when the corresponding copy packet will be stored in 810 with the compression level equal to the target compression level. This is the retransmission time point.
As shown in the Figure, the target compression level may be determined at a previous step 1250 (by module 4550) that may be performed periodically when waiting new packets at step 1210. This target compression level is determined based on actual retransmission bandwidth availability, i.e. T11 less the bandwidth already used in the current superframe for sending the acknowledge messages and for the retransmission of packets.
Next to step 1240, the receiving device 120 schedules the sending of the negative acknowledge of the received packet at a sending time depending on the retransmission time point obtained at step 1240. This is step 1260 performed by module 4570 to notify the transmitting device 140 of the erroneous reception of the packet and then to request it to retransmit the packet. Selecting the sending time based on the retransmission time point ensures the packet to be compressed according to the target compression level when transferred in buffer portion 820 for retransmission.
The sending time of the acknowledgement message may be obtained from the obtained retransmission time point less a sending delay obtained at step 1270. The sending delay represents the time needed for the acknowledge message to be received and processed by the transmitted device 140. It may be empirically determined based on network communication parameters and conventional processing systems.
Next to step 1260, the acknowledgement message is sent to the transmitting device 140 at the appropriate sending time, however requiring that a short guard interval Tsuard expire after the end of a time slot (as shown in Figure 2). This is step 1280 performed by module 4530.
The process then loops back to step 1210 for processing the next received packet.
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 which lie within the scope of the present invention will be apparent to a person skilled in the art. 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 as determined by the appended claims. In particular different features from different embodiments may be interchanged, where appropriate.

Claims (26)

  1. CLAIMS1. A method of communicating video data over a communication network, the method comprising, at a sending device: sending packets of video data to a receiving device; storing a copy of each sent packet in a resending buffer of the sending device while waiting for an acknowledge message thereof from the receiving device; further to receiving a negative acknowledge message from the receiving device for at least one sent packet, resending said at least one sent packet to the receiving device; wherein at least one copy packet in the resending buffer is compressed, and the compression level of the at least one packet copy varies over time during its or their storage in the resending buffer.
  2. 2. A method of communicating video data over a communication network, the method comprising, at a receiving device: determining a target compression level for a sending device to send at least one packet of video data to the receiving device, said determining being based on transmission bandwidth available in the communication network; determining a sending time point for the sending device to send the at least one packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in a buffer of the sending device; and scheduling the sending of a message requesting the sending device to send the at least one packet, at a requesting time based on the determined sending time point; and following the sending of the message, receiving the at least one packet from the sending device.
  3. 3. The method of Claim 1 or 2, wherein the buffer at the sending device comprises a first buffer portion to store uncompressed copy packets and a second buffer portion to store compressed copy packets at the compression level varying over time.
  4. 4. The method of Claim 3, wherein the first buffer portion is used to store copy packets of the packets the most recently sent by the sending device and the second buffer portion is used to store copy packets of older sent packets.
  5. 5. The method of Claim 3, further comprising, if the first buffer portion is full when a new packet is sent by the sending device, moving the oldest copy packet of the first buffer portion to the second buffer portion to free space for storing a copy packet of the newly sent packet, said moved oldest copy packet being compressed at the compression level for storage in the second buffer portion.
  6. 6. The method of Claim 3, further comprising, if the second buffer portion is full when a new copy packet is to be stored in the second buffer portion, increasing the compression level used for the storage of the compressed copy packets therein.
  7. 7. The method of Claim 6, further comprising, when the compression level is increased, modifying the compression of the copy packets already stored in the second buffer portion to the increased compression level.
  8. 8. The method of Claim 1 or 2. wherein the compression level varying over time is selected from a set of compression levels corresponding to the removal of a respective number of least significant bits in components of the video data making the packets.
  9. 9. The method of Claim 1 or 2, wherein the time-varying compression level depends on a size of the buffer and on the number of video data packets sent for first time by the sending device since a last reset of the compression level and stored in the buffer.
  10. 10. The method of Claim 1, further comprising upon receiving an acknowledge message from the receiving device, resetting the compression level to an initial compression level.
  11. 11. The method of Claim 10, wherein a copy packet of a sent packet positively acknowledged in the acknowledge message is removed from the resending buffer; and a copy packet of a sent packet negatively acknowledged in the acknowledge message is moved from a buffer portion of the resending buffer to a third buffer portion of the resending buffer.
  12. 12. The method of Claim 2. wherein the access to the communication network by the sending device is driven by a medium access scheme defining a plurality of superirames, each superl'rame comprising a defined number of frames for sending packets of video data for first time; and the method further comprises calculating the bandwidth defined between the superframe and the number of frames therein, less the bandwidth used for sending acknowledge messages and for resending packets already sent during the current superframe, to obtain the available transmission bandwidth.
  13. 13. The method of Claim 2, wherein the determining of a target compression level is also based on a Packet Error Rate measured by the receiving device on packets received from the sending device.
  14. 14. The method of Claim 2, wherein the requesting time point is computed from the determined sending time point and an estimate of a sending delay for the requesting message to be sent from the receiving device to the sending device.
  15. 15. The method of Claim 2, wherein the at least one packet corresponds to an erroneous packet received from the sending device, and the sending of the requesting message is postponed as long as a ratio between a number of erroneous received packets and a number of received packets is above a predefined threshold.
  16. 16. A communication device comprising: a sending module for sending packets of video data to a receiving device over a communication network; a resending buffer for storing a copy of each sent packet therein while waiting for an acknowledge message thereof from the receiving device; a resending module for resending at least one sent packet to the receiving device, further to receiving a negative acknowledge message from the receiving device for said at least one sent packet; wherein at least one copy packet in the resending buffer is compressed, and the compression level of the at least one packet copy varies over time during its or their storage in the resending buffer.
  17. 17. The communication device of Claim 16, further comprising a buffer controller configured to: if a first buffer portion of the resending buffer is full when a new packet is sent by the sending module, moving the oldest copy packet of the first buffer portion to a second buffer portion of the resending buffer to free space for storing a copy packet of the newly sent packet, said moved oldest copy packet being compressed at the compression level for storage in the second buffer portion, and if the second buffer portion is full when a new copy packet is to be stored in the second buffer portion, increasing the compression level used for the storage of the compressed copy packets therein.
  18. 18. The communication device of Claim 17, wherein the buffer controller is further configured to, when the compression level is increased, modify the compression of the copy packets already stored in the second buffer portion to the increased compression level.
  19. 19. The communication device of Claim 17, wherein the buffer controller is further configured to select the compression level varying over time from a set of compression levels corresponding to the removal of a respective number of least significant bits in components of the video data making the packets.
  20. 20. A communication device comprising: a compression level determining module for determining a target compression level for a sending device to send at least one packet of video data to the communication device over a communication network, said determining being based on transmission bandwidth available in the communication network; a sending time point determining module for determining a sending time point for the sending device to send the at least one packet, said determining being based on the determined target compression level and on a compression function defining a time-varying compression level at which copies of packets are compressed during their storage in a buffer of the sending device; a scheduler for scheduling the sending of a message requesting the sending device to send the at least one packet, at a requesting time based on the determined sending time point; and a receiver for receiving, following the sending of the message, the at least one packet from the sending device.
  21. 21. The communication device of Claim 20, wherein the access to the communication network by the sending device is driven by a medium access scheme defining a plurality of superframes. each superirame comprising a defined number of frames for sending packets of video data for first time; and the communication device further comprises an available bandwidth determining module configured to calculate the bandwidth defined between the superframe and the number of frames therein, less the bandwidth used for sending acknowledge messages and for resending packets already sent during the current superframe, to obtain the available transmission bandwidth.
  22. 22. The communication device of Claim 20, wherein the compression level determining module, the sending time point determining module, the scheduler and an estimator of a sending delay for the requesting message to be sent from the communication device to the sending device are separate hardware components.
  23. 23. A video communication system comprising a communication network and at least one communication device of Claim 16 acting as a sending device and one communication device of Claim 20 acting as a receiving device that communicate together over the communication network, wherein the receiving device further comprises: a receiver for receiving the packets of video data sent by the sending device; a check module for identifying at least one erroneous received packet amongst the received packets; an acknowledgment module for sending an acknowledge message requesting the sending device to resend the packet corresponding to the at least one erroneous received packet; wherein the determining by the compression level determining module and the sending time point determining module is performed for the at least one erroneous received packet so that the sending device resends the packet corresponding to the at least one erroneous received packet, wherein the available transmission bandwidth is a channel bandwidth available for resending packets corresponding to erroneous received packets, and the scheduled message is an acknowledge message.
  24. 24. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a communication device of a communication network, causes the communication device to perform the steps of the method of Claim 1 or 2.
  25. 25. A method of communicating video data substantially as herein described with reference to, and as shown in, Figures ba and lob; Figure 11 of the accompanying drawings.
  26. 26. A communication device substantially as herein described with reference to, and as shown in, Figure 7a; Figures 7a and 8; Figure 7b of the accompanying drawings.
GB1215045.4A 2012-08-23 2012-08-23 Method of communicating video data over a communication network, associated devices and system Active GB2505225B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1215045.4A GB2505225B (en) 2012-08-23 2012-08-23 Method of communicating video data over a communication network, associated devices and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1215045.4A GB2505225B (en) 2012-08-23 2012-08-23 Method of communicating video data over a communication network, associated devices and system

Publications (3)

Publication Number Publication Date
GB201215045D0 GB201215045D0 (en) 2012-10-10
GB2505225A true GB2505225A (en) 2014-02-26
GB2505225B GB2505225B (en) 2014-12-03

Family

ID=47045295

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1215045.4A Active GB2505225B (en) 2012-08-23 2012-08-23 Method of communicating video data over a communication network, associated devices and system

Country Status (1)

Country Link
GB (1) GB2505225B (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3386194A1 (en) * 2017-04-04 2018-10-10 Thomson Licensing Method of delivery audiovisual content and corresponding device
WO2020043114A1 (en) * 2018-08-31 2020-03-05 华为技术有限公司 Data transmission method and related apparatus
CN113126885A (en) * 2020-01-14 2021-07-16 瑞昱半导体股份有限公司 Data writing method, data reading method and storage device

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128776A (en) * 1989-06-16 1992-07-07 Harris Corporation Prioritized image transmission system and method
US5621820A (en) * 1994-03-03 1997-04-15 Radius Inc. Video data compression method and system which measures compressed data storage time to optimize compression rate
US20070296822A1 (en) * 2006-06-09 2007-12-27 Yin-Chun Blue Lan Method and device for wireless video communication
US20110149790A1 (en) * 2008-08-25 2011-06-23 Tetsuo Mabuchi Communication device and header compression control method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128776A (en) * 1989-06-16 1992-07-07 Harris Corporation Prioritized image transmission system and method
US5621820A (en) * 1994-03-03 1997-04-15 Radius Inc. Video data compression method and system which measures compressed data storage time to optimize compression rate
US20070296822A1 (en) * 2006-06-09 2007-12-27 Yin-Chun Blue Lan Method and device for wireless video communication
US20110149790A1 (en) * 2008-08-25 2011-06-23 Tetsuo Mabuchi Communication device and header compression control method

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3386194A1 (en) * 2017-04-04 2018-10-10 Thomson Licensing Method of delivery audiovisual content and corresponding device
EP3386193A1 (en) * 2017-04-04 2018-10-10 Thomson Licensing Method of delivery of audiovisual content and corresponding device
WO2020043114A1 (en) * 2018-08-31 2020-03-05 华为技术有限公司 Data transmission method and related apparatus
CN113126885A (en) * 2020-01-14 2021-07-16 瑞昱半导体股份有限公司 Data writing method, data reading method and storage device
US11403040B2 (en) * 2020-01-14 2022-08-02 Realtek Semiconductor Corporation Flash memory device that simulates operations of EEPROM and data programming and reading method thereof

Also Published As

Publication number Publication date
GB201215045D0 (en) 2012-10-10
GB2505225B (en) 2014-12-03

Similar Documents

Publication Publication Date Title
US8831091B2 (en) Adaptive wireless channel allocation for media distribution in a multi-user environment
US8422369B2 (en) Transmission and reception system, transmitter, transmission method, receiver, reception method, and program
US20110041024A1 (en) Evolved Universal Terrestrial Radio Access Acknowledged Mode Radio Link Control Status Report for Segmented Protocol Data Units
US20120039391A1 (en) System and method for transmission of data signals over a wireless network
US20120250762A1 (en) System and method for implementation of dynamic encoding rates for mobile devices
US20070234170A1 (en) Method and system for communication of video information over wireless channels
JP2007089176A (en) Method and apparatus for processing control pdu in re-establishing transmitter side in radio communication system
US20070162813A1 (en) Transmitting station, receiving station, communications method, communications program, computer-readable storage medium containing the program
KR101509766B1 (en) Method for sending rlc pdu and allocating radio resource in mobile telecommunications system and rlc entity of mobile telecommunications
KR20190022514A (en) Method and system for video streaming
US20070245387A1 (en) Method and system for video stream transmission over wireless channels
CN105493457A (en) Transmission control protocol (TCP) based video streaming
US20210007008A1 (en) Method and apparatus for data segmentation and reassembly over multiple wireless links
TWI737777B (en) Receiver devices, transmitter devices, methods for controlling a receiver device, methods for controlling a transmitter device, and computer-readable media
KR101889717B1 (en) Method and apparatus for a resource allocation schduling in a wireless communication system
US20160157230A1 (en) Transmission protection
US9614883B2 (en) Method and device for transmitting uncompressed video streams
US11133898B2 (en) Retransmission handling at TTI length switch
US20130290803A1 (en) Variable acknowledge rate to reduce bus contention in presence of communication errors
US20120331241A1 (en) Adaptive Control For Efficient HARQ Memory Usage
GB2505225A (en) Retransmission of video packets at time-varying compression levels
JP2007129723A (en) Method and apparatus for processing protocol error in radio communication system
US9882822B2 (en) Data frame sending method and apparatus
US20090245223A1 (en) Techniques for reducing buffer overflow in a communication system
US9246638B2 (en) Method and apparatus for polling transmission status in a wireless communications system