KR20070121136A - Video data processing method for video telephony service through mobile communication network - Google Patents

Abstract

A method for processing video data for a video telephony service through a wired/wireless communication network is provided to deal with packet loss efficiently during a decoding process of the video data, thereby significantly improving video transmission quality for the video telephony service within a communication terminal. In a method for processing video data for a video telephony service through a wired/wireless communication network, the method comprises the following steps of: initializing a bit sum assignment variable for packetization(S11); encoding packet object data after the above step(S12); receiving a packet loss rate by RTCP(Real-time Transport Control Protocol) from a packet network; varying a size of a packet according to the received packet loss rate(S14); and performing packetization into the varied packet size and transmitting the data(S16).

Description

Video data processing method for video telephony service through mobile communication network}

1 is a view showing a schematic configuration of a wired / wireless communication network for video communication as described above,

FIG. 2 is a diagram illustrating a hierarchical configuration diagram of a communication terminal for a video communication service (video telephony service) through the wired / wireless communication network of FIG. 1;

3 is a graph illustrating packet size adjustment in consideration of an error rate of a network;

4 and 5 are flowcharts illustrating different packetization methods of H.263 packetization and H.263 +, respectively.

6 is a flowchart illustrating a process of performing error detection in an H.263 decoder.

7 is a flowchart illustrating a video format error response process using an RTP H.263 payload header when H.263 packetization is performed.

8 is a flowchart illustrating a video format error response process using H.263 + payload information;

9 is a flowchart illustrating a picture type error response process using an H.263 payload;

10 is a flowchart illustrating a picture type error response process using an H.263 + payload;

11 is a flowchart illustrating a picture header loss correspondence process using only H.263 or H.263 + GOB information.

The present invention relates to a video data processing method, and more particularly, to efficiently deal with video errors for video telephony service provided through a wired / wireless network to prevent decoding errors and degradation due to packet loss. The present invention relates to a video data processing method for video telephony through a wired / wireless communication network.

Currently, communication technology provides roaming service between heterogeneous communication networks to receive communication service using one mobile phone in all regions of the world, and provides high speed data service such as video by expanded transmission band and high speed data service. do. Due to the development of communication technology, users of remote communication terminals can perform video communication through their mobile communication devices using a video telephony service.

1 is a diagram illustrating a schematic configuration of a wired / wireless communication network for video communication as described above, and FIG. 2 is a hierarchical structure of a communication terminal for a video communication service (video telephony service) through the wired / wireless communication network of FIG. 1. It is a figure which shows a figure.

As shown in FIG. 1, each wired / wireless communication network 10 provides H.263 protocol service for exchanging real-time multimedia data for video telephony service in an IP-based packet network network in a wired / wireless communication network. Terminals 1, 2, 3, and 4 having a video communication function are configured to perform video communication.

The H.323 protocol is a protocol for exchanging real-time multimedia data in an IP-based packet network. H.323 has been proposed by ITU-T, and was initially developed for multi-party video conferencing, but has been widely used in the VoIP direction. It provides compatibility with similar H.32x protocols for multimedia communication services in various networks. To provide.

Next, as shown in FIG. 2, the terminal for the video communication (video telephony) service encodes the received image of the camera / LCD and the camera as a physical configuration for the imaging of the communication target and the image display of the counterpart communication. An encoding / decoding unit (codec) for decoding encoded counterpart image data, a packet / depacketizing unit for converting the encoded image data into packet data and combining the received packet data into encoded image data, and broadcasting of a specific group A real-time transport protocol (RTP) / real-time transport control protocol (RTCP) stack that enables and controls real-time transmission of communications, a UDP stack that enables IP communications without transmission control, It is configured to include a protocol stack consisting of an IP stack to generate IP packets to perform IP communication.

In the wired / wireless communication network and the terminal for the video communication service configured as described above, the image data for the video communication is generated by decoding the camera captured image into H.263 data and generating a packet to generate an RTP / RTCP stack, a UDP stack, The packet is transmitted by performing a sequential packet change through an IP stack and depacketized in reverse order for the received packet and displayed on the LCD.

At this time, in video transmission for video communication service, packet delay, loss, or error occurs due to non-isochronous nature of the packet network, and thus H.263 decoding error occurs.

Accordingly, the present invention is to solve the above-mentioned problems of the prior art, a video decoder for a video communication service in an environment in which packet delay and loss or error occurs due to incompatibility of the packet network, Rather, when implementing wired / wireless packet network applications and video decoders in terminals, video data processing for video telephony through wired / wireless communication networks enables efficient error response to prevent decoding errors and quality degradation due to packet loss. Its purpose is to provide a method.

