KR20000044325A - Method for recovering lost packet of data for video on demand service - Google Patents

Abstract

PURPOSE: A method for recovering a lost packet of data for VOD(Video On Demand) service is provided to control the compression data flow and to enhance the reconstitution rate of packet loss and sequence error of compression data. CONSTITUTION: A method for recovering a lost packet of data for VOD service comprises the steps of;buffering the packet of H.323 RTP(Real time Transfer Protocol) data for the constant time(301);monitoring the RTP data buffered in the step(301)(302);checking the sequence of the respective packet and readjusting the sequence of packet when the sequence error is generated(303);checking the linear sequence number(304);judging whether the packet loss is generated for the step(304)(305);and analyzing the character of the former packet and latter packet and reconstituting the lost packet of data, by using the time stamp information in header of RTP data when the packet loss is generated(306,307).

Description

How to Recover Lost Packets of Data for On-Demand Video Services

The present invention relates to a communication system for providing a non-guaranteed query service, and more particularly to a method for recovering packet loss of compressed data for an on-demand video service.

For communication systems, such as LANs (LANs) that provide non-guaranteed query services in general, the recommendations of the International Telecommunications Union-Telecommunication sector (ITU-T) H.323 titled "Packet based multimedia communications system (Visual telephone systems and equipment for local area network which provide a non-guaranteed quality of service). In such a communication system, compressed data transmitted through an H.323 Real Time Transport Protocol (RTP) over User Datagram Protocol (UDP) port is transferred to an H.323 VOD set-top box for video on demand (VOD) service. Can be received and played back. At this time, compressed data may include voice data such as PCM (Pulse Coded Modulation) and Vocoder, and may include Common Intermediate Frequency (CIF), Quarter Common Intermediate Frequency (QCIF), and S Quarter Common Intermediate Frequency (SQCIF). There may be video data such as.

On the other hand, voice / video compressed data transmitted through UDP on the LAN is effective for data transmission requiring real time due to the characteristics of UDP, but data flow control is not possible. This means that even if a packet loss occurs or an out of order sequence packet occurs, there is no countermeasure for an application requiring real time data transmission.

Accordingly, an object of the present invention is to provide a method for controlling flow of compressed data for a VOD service in a communication system that provides an insured query service.

Another object of the present invention is to provide a method for recovering packet loss and sequence error of compressed data for a VOD service in a communication system providing an insured query service.

The present invention is to recover the packet loss of the data received in the VOD set-top box that meets the H.323 standard, using the fact that the data for the VOD service is not significant for real-time transmission . Voice / video data transmitted through the Internet is buffered for a predetermined time (about 10 to 20 seconds) in the set-top box and then transmitted to the user terminal. The receiving set-top box buffers the received voice / video data for a predetermined time and uses the time stamp and sequence number of the buffered RTP header data to drop the lost packet of the voice and video data. Restore it. Here, the packet of the lost voice and video data can be recovered. Since the voice and video data which are instantaneously changed are not largely changed, the lost packet can be recovered using the data characteristics of the front and back packets. At this time, the user can receive and view all packet data provided by the VOD server without any inconvenience (time delay).

According to the present invention, a method for recovering lost packets of data for a VOD service; A first process of receiving H.323 standard RTP data and buffering for a predetermined time, and checking the sequence number included in the header of the buffered RTP data and resequencing the packet when a sequence error occurs. In the case where packet loss occurs during the second step of checking and checking the linear sequence number, the data characteristics of the previous packet and the subsequent packet are analyzed using the time stamp information included in the header of the RTP data, and the data of the packet loss is restored. It is characterized by consisting of a third process.

Preferably, the predetermined time may be set to 10 to 20 seconds, or may be set to a time required to buffer a packet of 1024 bytes.

Preferably, when the buffered RTP data is voice data of the PCM, data of packet loss may be restored to a median characteristic of a previous packet and a subsequent packet. In contrast, when the buffered RTP data is voice data or video data of a vocoder, data of packet loss may be restored by performing an exclusive OR on the previous packet and the subsequent packet.

