KR20020046770A - Method of RTP Packetization for Video Streams - Google Patents

Abstract

PURPOSE: A method of packetizing RTP of a video stream is provided to minimize definition of payload format so as to reduce additional overhead and to secure independent encoding of an unpacketized video stream. CONSTITUTION: The size of RTP packet having variable size is determined. An input video stream is assigned in bytes such that the video stream is accepted in maximum in accordance with the size of a payload based on the determined size of the RTP packet. It is indicated if continuous RTP packets correspond to information about the same video stream or information about different video streams. The assigned video stream is accepted in the RTP packet payload and the indicated information is accepted in the RTP packet header.

Description

Method of RTP Packetization for Video Streams

The present invention relates to an Altipi packetization method of a video stream when using the RTP protocol for transmission and reception of a video stream in a video transmission system, and to a computer readable recording medium having recorded thereon a program for realizing the method.

MPEG-4 is an ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) standard that defines digital bit stream formats and related protocols for representing real-world audio, video, and object data as multimedia content.

International image compression standards, such as the existing H.261 / 3 standard, M-JPEG standard, MPEG-1, and MPEG-2 standard, are independent of the content contained in the input image. There is a limit to the performance by performing data compression based only on the pixel value of the image. Therefore, it is difficult to satisfy all the various functions required in the application fields of various multimedia services such as communication, broadcasting, and computer.

However, MPEG-4 adopts a content-based coding method with high compression efficiency, unlike the existing standard that simply performs block-by-block coding. It uses coding techniques that can be used over a wide range of bandwidths, up to high bandwidths.

Content-based encoding method based on understanding the content of the video is processed by the video content divided by each object (Object), so that it is possible to compress, play, transmit, and manipulate data in the unit of the object, the quality of service It is possible to control or display various forms according to the intention of the user by using a scalable processing technology that can adjust the function. Therefore, in MPEG-4, the contents of the service to be used can be manipulated more actively according to their own preferences to create an environment suitable for them.

For this reason, the application of MPEG-4 image compression technology is more suitable for high quality multimedia application services than conventional image compression technology. In addition, the hierarchical characteristics of the MPEG-4 terminal system enable free access through various transmission media and transparent transmission of streams, and are well suited for error environments such as mobile communication networks and the Internet because they are highly resistant to transmission errors. Do.

Since the MPEG-4 system has information such as timing and sequence number, it is best to transmit the MPEG-4 video stream over the user datagram protocol / Internet protocol (hereinafter referred to as "UDP / IP"). Looks like a simple and easy way. But there are some problems here.

First, MPEG-4 video streams transmitted directly over User Datagram Protocol (UDP) are incapable of synchronizing with other types of multimedia data streams. It cannot be extended to data that is not processed by) -4. For this reason, transmission of MPEG-4 video streams over User Datagram Protocol (UDP) has a problem in matching with data not processed by MPEG-4.

Second, MPEG-4 generated from two servers in a multicast session does not provide a method for synchronizing MPEG-4 streams from different servers on the Internet with variable delays. Streams can collide. MPEG-4 requires feedback control, but pure User Datagram Protocol (UDP) does not provide this algorithm.

For this reason, Real Time Protocol (RTP) is recognized as a suitable protocol for transmitting MPEG-4 video streams on the Internet, and the advantages of using RTP are as follows.

First, it is possible to synchronize MPEG-4 video streams with other RTP payloads and to monitor transmission performance through the Real Time Control Protocol (RTCP).

Secondly, MPEG-4 video streams can integrate other real-time data streams received from multiple terminals using an RTP mixer, and can also convert data types via RTP translation routines.

The existing RTP payload format for MPEG-4 elementary streams generated from MPEG-4 encoders is IETF Internet Draft (Kikuchi, Nomura, Fukunaga, Kimara, Matsui, RTP payload). format for MPEG-4 Audio / Visual streams, Internet Draft, Internet Engineering Task Force, Sep. 2000), which is a MPEG that can have a hierarchical structure generated from an MPEG-4 encoder. ) -MPEG-4 video streams that do not use the MPEG-4 system's synchronization and stream management capabilities by mapping elementary streams directly to RTP payloads. It is a format suitable for the following. However, the method has the following problems.

First, by considering the MPEG-4 elementary stream having a hierarchical structure, each payload format for each elementary stream should be defined. This is a burden of maintaining information on various payload formats at the transmitter and the receiver.

Secondly, there is an overhead that the transmitting end must indicate which layer of the MPEG-4 elementary stream the data of the RTP payload belongs to, and conversely, the receiving end receives the RTP. It is necessary to find out which layer of the MPEG-4 elementary stream is the payload data of the packet.