In the video data processing method for video telephony through the wired / wireless communication network of the present invention for achieving the above object, in the video data packetization method for a video telephony service, an initialization for initializing the bit sum allocation variable for packetization Process; An encoding process of encoding packet object data after the initialization process; A packet loss rate receiving process for receiving a packet loss rate by RTCP from the packet network; A packet size changing step of varying a packet size according to a packet loss rate received in the packet loss rate receiving process; And a packet transmission process for transmitting the packetized packet into the variable packet size and transmitting the packet.

The encoding process may be a process of encoding a macro block or a GOB (Group of Bolock).

In the packet size changing process, if there is no packet loss rate received in the packet loss rate receiving process, the packetization is performed in units of 1500 bytes, and when the packet loss rate is about 50%, a linear curve having a transmission packet size of 750 bytes is obtained. It is characterized in that performed using.

The packet transmission process is characterized in that the packet is transmitted when the number of Macro Block (MB) bits or GOB bits generated by the encoding is larger than the packet of the variable size.

According to another aspect of the present invention, there is provided a video data processing method for video telephony through a wired / wireless communication network. In decoding video data for a packet-based video telephony service, a packet is depacked and a video is inputted. A depacketizing process of generating a data bitstream and outputting RTP payload information; Determining the presence or absence of a Group of Block (GOB) header in the bitstream output during the depacketization process to detect the current macroblock number using any one of the MBA (Macro Block Address) information of the GOB or RTP payload. The current macroblock number detection process; A macroblock number comparison process of comparing a macroblock number (MB number) detected in the macroblock detection process with a next macroblock number (MB Number) of a previously decoded macroblock number (MB Number); As a result of comparing the macroblock number comparison process, if the calculated current macroblock number (MB number) matches the next macroblock number (MB Number) of the previously decoded macroblock number (MB Number), a normal decoding process is performed. A macroblock decoding process; As a result of comparing the macroblock number comparison process, if the calculated current macroblock number (MB number) does not match the next macroblock number (MB Number) of the previously decoded macroblock number (MB Number), the previous macroblock number And an error concealment process for performing error concealment from the next macroblock number MB of the (MB Number) to the current macroblock number (MB Number).

The current macroblock number detection process includes: a GOB header detection process of searching for a GOB header by searching a group of block start code (GBSC) in the bitstream; If a GOB header is detected in the GOB header detection process, the current macroblock number (MB number) is detected using GN (Group Numer) information, and if the GOB header is not detected in the GOB header detection process, the RTP payload Comprising a current macroblock number calculation process for detecting the current macroblock number using the MBA information of the.

In the macroblock decoding process, if the current macroblock number MB_num increased by 1 after the macroblock number of the current decoded macroblock is increased by 1, the process is terminated, and the maximum macroblock number is reached. If it is not (MB_num), it is characterized in that it further comprises a decoding end determination process to return to the depacketization process and repeat the process.

In another aspect of the present invention, a video data processing method for video telephony through a wired / wireless communication network according to the present invention is a video data decoding method for a packet-based video telephony service. A depacketization process of generating a data bitstream and outputting RTP Payload information; A GOB header detection step of detecting a GOB header in the bitstream generated in the depacketization step; A GOB corresponding decoding process for detecting a GFID when a GOB header is detected in the GOB header detection process and performing decoding using a video format or picture type of a previous packet when the GOB header is detected and compared with a previous GID; When the GOB header is not detected during the GOB header detection process or when the GOB header is detected but the GFID is not the same, after detecting image format information (SRC information) or picture type information among the RTP payload information And a payload corresponding decoding process for decoding using the detected image format information or picture type information.

The GOB header detection process is characterized by detecting by GBSC.

The video format information is characterized in that the 3-bit SRC bit information indicating the video format of the current packet.

In the present invention described above, the packet is a packet for an H.263 bitstream.

According to another aspect of the present invention, there is provided a video data processing method for video telephony through a wired / wireless communication network. In the video data decoding method for a packet-based video telephony service, decoding of a packet input through a packet network is performed. Depacketizing to generate a bitstream for decoding by performing depacketization and outputting RTP Payload information in this process; A PSC detection process of detecting a Picture Start Code (PSC) in the RTP payload information; A PSC corresponding decoding process for decoding the image data by decoding the image format data or the picture type by using the picture header information when the PSC is detected in the PSC detection process; When the PSC is not detected in the PSC detection process, after detecting a packaging type from the RTP payload information, one of the image format information and the picture type information is determined according to the packetization type, and then according to the determined information. And a payload corresponding decoding process of decoding the image data by performing initialization.