1 is a diagram illustrating a configuration of a set-top box having a function of recovering lost packets of data for an on-demand video service according to the present invention.

2 illustrates the structure of an RTP header used to recover lost packets in the present invention.

FIG. 3 shows a process flow for recovering lost packets of data for video on demand services in accordance with the present invention. FIG.

4 is a diagram for explaining the principle of recovering lost packets of PCM voice data according to the present invention;

DETAILED DESCRIPTION A detailed description of preferred embodiments of the present invention will now be described with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. In addition, the terms to be described below are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of the user or chip designer, and the definitions should be made based on the contents throughout the present specification.

First of all, the present invention is a technique for recovering packet loss of data received in a VOD set-top box that meets the H.323 standard, and utilizes the fact that data provided for a VOD service does not have much meaning for real-time data transmission. Even if the set-top box buffers the data for a certain period of time (about 10 to 20 seconds) and transmits it to the user terminal, the user can watch all the packet data provided by the VOD server without any inconvenience. Can be.

More specifically, the receiving set-top box buffers the received voice / video data for a predetermined time and then uses the time stamp and the sequence number among the buffered RTP header data. Can recover lost packets. Here, the packet of lost voice and video data can be recovered because the instantaneous voice and video data does not change much, for example, even if the intermediate 30 millisecond (ms) 1 packet is lost. Data characteristics can be used to recover lost packets. The present invention has no meaning because the user can feel great inconvenience when applied to an H.323 video phone or an Internet gateway, but in an application having a lot of downstream data such as VOD, Packet data can be received without great inconvenience. That is, the present invention can provide a qualitative improvement in processing packet data for a VOD service.

1 is a view showing a configuration of a set-top box having a function of recovering lost packets of data for a VOD service according to the present invention, which is shown in terms of software (S / W). The set-top box according to the present invention is largely a block for processing Real Time Transport Protocol (RTP) video, a block for processing RTP audio, a block for buffering RTP downstream, and a RTP And a block for recovering the downstream lost packets and the sequence error packet, and a block for connecting to the LAN.

In FIG. 1, a video control processor (VCP) 10, a DSP manager 20, and a main DSP 30 process RTP video. In this case, the DSP manager 20 includes an ISR 22 performing a write operation and an ISR 24 performing a read operation. The DSP 40, the DSP manager 50, and the main DSP 60 process RTP audio. In this case, the DSP manager 50 includes an ISR 52 performing a write operation and an ISR 54 performing a read operation. The Multiplexer / Demultiplexer (MUX / DEMUX) 110 is provided for connection to a LAN (or may be INTERNET), and is provided on a User Datagram Protocol (UDP) that is transmitted and received over a LAN. Multiplex and demultiplex stream data. The RTP-Tx 90 transmits the stream data received from the LAN through the MUX / DEMUX 110 to the buffer 70. The RTP-Rx 100 receives and processes stream data from the buffer 80 for transmission to the LAN through the MUX / DEMUX 110. The buffer 70 is provided to receive and buffer the RTP downstream data for a predetermined time and to recover packets of lost packets and sequence errors. Preferably, the buffer 70 buffers the RTP downstream data for about 10 to 20 seconds (or 1024 bytes of packets), wherein the buffer 70 includes a queue for receiving and buffering the downstream data, It may consist of three to recover the packet.

2 is a diagram illustrating the structure of an RTP header used to recover lost packets in the present invention.

The RTP header of the structure as shown in FIG. 2 has been standardized under ITU-T Recommendation H.225 titled "Call signaling protocols and media stream paketization for packet based multimedia communication system". In the present invention, the information of the time stamp and the sequence number of the RTP header is used. In addition to the information used in the present invention, the RTP header includes V, P, X, CC, M, PT, Syncronization SouRCe (SSRC) IDENTIFIER, and CSRC (Contributing SouRCe) IDENTIFIER.

3 is a flowchart illustrating a process of recovering a lost packet of data for an on-demand video service according to the present invention.

