Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
2001-03-02
2004-09-14
Vu, Viet D. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S236000, C709S250000, C719S329000
Reexamination Certificate
active
06792470
ABSTRACT:
The present invention relates to a data transmission method and apparatus and more particularly to video streaming applications.
In video and multimedia communications many applications exist in which video streams are delivered over non-reliable channels. Examples of such applications include personal computers, TV apparatus and computer cards, MPEG decoders and boards, multimedia transceiver systems and set-top receiver units, DVD devices, video recorders and CCD cameras, video signal equipment, frame grabbers and image capture boards, industrial and medical imaging products, video printers and projectors, or the like. It will therefore be appreciated that many kinds of video streaming applications in the consumer market as well as professional applications exist both in software and hardware.
A video stream consists of a flow of bit-packets called frames that contain information about the video picture itself as well as some meta information such as time stamps. The frames contain the video information in different formats depending on the video compression. Some of these frames can be used independently, so-called intra-coded frames or I-frames, while others depend on the preceding frame, so-called predictive-coded frames or P-frames.
FIG. 1
illustrates a conventional video streaming system. Video server
110
transmits video data through channel
150
to video client
160
. For this purpose, the video server
110
includes a transmitter buffer unit
130
which receives video frames with nearly no delay from video source application
120
. The bit rate of this internal transmission is only limited by the video source application's bit rate. In the transmitter buffer unit
130
the frames first undergo segmentation, i.e. splitting data packets by lower layer protocols into smaller segments with the number of segments depending on the length of the packet, which is variable and may for instance amount to 200 or 2,000 byte. This segmentation determines one part of the transmission time for the respective packet.
Once the frames have undergone segmentation the segments are sent on the channel in defined time slots according to the available channel bit rate. In unreliable channels 150 bit errors occur and the available channel bit rate varies in time, if the channel is shared by multiple users. This leads to a significant and variable propagation delay.
Access to the channel
150
is given to the transmitter buffer unit
130
by channel access controller
140
. As the bit rate of channel
150
is lower than the bit rate of the video stream received from video source application
120
, those segments which could not be sent are buffered by the transmitter buffer unit
130
in a first-in-first-out (FIFO) queuing discipline. The transmission buffer unit and the channel access controller are isolated entities and totally independent from the video application. Hence, the video source application
120
does not receive any feedback about the status of the frames as to whether they are already sent or whether they are buffered. All data will be sent by the transmitter buffer unit
130
in the order it arrived.
The segments or PDUs (protocol data units) transmitted by the video server
110
are received by the video client
160
in a receiver buffer unit
170
. The receiver buffer unit
170
includes a buffer for storing the received data, and also reassembles the frames from the segments. The video frames are then sent to video display application
180
which might for example likewise be a storage device or the like.
Two main problems occur in video transmissions over unreliable links. The first problem is that because of changes in the channel condition, the bit error rate may increase such that packet loss occurs. Since compressed video streams are extremely susceptible for packet loss, the video quality is decreased dramatically. The second problem may arise from the variable and sometimes very high delay of the video data which might lead to situations in which the delay requirements for the transmission are no longer fulfilled and the video performance again is decreased dramatically.
For reducing the packet loss several mechanisms exist in the prior art. One of these mechanisms is a method called automatic repeat request (ARQ), according to which the loss of a packet is detected in the receiver and the transmitter is informed accordingly. The transmitter then automatically repeats the transmission of the lost packet so that missing video frames are retransmitted. However, not all of the lost packets can be retransmitted because of the delay requirements and/or limited bandwidth of the transport channel. Moreover, such prior art systems lead to a higher delay which might not be tolerable in any case.
A prior art system for overcoming the second problem, i.e. the occurrence of a variable and sometimes very high channel delay, is called Real-Time Transport Protocol (RTP). To control the display times and cope with the real time requirements, this protocol adds some information to the video frames such as time stamps and sequence numbers, encapsulated in RTP packets. This information is used to send the video frames at the right time and in correct sequence. The receiver may perform some measurements, e.g. of delay jitter, and may signal the results to the source by means of the RTP control protocol (RTCP).
One approach to deal with both problems, i.e. packet loss and channel delay, is to improve the RTP technique such that only the I-frames are retransmitted and that before sending any frame a judgement is made whether the retransmitted I-frame would still arrive in time. Such integration of retransmission mechanisms in the RTP technique can be for instance done by using multi-purpose acknowledgement (MACK) packets which can be extended by protocol-specific fields. By restricting retransmission to I-frames and introducing a timer-based judgement for deciding whether to send a frame or to discard it, both problems are addressed, leading to an increased video quality because more frames can be displayed. The delay is kept in a reasonable range by discarding “old” frames, i.e. frames that would be received after expiration of their display time.
Such systems however, would have a significant degree of inadaptability because the retransmissions are limited to the I-frames even when enough free bandwidth is available to retransmit all frames. In certain channel conditions many correctly received P-frames are discarded at the video client, because the preceding P-frame was not received correctly.
Moreover, such techniques perform poorly because frames are sent which should have been discarded and vice versa. This is because the judgement whether to send a frame or to discard it is based on a fixed estimated transmission time which is set at the beginning of the transmission for every packet and is the same for all the packets, being independent of the channel status and the respective packet length. The fixed estimated transmission time is needed to calculate the time at which the frame would be received.
A similar method for selectively retransmitting missing data packets of a data stream is disclosed in U.S. Pat. No. 5,918,002. Retransmission is prioritized based on data types of the data packets. For example, since parent I-frames are needed to render dependent child P-frames, data packets which include I-frames are assigned higher priority for transmission and/or retransmission over data packets which include only P-frames. Moreover, the sequence of retransmission requests is priority-dependent.
Another technique which is concerned with resuming playback taking into consideration the different importance of I- and P-frames is disclosed in U.S. Pat. No. 5,784,527.
In U.S. Pat. No. 5,768,527 it is disclosed that upon detection of a lost packet the client device requests a number of multiple copies of the lost packet, with said number depending on the importance of the lost frame.
The mentioned prior art, however, leads to the above-described disadvantages when transmitting vi
Burmeister Carsten
Hakenberg Rolf
Wiebke Thomas
Matsushita Electric - Industrial Co., Ltd.
Vu Viet D.
Wenderoth , Lind & Ponack, L.L.P.
LandOfFree
Method and apparatus for communicating with data frames... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for communicating with data frames..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for communicating with data frames... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3268731