The payload corresponding decoding process may include: a packetization type classification process of classifying a picture segment packet and a follow on packet in the RTP payload information; After the packetization type classification process, a picture segment packet includes a picture segment packet image format or picture type information detection process for detecting image information or picture type information in a current packet; A follow-on packet-type classification process, wherein the follow-on packet detecting step includes: detecting a follow-on packet picture format or picture type information from the previous picture segment packet; And a video data decoding process for decoding the video data after performing initialization using the detected image format or picture type information.

The packet may be a packet having an H.263 + bitstream.

In another aspect of the present invention, a video data processing method for video telephony through a wired / wireless communication network according to the present invention is a video data decoding method for a packet-based video telephony service. A depacketization process of generating a data bitstream and outputting RTP Payload information; A PSC detection process of detecting a Picture Start Code (PSC) in the RTP payload information; A PSC corresponding decoding process for decoding the image data by decoding the image format data or the picture type by using the picture header information when the PSC is detected in the PSC detection process; A GOB detection process of detecting GOB information after receiving the next packet when the PSC is not detected in the PSC detection process; A GFID decoding process for decoding a GFID when GOB is detected in the GOB detection process; If the GFID is the same as the GFID of the previous packet, performing a first GFID corresponding decoding process for decoding using the previous image size and picture type information; And if the GFID is not the same as the GFID of the previous packet, a second GFID-corresponding decoding process for decoding using the supported maximum image size and picture type information opposite to the previous picture type. .

The first GFID-corresponding complexation process is characterized in that decoding is performed using PQUANT. The second GFID-corresponding decoding process is characterized in that decoding is performed using PQYAN after GQUANT decoding.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

3 is a graph illustrating packet size adjustment in consideration of an error rate of a network, and FIGS. 4 and 5 are flowcharts illustrating different packetization methods of H.263 packetization and H.263 +, respectively.

In general, in the prior art, the transmitting end encodes an image input from a camera through H.263 and H.263 + Encoder, and then performs a packetization step. Then, before the final packet network transmission, total header information of 40 bytes (IP header (20Byte) + UDP header (8 Byte) + RTP header (12 Byte)) is added and then transmitted to the packet network. Here, RTCP feeds back information about network error conditions, that is, packet loss rate. On the other hand, in the real-time video communication service through the packet network, packet delay and loss occurs due to the non-isochronous nature of the packet network, thereby causing a phenomenon in which the image of the receiving screen is broken. In order to solve this problem, most terminals attempt to improve image quality through post-processing, that is, error concealment at the receiving end. In the conventional H.263 stream packetization method, since data is lost in 1500 byte units when one packet is lost, there is no problem in an error-free situation, but in an error situation where there is a packet loss, a large amount of data is lost as the packet loss rate increases. There is a problem of image quality deterioration at the receiving end.

Accordingly, in order to solve this problem, as shown in FIGS. 3 to 5, when packetizing H.263 and H.263 + streams at the transmitting end, the packet size is adaptively adjusted in consideration of the feedback packet loss rate, thereby preventing errors. It ensures robust video transmission and prevents image degradation caused by packet loss.

In more detail, as shown in FIG. 4, initialization is performed to set a variable sum having a sum bit value of macro bits and mb_bit to which a macro bit is allocated to 0 for packetization. Initialize the variable (SUM) indicating the packet size and mb_bit (S11).

Thereafter, one macro block (MB) is encoded (S12).

In a packet network in which packet loss exists, information on an error condition on the network is fed back as packet loss rate (PLR) information through RTCP (S13).

Next, the size of the transport packet to be packetized is variably adjusted using the information fed back in step S13. Here, the transport packet size curve may be linear / or nonlinear in consideration of computational complexity. It is assumed that it is a linear case. If there is no error, it is changed to packetize the existing 1500 byte unit. If the packet loss rate is about 50%, the transmission packet size is reduced to about 750 bytes. The reason for this is that the higher the probability of packet loss, the smaller the size of the transmitted packet, thereby reducing the amount of data lost in case of packet loss, and also reducing the amount of data lost on the screen even under error concealment at the receiver. Improvement in image quality by magnification can be achieved (S14).

Next, it is determined whether the size of Sum + mb_bit generated by encoding is greater than the variable packet size in step S14 (S15).