Referring to FIG. 3, the packet of the H.323 standard RTP data received through the LAN of FIG. 1 is buffered in the buffer 70 for a predetermined time (step 301). Here, the predetermined time may be set to a time required for buffering a packet of RTP data for about 10 to 20 seconds or a time required for buffering a packet of 1024 bytes. The size of the buffer 70 is adjustable to suit the characteristics of the service. Next, when the buffered RTP data is monitored (step 302) and accumulated by a predetermined packet, the received sequence of each packet is checked (step 303). At this time, there should be at least two buffers for buffering. This is because one should be used for the reception buffer and the other for the recovery of sequence error and lost packets when packets of 1024 bytes are accumulated. After the recovery operation for a packet of 1024 bytes is completed, this buffer is reused for the receiving buffer, and the buffer used for the receiving buffer must be converted to a buffer for recovering the sequence error and lost packets. Also, the sequence number is readjusted. You also need a buffer to do this. If the sequence error occurs by checking the sequence number, it recalibrate each packet according to the sequence.

Due to the characteristics of UDP, the order of packets may be changed. This can be solved by buffering a certain amount of packets due to the characteristics of the VOD service. In step 303, the sequence of packets is rearranged and the sequence of each packet is checked. At this time, the sequence is sequentially increased, the reception packet loss may occur due to the characteristics of UDP transmission (step 305), and the sequence of the lost packet may be found by checking the sequence of the packet. In this case, the packet may be found using the time stamp information in the packet information, and even when the packet is recovered, the data characteristics may be analyzed using the time stamps of the previous packet and the subsequent packet and restored as much as the corresponding time (steps 306 and 307).

When the RTP data is the voice data of the PCM, the packet of the lost data can be estimated by using the characteristic that the width of the voice frequency is small as shown in FIG. 4 due to the characteristics of the PCM data. For example, if b, d, and e are lost in FIG. 4, the intermediate data of a and c may be extracted to generate an expected b packet, and the d and e packets may be generated using characteristics of the intermediate data of c and f. Can be. That is, the lost packets b, d, and e can be restored.

On the other hand, when the RTP data is voice data by vocoder, since only the characteristic data of the voice is transmitted, it is difficult to recover lost packets as in the case of PCM data. Video data is also difficult to recover lost packets since only the converted data is transmitted compared to the previous frame. In this case, for example, A, B, C, D, ... in the data transmission server. When sending a packet of A, {A XOR B; Packets resulting from the exclusive OR of packets A and B}, B, {B XOR C}, C, {C XOR D}, D,... By transmitting data in order, it is possible to recover the lost B packet by using the B XOR C packet and the C packet when the B packet is lost in the middle. This method is applicable to all cases of voice data and video data. However, there is a disadvantage in that a large amount of packets need to be transmitted (more than twice), but this disadvantage is possible if bandwidth is secured. This is also possible due to the characteristics of the VOD service as described above.

As described above, the present invention has an advantage in that the received VOD set-top box receives and buffers H.323 RTP data so that packet sequences can be aligned and lost packets can be recovered. Also, due to the characteristics of the VOD service, real-time data transmission is required, but even delay does not cause any problems in the service. Therefore, buffering H.323 RTP data can restore sequence error and packet loss, and provide more accurate data transmission. There is an advantage to this.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

Claims (5)

A method for recovering lost packets of data for video on demand services, the method comprising: Receiving a H.323 standard RTP data and buffering for a predetermined time; A second step of checking a sequence number included in a header of the buffered RTP data and resequencing a packet when a sequence error occurs; When packet loss occurs during the checking of the linear sequence number, a third process of analyzing data characteristics of the previous packet and the subsequent packet using time stamp information included in the header of the RTP data and restoring the packet loss data is performed. Lost packet recovery method characterized in that. The method of claim 1, wherein the predetermined time is 10 seconds to 20 seconds. The method of claim 1, wherein the predetermined time is a time required to buffer a packet of 1024 bytes. 2. The method of claim 1, wherein when the buffered RTP data is voice data of the PCM, data of packet loss is restored to a median characteristic of a previous packet and a subsequent packet. The method of claim 1, wherein when the buffered RTP data is voice data or video data of a vocoder, data of packet loss is recovered by performing an exclusive OR operation on a previous packet and a subsequent packet.