Third, despite the above overhead, the MPEG-4 decoder actually corresponds to the base layer that constitutes one complete MPEG-4 elementary stream. Decryption is not possible until all data is constructed. Therefore, in consideration of the hierarchical structure of the MPEG-4 elementary stream while taking such overhead, defining and managing various RTP payload formats has its limitations.

The present invention has been proposed to solve the above problems, and defines only an RTP payload format for a video object corresponding to a base layer that is a base unit of decoding. Altipi packetization method of video streams to minimize additional overhead by minimizing the definition of payload format and ensure independent decoding of unpacketized video streams, and a program for realizing the method Its purpose is to provide a computer readable recording medium having recorded thereon.

1 is an exemplary configuration diagram of a communication network to which the present invention is applied.

2 is a structural diagram of an embodiment of a transfer unit in a general protocol stack.

3 is a structural diagram of an embodiment of an RTP packet according to the present invention;

4 is a flowchart of an embodiment of a method for packetizing a video stream according to the present invention.

* Explanation of symbols for the main parts of the drawings

101: image acquisition unit 102: MPEG-4 elementary stream encoder

103: RTP packetizing unit 104: transmitting unit

105: receiving unit 106: RTP packet recovery unit

107: MPEG-4 element stream decoder

108: video playback unit

According to an aspect of the present invention, there is provided a method of determining a size of an RTP packet having a variable size in a method of packetizing a real time protocol (RTP) packet of a video stream to which an RTP packetization apparatus is applied. Stage 1; A second step of allocating the input video stream in units of bytes large enough to accommodate the payload according to the determined size of the RTP packet; A third step of indicating whether consecutive RTP packets are information on the same video stream or information on another video stream; And a fourth step of accommodating the allocated video stream in an RTP packet payload and accommodating the indication information in an RTP packet header.

On the other hand, the present invention, the RTP packetization device having a large processor, the first function for determining the size of the RTP packet having a variable size; A second function of allocating an input video stream in units of bytes to accommodate a maximum payload size according to the determined size of the RTP packet; A third function of indicating whether successive RTP packets are information about the same video stream or information about another video stream; And a computer readable recording medium storing a program for realizing a fourth function of accommodating the allocated video stream in an RTP packet payload and accommodating the indication information in an RTP packet header.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary configuration diagram of a communication network to which the present invention is applied.

As shown in FIG. 1, the transmitting end of the communication network to which the present invention is applied includes an image acquisition unit 101 for acquiring a natural image, and an MPEG-4 image obtained by the encoder from the image acquisition unit 101. MPEG-4 elementary stream coding unit 102 to encode the elementary stream (Elementary Stream), the MPEG received from the MPEG-4 elementary stream encoder (102) ( An RTP packetizer 103 for receiving an MPEG-4 elementary stream in an RTP packet payload, and a transmitter 104 for transmitting an RTP packet generated by the RTP packetizer 103. do.

The receiving end of the communication network to which the present invention is applied includes a receiving unit 105 for receiving a continuous RTP packet transmitted from the transmitting unit 104 through the Internet, and an MPEG (MPEG) for receiving the RTP packet received from the receiving unit 105. MPEG-4 for restoring each RTP packet so that the decoder can decode it; MPEG for converting the decodable data restored in the RTP packet decompressor 106 into playable video data (MPEG) ) -4 elementary stream decoder 107, and an image playback unit 108 for reproducing the video decoded by the MPEG-4 elementary stream decoder 17; .

The RTP packet size in the present invention is determined according to the characteristics of the underlying protocol, which is 28 bytes in the maximum transmission unit (MTU) specified in IETF RFC 1191 (Internet Engineering Task Force Request For Comment 1191) according to each protocol. Set the same as minus value. This is because the Internet Protocol (IP) header is 20 bytes and the User Datagram Protocol (UDP) header occupies 8 bytes. For example, when using the X.25 protocol, the size of an RTP packet is 548 (576-28) bytes; when using Ethernet, 1472 (1500-28) bytes is the size of an RTP packet. In addition, the RTP header is at least 16 bytes, but is set to 20 bytes in consideration of the extension header. Therefore, the size of the RTP packet payload becomes a portion excluding the space used for various header information in the maximum transmission unit (MTU).

2 is a structural diagram of an embodiment of a transfer unit in a general protocol stack.

As shown in FIG. 2, an MPEG-4 compression layer 210, an RTP layer 220, a UDP layer 230, and an IP layer are provided. Layer 240 represents each layer of the protocol stack.