If the size of the sum + mb_bit generated by the encoding process is smaller than the variable packet size in the process S14, the process returns to the process S12 and repeats the process, and the size of the sum + mb_bit generated by the encoding process is determined. If larger than the variable packet size in step S14 and packetized and transmitted (S16).

Since the number of bits per GO and the number of GOB bits per macroblock can be known after encoding, in FIG. 5, unlike FIG. 4, while monitoring the number of bits at the time of encoding GOB, the size of a variable transmission packet determined by the PLR is increased. When a packet is transmitted, it is a flow chart.

FIG. 6 is a flowchart illustrating another method of processing video telephony video data according to the present invention and performing error detection in an H.263 decoder.

In the video telephony service, in addition to the problems to be solved by FIGS. 3 to 5, in a real-time video communication service through a packet network, a packet delay and loss occurs at a receiving end due to non-isochronous nature of the packet network, and decoding is performed. There are many problems such as decoding error.

In order to solve this problem, an error detection and error concealment method in the decoder stage is required, and many error concealment methods using space-time correlation have been developed and studied. However, it is error detection that fundamentally determines such error concealment performance, and it is difficult to expect the performance improvement of error concealment without detecting the exact error. On the other hand, most of the H.263 decoders used in the standard detect errors in VLC (Variabel length code) errors, that is, when bitstreams are missing from the VLC table, or macros depending on the GOB number in the GOB header. In most cases, block order loss is detected as an error. Since there is almost no VLC error due to such a bit loss in the packet network, the existing decoder relies solely on error detection by GOB (group of block) header information. Therefore, when the packet is lost, the next bitstream without the GOB header is not detected as an error and is not misidentified and error concealed as a normal bitstream. Filling of the image occurs, causing a fatal loss of image quality. Therefore, modification and security of this error detection method is inevitable when decoding packet application H.263.

In order to solve this problem, in H.263 decoding in packet-based video communication system, error detection is used not only with GOB information but also with RTP H.263 payload format information transmitted together. 263 It is possible to efficiently reduce decoding errors and image quality degradation.

That is, as shown in FIG. 6, the H.263 decoder generates a H.263 bitstream for decoding by performing depacketization for decoding a packet input through a packet network, and in this process, an RTP H.263. The MBA (Macro Block Address) information of the payload is output (S31).

At this time, since the transmitter sends the macroblock address of the current packet when H.263 packetization, this information is used to detect the error of the decoder, and the presence or absence of the GOB header is determined as the first step for error detection. . In most packet application video communication services, it is common to transmit these GOB headers at the transmitting end. However, in some cases, the presence of the GOB header is used to find GBSC (Group of Block Start Code) 17 bit (0000 0000 0000 0000 1) information. It is judged by the presence or absence (S32).

As a result of the determination of the S32 process, if there is a GBSC, it has GN (Group Numer) information indicating the number of GOBs thereafter, so it is obtained using this information (S33) to calculate the current macroblock number (MB number). (S35).

On the contrary, if there is no GBSC as a result of the S32 process, after receiving MBA (Macro Block Address) information of the RTP H.263 payload outputted in the S31 process (S32), the current macroblock number (MB number) is input. Calculate (S35).

The macroblock number MB number calculated by the above-described step S35 is compared with the next macroblock number MB Number of the previously decoded macroblock number MB Number (S36).

If there is no packet loss when the macroblock number (MB number) calculated by the step S35 matches the next macroblock number (MB Number) of the previously decoded macroblock number (MB Number) as a result of the comparison in the step S36. The normal decoding process is performed (S37).

After the macroblock number of the current decoded macroblock is increased by one (S38), it is determined whether the current macroblock number MB_num increased by one is a macroblock number. As a result of the determination, if the maximum macroblock number MB_num is terminated, the process is terminated, and if it is not the maximum macroblock number MB_num, the process returns to step S31 to repeat the process for the input packet (S39).

Next, as a result of the comparison of the step S36, if the macro block number (MB number) calculated by the step S35 does not match the next macro block number (MB Number) of the previously decoded macro block number (MB Number), packet loss It is determined that there is an error detection signal is output (S40), and the error concealment is performed from the next macroblock number MB of the previous macroblock number (MB Number) to the current macroblock number (MB Number) (S41). After step S41, the process returns to step S39 again to repeat the data decoding process for the input packet.

In this way, H.263 decoding error and image quality deterioration due to an error detection error occurring when the existing GOB header is not attached can be effectively reduced.

7 is a flowchart illustrating a video format error correspondence process using an RTP H.263 payload header when H.263 packetization, and FIG. 8 illustrates a video format error correspondence process using H.263 + payload information. It is a flowchart showing.

The image format information is important information that is necessarily used when the decoder operates and initializes all memories and processing routines. However, in the real-time video communication service through the packet network, packet delay and loss occurs at the receiving end. If the video format is lost due to this, the decoder allocates and processes the memory incorrectly. Many problems arise, such as errors in processing results.

Therefore, in order to cope with an error in decoding processing due to video format loss in such a packet-based video communication system, an image using RTP payload format information and GOB information transmitted together with the image size information as well as the image size information is decoded. Decoding errors due to format loss can be reduced.

First, an image format error processing process using an RTP H.263 payload header during H.263 packetization will be described with reference to FIG. 7.

In general, in order to decode a packet transmitted through a packet network, the H.263 bitstream for image decoding is generated through depacketization. In this case, the transmitting end generates the image format information of the current packet when the H.263 packetization is performed. This information can be used when the video format is lost by the decoder. The main problem caused by video format loss is the loss of the first packet including the picture header in one frame encoding, so that the decoder can correct the lost video format information with the next packet.

Therefore, as shown in FIG. 7, the H.263 decoder generates a H.263 bitstream for decoding by performing depacketization for decoding a packet input through a packet network, and in this process, an RTP H.263 decoder. Payload information is output (S51).

Next, as a first step for correcting a lost video format, it is determined whether a GOB header is included in the H.263 bitstream generated in step S51. In most packet application video communication services, the sender attaches these GOB headers and transmits them.However, in some cases, the presence of the GOB header is required for GBSC (Group of Block Start Code) 17 bit (0000 0000 0000 0000 1) information. Determine according to (S52).

If the GBSC is not detected by the S52 process, the GFID information cannot be used because there is no GOB header, or if the GOB header is detected but has a different GFID value from the previous frame, H.263 extracted during depacketization of the S51 process. Image format information is detected from payload information. At this time, the detected video format information is SRC bit information with 3 bits indicating the video format of the current packet in the H.263 payload. The SRC is represented as "001" ◎ sub-QCIF, "010" QCIF, "011" CIF, "100" 4CIF, and "101" 16CIF according to the video format, so that the SRC can know the video format of the current packet (S53). ).

Next, after the process S53, decoding of the image data is performed using the image format detected in the process S53 (S54). Thereafter, if the received packet exists, the process returns to step S51 to repeat the process, and if the received packet does not exist, the process ends.

In contrast, if there is a GBSC by the S52 process, as shown in the figure, the GFID following it is found. Here, the GFID is a GOB frame ID (Group of Block Frame ID) and has a fixed length of 2 bits and has information on whether the picture header information is the same or different (S55).

Thereafter, it is determined whether the GFID detected in step S55 is the same as the GFID of the previously transmitted frame. At this time, if the image format of the previous transmitted frame and the received frame is the same, the same GFID, if different, and have a different GFID (S56).

As a result of the determination of step S56, if the GFID of the previously transmitted frame and the GFID detected in step S55 are not the same, the process moves to step S53 to perform the processing of S53 to S54.

In contrast, if the determination result of step S56 is the same as the GFID of the previously transmitted frame and the detected GFID in step S55, the image data is decoded using the image format of the previous packet as it is (S57). Thereafter, if the received packet exists, the process returns to step S51 to repeat the process, and if the received packet does not exist, the process ends.

FIG. 8 is a flowchart illustrating an image format error correspondence process using H.263 + payload information unlike FIG. 7.

As shown in FIG. 8, the H.263 + decoder generates a H.263 + bitstream for decoding by performing depacketization for decoding a packet input through a packet network, and in this process, an RTP H.263. + Payload information is output (depacketization process) (S61).

Next, it is determined whether PSC (Picture Start Code; 22 bits) is included in the H.263 + payload information (S62).

As a result of the determination in step S62, the PSC is followed by a picture header, and is determined to be a normal packet to decode the video format (S63).

Next, after the image format is decoded, a general decoding process is performed after setting parameters related to memory initialization and image decoding according to the decoded image format (S64 and S65).

On the other hand, if the PSC information does not exist as a result of the determination in step S62, the first packet of the image frame is lost and thus there is no image format information due to the loss of the picture header information included therein. In this case, the image format information is detected from the H.263 + payload information in the depacketization step for generating the H.263 + bitstream. The reason for this is that in case of H.263 + packetization at the transmitter, the picture header information including the video format information of the current packet is copied and sent along with Payload information according to the packetization type. This is because information is available (S66).