The MPEG-4 compression layer 210 generates MPEG-4 data 211, and the RTP layer 220 generates the MPEG-4 compression layer. The RTP header 221 is attached to the MPEG-4 data 211 generated by the 210. In the UDP layer 230, a UDP header 231 is attached to the RTP header 232 and the MPEG-4 data 233 made in the RTP layer 220. The IP layer 240 adds an IP header 241 to the structure of the UDP header, the RTP header, and MPEG-4 data generated in the UDP layer 230.

The process proceeds in order from the MPEG-4 compression layer 210 to the IP layer 240, in particular, the size of the structure created in the IP layer must be smaller than the maximum transmission unit (MTU).

The MPEG-4 data 211, 222, 233, and 244 represent an MPEG-4 video stream which is actual paid information, and the information becomes an RTP payload portion.

The RTP headers 221, 232, and 243 represent the header portion of the RTP packet and have a size of 20 bytes in consideration of the extended header.

UDP headers 231 and 242 denote UDP packet headers, and IP header 241 denotes IP packet headers.

Meanwhile, the present invention does not consider the hierarchical structure of MPEG-4 elementary streams, and RTP for a video object corresponding to a base layer serving as a base unit of decoding. By defining only the payload format, it minimizes the definition of the payload format, reducing additional overhead, and defining only the payload format for the video object, thereby unpacketized. This is to ensure independent decoding of the video stream.

3 is a structural diagram of an embodiment of an RTP packet according to the present invention.

The strategy of defining the RTP payload format for the Video Object, which is the base layer of the MPEG-4 Elementary Stream, is as follows.

First, in one packet, only information about one video object is stored to exclude the dependency between the video objects.

Second, if the video object is the same size or smaller than the payload portion of the packet, the video object is packetized into one packet.

Third, if the video object is larger than the payload portion of the packet, the video object is packetized by the payload size of the packet. Thereafter, this process is repeated until there is no remaining portion of the unpacked video object. The marker bit of the RTP header is used to indicate whether a subsequent packet is information about the same video object. That is, if the marker bit is 0, successive packets indicate information about the same video object, and if 1, subsequent packets indicate information about another video object.

Fourth, the minimum unit for packetization is in bytes. That is, the byte alignment method is used by packetizing as many bytes as possible in the RTP payload.

Fifth, even if there is available space because the payload portion of the packet containing the last part of the video object is not occupied, the packetization for another video object is not included in this packet. Instead, it fills the rest with padding bytes. This is to maintain independence between adjacent video objects.

An example of a packetization algorithm based on the RTP payload format definition strategy is as follows.

[algorithm]

procedure packetize;

begin

while (there is encoded data to be packetized) do

begin

search next VO_start_code

and count the number of bytes;

if ((next VO_start_code is found) and (ByteCount MaxPL))

then packetize the bytes before next VO_start_code);

else if (ByteCount> MaxPL)

then packetize as many bytes as possible without exceeding MaxPL

and crossing into next VideoObject;

else packetize the remaining data;

end; {of while}

end; {of packetize}

The parameters and functions used in the above [Algorithm] are as follows.

"ByteCount" is the total number of bytes of the video object currently being packetized, and after one RTP packet is completed, the total number of bytes is decreased.

"Maximum Payload Length (MaxPL)" means an acceptable payload length in one packet.

"VO_start_code" means a start code of a video object.

As shown in FIG. 3, the video object headers 312 and 322 and the video objects 313, 323, and 325 correspond to MPEG-4 data 205. In this regard, the VO header indicates a header of a video object in an MPEG-4 video stream.

In the drawing, the "310" structure is a model that can be used when all the information about one video object can be accommodated in one packet, and the "320" structure is one video object in one packet. It is a model that divides the information into segments when it cannot accommodate all of the information about). In this case, even if there is an available space for another video object in the last packet having information about the same video object, padding is maintained to maintain independence between adjacent video objects. Fill it with bytes.

4 is a flowchart illustrating a method of packetizing a video stream according to the present invention.

First, a continuous video object is input (401), and a start code of the input video object is searched (402). The remaining number of bytes (ByteCount) that have not been packetized of the video object to be processed now is calculated (403), and the number of bytes that have the start code of the next video object and the packetization of the video object has not been performed (ByteCount). It is determined whether is less than or equal to the maximum value MaxPL of the payload length (404).

As a result of the determination 404, if there is a start code of the next video object and the number of bytes (ByteCount) which has not performed packetization of the video object is less than or equal to the maximum value of the payload length MaxPL, the video until the next video object start code. The process proceeds to step 409 of packetizing the object and checking whether there is more video data to packetize. At this time, the next video object is not put in the same packet.