The H.263 + payload information detected in step S66 is divided into Picture segment Packet or Follow on Packet according to the type. In the former case, the picture header information including the image format is copied and sent. The case is when there is no such information. Accordingly, the packet is classified according to the packetized type classification, whether the packet is a picture segment packet or follow on packet (packetization type classification process) (S67).

In the case of picture segment packet (S68) in the classification process of step S67 because it already has the video format information itself, it finds the video format information in the current packet and then uses it in the decoder initialization process (S69).

Next, in the case of Follow on Packet (S70) in the classification process of S67, since the image format information is not available in the current packet, the image format information is searched for in the previous picture segment packet (S71).

After the steps S69 and S71, the process proceeds to step S64 to perform an initialization process of the decoder by using the image format information detected by the picture segment packet (S64, S65).

9 is a flowchart illustrating a picture type error correspondence process using an H.263 payload, and FIG. 10 is a flowchart illustrating a picture type error correspondence process using an H.263 + payload.

In general, if a picture is lost during decoding, it may cause an incorrect processing result and damage to image quality during decoding in the decoder. Therefore, in H.263 decoding, processing and response for preventing decoding errors due to picture type loss are inevitable.

9 is a flowchart illustrating a process for preventing decoding error due to picture type loss during H.263 decoding. The H.263 decoder performs depacketization for decoding a packet input through a packet network. A H.263 bitstream is generated and RTP H.263 payload information is output in this process (S81).

Next, as a first step for correcting a lost video format, it is determined whether a GOB header is included in the H.263 bitstream generated in step S81. In most packet application video communication services, the sender attaches these GOB headers and transmits them.However, in some cases, the presence of the GOB header is required for GBSC (Group of Block Start Code) 17 bit (0000 0000 0000 0000 1) information. Determine according to (S82).

If GBSC is not detected by S82 and there is no GOB header to use GFID information, or if a GOB header is detected but has a different GFID value than the previous frame, H.263 extracted during depacketization of S81. Picture type information of the payload information is detected (S83).

Next, after step S83, decoding is performed using the picture type detected in step S83 as it is. If there is a received packet, the process returns to step S81 to repeat the process and if there is no received packet. The process ends (S84).

In contrast, if there is a GBSC by the process S82, as shown in the figure, the GFID following it is found. Here, the GFID is a GOB frame ID (Group of Block Frame ID) and has a fixed length of 2 bits and has information about whether or not the picture header information is the same (S85).

Thereafter, it is determined whether the GFID detected in step S85 is the same as the GFID of the previously transmitted frame. At this time, if the image format of the previously transmitted frame and the received frame is the same, the same GFID, if different, it will have a different GFID (S86).

As a result of the determination in step S86, when the GFID of the previously transmitted frame and the GFID detected in step S85 are not the same, the process moves to step S83 to perform the processes of S83 to S84.

On the contrary, if the GFID of the previous transmitted frame and the GFID detected in the S85 process are the same, image decoding is performed using the picture type of the previous packet as it is. Thereafter, if the received packet exists, the process returns to step S81 to repeat the process, and if the received packet does not exist, the process ends (S87).

FIG. 10 is a flowchart illustrating a picture type error response process using an H.263 + payload, wherein the H.263 + decoder performs depacketization to decode a packet input through a packet network, thereby decoding H.263 +. A 263+ bitstream is generated and RTP H.263 + payload information is output in this process (depacketization process) (S91).

Next, it is determined whether PSC (Picture Start Code; 22 bits) is included in the H.263 + payload information (S92).

As a result of the determination in step S92, if there is a PSC, the picture header is followed, and it is determined that the packet is normal and the picture type is decoded (S93).

Next, after the picture type is decoded, a general decoding process is performed after setting memory initialization and processing routines according to the decoded picture type (S94 and S95).

On the contrary, when the determination result of step S92 is that there is no PSC information, the first packet of the video frame is lost, and thus there is no picture type information due to the loss of the picture header information included therein. In this case, picture type information is detected from the H.263 + payload information in the depacketization step for generating the H.263 + bitstream. The reason for this is that in case of H.263 + packetization at the transmitting end, the picture header information including the video format information of the current packet is copied and sent along with the payload information according to the packetization type. This is because information is available (S96).

The H.263 + payload information detected in step S96 is divided into Picture segment Packet or Follow on Packet according to the type. In the former case, the picture header information including the image format is copied and sent. The case is when there is no such information. Accordingly, the packet is classified according to the packetized type classification, whether the packet is a picture segment packet or follow on packet (packetization type classification process) (S97).

In the case of picture segment packet (S98) in the classification process of step S97, since the picture type information is already included in itself, the picture segment information is found in the current packet and used for the decoder initialization process (S99).

Next, in the case of Follow on Packet in the classification process of S97 (S100), since the picture type information is not available in the current packet, the picture type information is searched for in the previous picture segment packet (S101).

After the process S99 and the process S101, the process moves to process S64 to perform the initialization process using the picture type information detected by the picture segment packet, and then decodes the image (S94 and S95).

11 is a flowchart illustrating a picture header loss correspondence process using only H.263 or H.263 + GOB information.

As shown in FIG. 11, first, the H.263 + decoder generates a H.263 + bitstream for decoding by performing depacketization for decoding a packet input through a packet network, and in this process, the RTP H .263+ Payload information is output (depacketization process) (S111).

Next, it is determined whether PSC (Picture Start Code; 22 bits) is present among the H.263 + payload information (S112).

As a result of the determination in step S112, the PSC is followed by a picture header, and after determining that the packet is normal, performs normal decoding and ends the process (S113).

Next, if the PSC does not exist in the determination of step S112, after receiving the next packet (S114), it is determined whether the GBSC exists by searching the GBSC information (S115, S116).

If it is determined in step S116 that the GBBSC does not exist, go back to step S113 to repeat the process. On the contrary, if it is determined that GBSC exists in step S116, the GFID is decoded (S117).

Next, it is determined whether the GFID value decoded in step S117 is the same as the previous GFID value (S118).

As a result of the determination in S118, when the decoded GFID value is the same as the previous GFID value, the image data is decoded using the previous image size, picture type, and PQUANT as such (S119).

On the contrary, when the determination result of step S118 indicates that the decoded GFID value is not the same value as the previous GFID value, the picture type (I-> P) opposite to the previous picture type is used by using the maximum image size supported instead of the previous image size. , P-> I), and decoding is performed using the PQUANT value after GQUANT decoding (S120).

The present invention described above can effectively cope with packet loss when decoding video data used in video telephony service using a communication network, thereby significantly improving video image transmission quality for video telephony service in a communication terminal. to provide.

Claims (17)