As a result of the determination 404, if there is a start code of the next video object and the number of bytes (ByteCount) not performing packetization of the video object is less than or equal to the maximum value of the payload length (MaxPL), the payload length Packetization is performed as many bytes as possible without exceeding the maximum value MaxPL (406). In operation 407, it is determined whether the remaining byte count (ByteCount) which has not been packetized of the video object is larger than the maximum value MaxPL of the payload length.

As a result of the determination 407, if the number of remaining bytes (ByteCount) which has not been packetized of the video object is larger than the maximum value of the payload length MaxPL, possible bytes within the range not exceeding the maximum value of the payload length MaxPL The process proceeds to step 406 where packetization is performed by the number of packets.

As a result of the determination (407), if the remaining number of bytes (ByteCount) not performing packetization of the video object is not greater than the maximum value (MaxPL) of the payload length, the remaining unpacked data of the video object is packetized (408). In step 409, it is determined whether there is more video data to packetize. Again, the next video object is not put in the same packet.

On the other hand, it is checked whether there is more video data to be packetized (409). If there is video data to be packetized, the process proceeds to step 402 of retrieving the start code of the video object, or ends.

As described above, the method of the present invention may be implemented as a program and stored in a recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.) in a computer-readable form.

The present invention described above is not limited to the above-described embodiments and the accompanying drawings, and various substitutions, modifications, and changes are possible in the art without departing from the technical spirit of the present invention. It will be apparent to those of ordinary knowledge.

As described above, the present invention eliminates the disadvantages of using pure UDP by using RTP as a protocol for transmitting a video stream in order to provide a high quality image in the Internet where various connection environments exist, and a basic unit of decoding. By defining only the RTP payload format for the Video Object corresponding to the base layer, the minimum definition of the payload format is minimized, thereby reducing additional overhead and restoring ( It is effective to ensure independent decoding of an unpacketized video stream.

In addition, the present invention has the effect of establishing a transmission system that guarantees high-quality video and real-time on the Internet using a video stream and RTP.

Claims (7)

In the Real Time Protocol (RTP) packetization method of a video stream applied to an RTP packetizer, Determining a size of an RTP packet having a variable size; A second step of allocating the input video stream in units of bytes large enough to accommodate the payload according to the determined size of the RTP packet; A third step of indicating whether consecutive RTP packets are information on the same video stream or information on another video stream; And A fourth step of accommodating the allocated video stream in an RTP packet payload and accommodating the indication information in an RTP packet header Real Time Protocol (RTP) packetization method of a video stream comprising a. The method of claim 1, The second step, A fifth step of retrieving the start code of the input video stream and calculating the number of bytes not performing packetization of the video stream; A sixth step of determining whether there is a start code for a next video stream of the video stream, and whether the remaining number of bytes which have not performed packetization of the video stream is less than or equal to a payload length maximum value; A seventh step of packetizing the video stream before the next video object start code if the remaining number of bytes is less than or equal to the maximum payload length as a result of the sixth step; And An eighth step of performing packetization according to the size of the video stream if the remaining bytes are greater than the maximum payload length as a result of the determination of the sixth step RTP packetization method of a video stream comprising a. The method of claim 2, The eighth step, A ninth step of packetizing as many bytes as possible without exceeding a maximum value of the payload length; A tenth step of determining whether the number of remaining bytes which have not performed packetization of the video object is greater than the maximum payload length value; And As a result of the determination of the tenth step, if it is large, the process goes to the ninth step, and if it is not large, the eleventh step of packetizing the remaining unpacked data of the video object. RTP packetization method of a video stream comprising a. The method of claim 1, The display information of the third step, A method of RTP packetization of a video stream, characterized by indicating whether consecutive RTP packets are the same video stream or different video streams using marker bits. The method according to any one of claims 1 to 4, The packetization process, RTP packetization method of a video stream, characterized in that only one information about the same video object is stored in one packet to exclude the dependency between the video objects. The method according to any one of claims 1 to 4, The RTP packet is, A method of RTP packetization of a video stream, in which an RTP payload format is defined only for a video object which is a base layer to minimize additional overhead in RTP packetization and ensure independent decoding. In the ALTP packetization device having a large capacity processor, A first function of determining a size of an RTP packet having a variable size; A second function of allocating the input video stream in units of bytes large enough to accommodate the payload according to the size of the determined RTP packet; A third function of indicating whether successive RTP packets are information about the same video stream or information about another video stream; And A fourth function of accommodating the allocated video stream in an RTP packet payload and accommodating the indication information in an RTP packet header A computer-readable recording medium having recorded thereon a program for realizing this.