In the video data packetization method for video telephony service, An initialization process of initializing a bit sum allocation variable for packetization; An encoding process of encoding packet object data after the initialization process; A packet loss rate receiving process for receiving a packet loss rate by RTCP from the packet network; A packet size changing step of varying a packet size according to a packet loss rate received in the packet loss rate receiving process; And a packet transmission process of transmitting the packetized packet into the variable packet size and transmitting the packet data. The video data processing method for video telephony through a wired / wireless communication network. The method of claim 1, wherein the encoding process is a process of encoding a macro block or a GOB (Group of Bolock). According to claim 1, wherein the packet size change process, If there is no packet loss rate received in the packet loss rate receiving process, the packet loss is packetized in units of 1500 bytes, and when the packet loss rate is about 50%, the packet loss rate is performed using a linear curve having a transmission packet size of 750 bytes. Video data processing method for video telephony through a wired / wireless communication network. The method of claim 1, wherein the packet transmission process is a process of packetizing and transmitting when the number of Macro Block (MB) bits or GOB bits generated by the encoding is larger than the packet having the variable size. Method of processing video data for video telephony through wired / wireless communication network. In video data decoding for packet-based video telephony service, Depacketizing the depacketized packet to generate a video data bitstream and to output RTP payload information; Determining the presence or absence of a Group of Block (GOB) header in the bitstream output during the depacketization process to detect the current macroblock number using any one of the MBA (Macro Block Address) information of the GOB or RTP payload. The current macroblock number detection process; A macroblock number comparison process of comparing a macroblock number (MB number) detected in the macroblock detection process with a next macroblock number (MB Number) of a previously decoded macroblock number (MB Number); As a result of comparing the macroblock number comparison process, if the calculated current macroblock number (MB number) matches the next macroblock number (MB Number) of the previously decoded macroblock number (MB Number), a normal decoding process is performed. A macroblock decoding process; As a result of comparing the macroblock number comparison process, if the calculated current macroblock number (MB number) does not match the next macroblock number (MB Number) of the previously decoded macroblock number (MB Number), the previous macroblock number Error concealment process for performing error concealment from the next macroblock number (MB) of the (MB Number) to the current macroblock number (MB Number); video data for video telephony through a wired / wireless communication network, comprising: Treatment method. The method of claim 5, wherein the macroblock number detection process comprises: A GOB header detection process of searching for a GOB header by searching a group of block start code (GBSC) in the bitstream; If a GOB header is detected in the GOB header detection process, the current macroblock number (MB number) is detected using GN (Group Numer) information, and if the GOB header is not detected in the GOB header detection process, the RTP payload Computing the current macroblock number to detect the current macroblock number using the MBA information of the video data processing method for video telephony over a wired / wireless communication network. The method of claim 5, wherein the macroblock decoding process, After the macroblock number of the current decoded macroblock is increased by 1, the process is terminated when the current macroblock number (MB_num) increased by 1 is the maximum macroblock number, and when it is not the maximum macroblock number (MB_num). A video data processing method for video telephony over a wired / wireless communication network, characterized in that the method further comprises a decoding end determination step of returning to the depacketization process and repeating the processing. A video data decoding method for packet based video telephony service, Depacketizing the packet into an input packet to generate a video data bitstream and to output RTP payload information; A GOB header detection step of detecting a GOB header in the bitstream generated in the depacketization step; If a GOB header is detected in the GOB header detection process, it detects a GFID and compares it with a previous GID to perform decoding using a video format or picture type of a previous packet; When a GOB header is not detected in the GOB header detection process or when a GOB header is detected but the GFID is not the same, after detecting image format information (SRC information) or picture type information among the RTP payload information. Payload corresponding decoding process for decoding using the detected image format information or picture type information; video data processing method for video telephony over a wired / wireless communication network. 10. The method of claim 8, wherein the GOB header detection process is detected by GBSC. 10. The method of claim 8, wherein the video format information is 3-bit SRC bit information indicating a video format of a current packet. 11. The method according to any one of claims 8 to 10, wherein said packet is a packet for an H.263 bitstream. A video data decoding method for packet based video telephony service, A depacketization process of performing a depacketization process for decoding a packet input through a packet network to generate a bitstream for decoding and outputting RTP Payload information in this process; A PSC detection process of detecting a Picture Start Code (PSC) in the RTP payload information; A PSC corresponding decoding process for decoding the image data by decoding the image format data or the picture type by using the picture header information when the PSC is detected in the PSC detection process; When the PSC is not detected in the PSC detection process, after detecting a packaging type from the RTP payload information, one of the image format information and the picture type information is determined according to the packetization type, and then according to the determined information. Payload corresponding decoding process for decoding the image data by performing initialization; video data processing method for video telephony over a wired / wireless communication network comprising a. The method of claim 12, wherein the payload corresponding decoding process is performed. A packetization type classification process of classifying a picture segment packet and a follow on packet in the RTP payload information; After the packetization type classification process, a picture segment packet includes a picture segment packet image format or picture type information detection process for detecting image information or picture type information in a current packet; A follow-on packet-type classification process, wherein the follow-on packet detecting step includes: detecting a follow-on packet picture format or picture type information from the previous picture segment packet; And a video data decoding process for decoding the video data after performing initialization using the detected image format or picture type information. 2. The video data processing method of claim 1, further comprising a video data decoding process. 15. The method of claim 12 or 13, wherein said packet is a packet having an H.263 + bitstream. A video data decoding method for packet based video telephony service, Depacketizing the packet into an input packet to generate a video data bitstream and to output RTP payload information; A PSC detection process of detecting a Picture Start Code (PSC) in the RTP payload information; A PSC corresponding decoding process for decoding the image data by decoding the image format data or the picture type by using the picture header information when the PSC is detected in the PSC detection process; A GOB detection process of detecting GOB information after receiving the next packet when the PSC is not detected in the PSC detection process; A GFID decoding process for decoding a GFID when GOB is detected in the GOB detection process; If the GFID is the same as the GFID of the previous packet, performing a first GFID corresponding decoding process for decoding using the previous image size and picture type information; And if the GFID is not the same as the GFID of the previous packet, a second GFID-corresponding decoding process for decoding using the supported maximum image size and picture type information opposite to the previous picture type. Method of processing video data for video telephony through wired / wireless communication network. The video data processing method for video telephony through a wired / wireless communication network according to claim 15, wherein the first GFID-corresponding decoding process performs decoding using PQUANT. The video data processing method for video telephony through a wired / wireless communication network according to claim 15, wherein the second GFID-corresponding decoding process performs decoding using PQYAN after GQUANT decoding.

Images