JP2004328353A - Correction method and apparatus for inverted stream packet - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a correction method and an apparatus for inverted stream packets for preventing a deterioration in quality such as disturbance of an image even when the received packets are decoded. <P>SOLUTION: A system which passes MPEG stream packets over an IP network and performs image distribution in real time, includes a packet receiving part 10 which receives the MPEG stream packets, an RTP header information extraction part 11 which extracts RTP headers from the received packets, a sequence number extraction part 12 which further extracts sequence numbers of the packets from the extracted RTP headers and a packet order correction part 13 which corrects an order of the packets based on the sequence numbers extracted from the sequence number extraction part 12. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a method and an apparatus for correcting a reverse stream packet. With the arrival of the multimedia age, the expansion of infrastructure such as communication networks has been progressing. However, since the amount of information of the image data is large, if the data is transferred as it is, there is a problem that the communication time is still long and the load on the communication line is increased. As a technique for solving such a problem, a JPEG (Joint Photographic Coding Experts Group) or MPEG (Moving Picture Coding Experts Group) image compression technique is used. Among these, the MPEG method is mainly used for compression of moving images (video data), and can also compress audio data and multiplex it with video data.
[0002]
[Prior art]
The MPEG system used as the above-described image compression technology includes MPEG1, MPEG2, and MPEG4. As a conventional technique of this kind, an order table in which a correspondence relationship between a packet group arrangement in an original MPEG data stream and a packet group arrangement in a generated MPEG data packet sequence is described in a PES private data area of an MPEG packet. There has been known a system in which the order of packet groups is initially grasped and the order of packet groups can be arbitrarily changed (see, for example, Patent Document 1).
[0003]
FIG. 7 is a conceptual diagram of a conventional data transfer system. In the figure, reference numeral 1 denotes a camera, and 2 denotes an encoder for receiving and modulating an NTSC signal photographed by the camera 1. In this example, three cameras 1 to 3 are shown as the camera 1 and three encoders 1 to 3 are shown as the encoder 2. Reference numeral 3 denotes a network to which an output signal of the encoder 2 is transferred. The output of these encoders 2 becomes MPEG data, which is an MPEG stream packet distribution.
[0004]
Reference numeral 4 denotes a decoder which is connected to the network 3 and receives MPEG data as an output signal of the encoder 2 and restores the original NTSC signal. A monitor 5 is connected to the decoder 4 and displays an NTSC image. In the example shown in the figure, an example is shown in which two decoders, decoder 1 and decoder 2, and two monitors 5, monitor 1 and monitor 2, are provided. Reference numeral 6 denotes a management server connected to the network 3, and reference numeral 7 denotes a personal computer (PC) also connected to the network 3. The outline of the system configured as described above is as follows.
[0005]
The system shown in this figure is a system that distributes MPEG stream packets over an IP network and distributes images in real time. Encoders 1 to 3 in the figure each have an NTSC video / audio input and an IP interface, encode NTSC video / audio data input from the camera 1 into an MPEG stream, and deliver MPEG stream packets over an IP network. have.
[0006]
Also, the decoder 1 and the decoder 2 in the figure have NTSC video / audio output and an IP network interface, respectively, and have a function of decoding live-received MPEG stream packets into NTSC video / audio data and outputting them to the monitor 5.
[0007]
With such a system, it is possible to simultaneously distribute to a large number of monitors on an IP network by multicast or unicast. Further, these devices can be collectively set by the management server 6 and the personal computer (PC) 7. For example, it is possible to switch and set the video / audio received from the encoder 1 by the decoder 1 and displayed on the monitor 1 by the management server 6 or the personal computer 7 to be received by the decoder 2 and displayed on the monitor 2. it can.
[0008]
The device configurations of the encoder and decoder are shown below. FIG. 8 is a diagram illustrating an example of the internal configuration of the encoder 2. In the figure, reference numeral 2a denotes an encoder for receiving and encoding NTSC data from a camera, for example, and converts the NTSC data into MPEG data. A transmission unit 2b transmits the MPEG data output from the encoder unit 2a. MPEG stream packet distribution is performed from the transmission unit 2b.
[0009]
FIG. 9 is a diagram showing an example of the internal configuration of the decoder 4. In the figure, reference numeral 4a denotes a receiving unit that receives an MPEG stream packet from the encoder 2, for example. A decoder 4b decodes the MPEG data output from the receiver 4a and converts the data into NTSC data. The output of the decoder unit 4b is connected to, for example, a monitor, and an image is displayed.
[0010]
FIG. 10 is a diagram showing a configuration example of an MPEG stream packet. FIG. 3 is a diagram illustrating a configuration example of an MPEG stream packet. The MPEG stream packet is roughly composed of two parts, an RTP header and a payload part. The RTP header is added by the transmission unit when the encoder distributes the MPEG stream packet to the IP network, and the header stores a sequence number indicating the distribution order of the packet.
[0011]
The packet is composed of 32 bits from 0 to 31 bits per row, and is cyclically numbered in the range of 0 to 65535. Based on this number, the decoder recognizes the occurrence of a received packet or stream switching.
[0012]
In the RTP header, V indicates a version, P indicates padding, X indicates an extension, CC indicates a CSRC count, M indicates a marker indicating a RAP flag, PT indicates a payload type, and a sequence number indicates a serial number of a packet. The time stamp is time information.
[0013]
In the payload portion, the MPEG compression mode indicates a compression mode (for example, MPEG1 or MPEG2), and the time is displayed when the RAP flag is set. Thereafter, the actual MPEG data is entered.
[0014]
FIG. 11 shows a reception flowchart when the MPEG stream packet distributed from the encoder to the network is received by the receiver of the decoder. When a stream packet is received (S1), the number of received packets is counted (S2). Next, the RTP header information is checked (S3). Then, the stream size is checked (S4).
[0015]
Next, it is checked whether or not the received packet is incorrect (S5). Here, the incorrect reception packet means, for example, that the reception packet data is broken. If the received packet is incorrect, the received stream is discarded (S6), and the process returns to step S1 to start over from the packet receiving step. If the received packet is not wrong, it checks for missing packets (S7) and requests decoding of the received stream (S8). Then, the process enters the next packet receiving process.
[0016]
As is clear from the above description, in the MPEG stream packet received by the receiving unit, the information in the RTP header is first checked in the receiving unit, and then the sequence number is checked. In the prior art, even if packet inversion occurs, a decoding request is made to the decoder unit in accordance with the order of packet reception.
[0017]
[Patent Document 1]
Japanese Patent Application Laid-Open No. 10-31648 (page 6, FIG. 1)
[0018]
[Problems to be solved by the invention]
As described above, when an MPEG stream is inverted and received, in the conventional packet reception processing, a decoding request is made in an order different from the order transmitted by the encoder. For this reason, the image is distorted even though no data is missing, and there is a problem of deterioration in quality. In particular, with respect to MPEG4, the data size is small and the frequency of packet reversal increases, so that there is a problem that the image is further distorted as compared with MPEG1 and MPEG2.
[0019]
SUMMARY OF THE INVENTION The present invention has been made in view of such a problem, and provides a method and an apparatus for correcting a reverse stream packet which can prevent quality deterioration such as image distortion even when a received packet is decoded. It is intended to provide.
[0020]
[Means for Solving the Problems]
(1) The invention described in claim 1 is as follows. FIG. 1 is a flowchart showing the principle of the method of the present invention. According to the present invention, in a system for flowing an MPEG stream packet received via an IP network and delivering images in real time, RTP header information is extracted from the MPEG stream packet received via the IP network (step 1). Sequence number information indicating the packet transmission order in the RTP header is extracted (Step 2), an error in the packet reception order is identified based on the extracted sequence number, and processing is performed according to the packet transmission order (Step 3). It is characterized by the following.
[0021]
With this configuration, when decoding received packet data based on a sequence number, decoding is performed not in the order of packet arrival but in the order of sequence numbers. The drop can be prevented.
(2) The invention described in claim 2 is as follows. FIG. 2 is a block diagram showing the principle of the present invention. The apparatus shown in the figure shows a decoding part of a system for transmitting an MPEG stream packet over an IP network and distributing images in real time. In the figure, 10 is a packet receiving unit for receiving an MPEG stream packet, 11 is an RTP header information extracting unit for extracting an RTP header from the received packet, and 12 is a sequence number extracting unit for further extracting the sequence number of the packet from the extracted RTP header. The unit 13 is a packet order correcting unit for correcting the order of packets based on the sequence numbers extracted from the sequence number extracting unit 12.
[0022]
With this configuration, even if the packet arrival order at the time of packet reception is out of order as compared with the time of packet transmission, the packet order correction unit 13 performs the decoding process in accordance with the packet transmission order, so that the packet is decoded. There is no disturbance in the image, and it is possible to prevent a decrease in quality.
(3) In the invention according to claim 3, in the case where the packet reversal occurs, the packet order correcting unit 13 sets a guaranteed number range as a threshold value for assuring the degree of the packet reversal, and finally sends a decoding request. The range is from the sequence number of the performed stream to the threshold.
[0023]
With this configuration, the guaranteed number range for correcting the packet inversion is set in advance, and the packets arriving within the guaranteed number range are corrected in the packet order. And a preferable image can be obtained.
(4) According to a fourth aspect of the present invention, in the packet order correcting section, the maximum number of held packets is set as a threshold value for determining how much a reversed packet is held, and the value is a guaranteed number range according to the third embodiment. It is characterized by the same as above.
[0024]
With this configuration, if the number of packets is within the maximum number, the reverse rotation can be corrected and the quality of the decoded image can be prevented from lowering.
(5) The invention according to claim 5 is characterized in that a stream management table is provided for managing the held stream and the stream information for which the decoding request was made last, and the stream is managed collectively. .
[0025]
With this configuration, by performing the stream management collectively, the packet order can be corrected, and the image quality can be maintained.
[0026]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[0027]
FIG. 3 is a flowchart showing an example of the operation of the method of the present invention. The flowchart shown corresponds to the conventional method of FIG. Compared with the method of FIG. 11, steps S7 and S8 of FIG. 11 are replaced with S7 ′ in the present invention. S7 'is the packet reversal correction processing according to the present invention.
[0028]
First, the overall operation will be described. When a stream packet is received (S1), the number of received packets is counted (S2). Next, the RTP header information is checked (S3). Then, the stream size is checked (S4). Next, it is checked whether or not the received packet is incorrect (S5). Here, the incorrect reception packet means, for example, that the reception packet data is broken. If the received packet is incorrect, the received stream is discarded (S6), and the process returns to step S1 to start over from the packet receiving step. If the received packet is not wrong, and if the packet has been inverted, a packet inversion correction process is performed (S7 '), and the next packet reception process is started.
[0029]
When a packet inversion occurs, a guaranteed number range is provided as a threshold value for assuring the degree of the packet inversion, and the range from the sequence number of the stream for which the decoding request was made last to the threshold value is set. Packets received out of the original order must be held until the expected packets are received. Therefore, the maximum number of held packets is set as a threshold value for determining how many packets are held, and the value is set to the same value as the guaranteed number range.
[0030]
Furthermore, a stream management table is provided to manage the held stream and the stream information for which the last decoding request was made, so that the streams are collectively managed.
[0031]
FIG. 4 is a diagram illustrating an example of the stream management table. The stream management table is a table in which all necessary information is stored in order to correct inversion of a packet. This stream management table is provided in the packet order correction unit 13 in FIG. As shown in the figure, the stream management table stores three main types of information. The first is information on a stream for which a decoding request was made last, and manages a sequence number and head address information on a buffer storing MPEG actual data. The sequence number is information required for checking a sequence skip between a received packet and a stream for which a decoding request was made last. The head address of the actual MPEG data is for managing a buffer in which the received stream is stored.
[0032]
The second is information on the currently received stream, which includes a sequence number, RTP header start address, MPEG actual data start address and its size, MPEG format, MPEG mode number, and device type. The RAP flag is a flag indicating whether or not the received MPEG stream packet is a RAP. Here, the RAP is a reference image.
[0033]
As described above, the sequence number is used for checking the sequence number with the stream that has requested decoding last. Other information is information required at the time of a decoding request, and a decoding request is made by passing the information to the decoder unit.
[0034]
The third is information on a stream held when a packet inversion occurs, and an area corresponding to the maximum number of held streams is prepared. Except for the held stream flag, the content is the same as the content shown in the second. The held stream flag is a flag for identifying whether the stored held stream information is valid or invalid. For example, when this flag is set, this information indicates that stream information within the guaranteed number range of the currently occurring packet inversion is stored.
[0035]
When the stream is requested to be decoded, discarded, and initialized, the flag is lowered. This flag makes it possible to clearly confirm whether the information is correct, and eliminates waste when searching for a held stream.
[0036]
The stream management table is initialized at the start of decoding request, at the time of stopping the decoding request, and at the time of network disconnection, since there is a possibility that packet continuity may be lost. By using such a stream management table, it is possible to carry out batch management of streams to perform correction processing of the packet order and maintain image quality.
[0037]
As described above, according to the present invention, the guaranteed number range for correcting the packet inversion is set in advance, and the packets arriving within the guaranteed number range are corrected in the packet order. The obtained image is not disturbed, and a preferable image is obtained. In addition, the maximum number of held packets is set as a threshold for holding the inverted packets, and the value is set to be the same as the guaranteed number range, thereby lowering the quality of the decoded image by correcting the inverted data. Can be prevented.
[0038]
FIG. 5 is a flowchart illustrating an example of the packet reverse rotation correction process. The main part of the operation is the packet order correction unit 13 in FIG. The correction uses the existing sequence number to identify the order of the packets transmitted by the encoder over the IP network, and corrects the decoding order of the packets.
[0039]
First, the sequence number of the received stream is checked (S1). In this check, the information of the stream management table shown in FIG. 4 is compared with the sequence number of the stream for which the last decoder request was made, and whether or not a sequence skip has occurred is identified. Stand up.
[0040]
Next, it is checked whether the received stream is the first stream packet from the start of reception (S2). If it is the first stream packet, there is no possibility of packet inversion, so a decoding request is immediately sent to the decoder unit (S9). If it is not the first time (the second and subsequent streams from the start of reception), the next process is started.
[0041]
Next, it is checked whether the number of the received stream is smaller than that of the stream for which the decoding request has been made (S3). If the stream number is smaller than the last stream for which a decode request was made, it is an unnecessary packet, so the sequence number of the last stream for which a decode request was made is obtained from the stream management table, and the received stream packets before that are discarded. (S10).
[0042]
Next, a case where the received stream is within the guaranteed number range will be described. It is checked whether the received stream is within the guaranteed number range of the sequence skip (S4). If the number is within the guaranteed number range, the processing changes depending on whether a sequence skip has occurred first. The sequence skip is performed by the sequence skip check performed first, and is determined based on the contents of the flag (S5).
[0043]
If a sequence skip has occurred, the received stream is decoded and held (S11). In this case, the storage location flag in the stream management table is used to search for an empty storage location, and that information is stored. By this processing, when a decoding request for the held stream is made later, it is possible to extract information from the stream management table.
[0044]
If the sequence skip does not occur, it means that the received stream is continuous, so a decoding request is made for the received stream (S6). At this time, it is checked whether or not there is a next stream among the streams held by the stream management table (S7). If there is a stream next to the received stream, a decoding request for the held stream is made (S8). After that, it enters a reception waiting state.
[0045]
Next, processing when the received stream is out of the guaranteed number range will be described. If the number is out of the guaranteed number range, the stream management table is searched for a stream having a sequence number immediately before the stream received first (S13), and if so, a flag is set (S12). Search for another previous stream. By repeating this process, a decoding request is made for all the continuous holding streams in the stream management table, and thereafter, a decoding request for the currently received stream is made. Finally, since the received stream exceeds the guaranteed number range, the stream management table is initialized once. After that, it enters a reception waiting state.
[0046]
More specifically, if there is no previous stream in the held stream, it is checked whether or not the loop has been passed (S14). If the stream has been passed, only the stream having a continuous sequence number is requested to decode the held stream (S15). ). Next, a decoding request is made for the received stream (S16), the remaining stream is discarded (S17), and the process returns to step S1.
[0047]
If it is determined in step S14 that the data does not pass through the loop, the received stream is requested to be decoded (S18), all the held streams are discarded (S19), and the process returns to step S1.
[0048]
With this configuration, even if the packet arrival order at the time of packet reception is out of order compared to the packet transmission, the packet order correction unit 13 performs the decoding process in accordance with the packet transmission order, so that the packet is decoded. There is no disturbance in the image, and it is possible to prevent a decrease in quality.
[0049]
Next, examples of some packet reversal correction processing will be described with reference to FIGS. FIG. 6 is a diagram illustrating an example of packet reception. The reception order of the packets in FIG. 6 is assumed to be received in order from left to right, the arrows in the figure indicate that the packets are reversed, and the numbers indicate the sequence numbers. A shaded packet indicates that a missing packet has been received. Here, the case where the guaranteed number range and the maximum holding number are 10 is taken as an example.
(When a packet earlier than the stream that requested decoding is received)
As shown in FIG. 6A, when a packet earlier than the stream for which the decoding request was made is received (when packet number 5 comes after packet number 33), processing is performed according to the reverse rotation correction processing flowchart of FIG. Is performed, the stream of sequence number 1 (hereinafter, only the number) is subjected to the sequence check of S1 and is the first stream from the start of reception. Therefore, the process proceeds to S9 at the branch of S2, and a decoding request is made. This process is an initial operation.
[0050]
When a decode request is made, the decode request information in the stream management table is updated. Thereafter, the update process is performed every time a decode request is made. Packet 2 is performed in the order of S1, S2, S3, S4, S5, S6, and S7. This processing order is a normal operation. After that, the normal processing is performed for the packets up to 33 in the same manner as for the second packet.
[0051]
Next, when the packet of 5 arrives, it undergoes the processing of S1 and S2, and since the number is smaller than that of the stream 33 that last made the decoding request due to the branch of S3, the processing of S10 is performed and the packet is discarded. Is done. The processing after 34 is the same processing order as in 2.
(When a stream exceeding the guaranteed number range is received)
When a packet exceeding the guaranteed number range as shown in FIG. 6B is received and the processing is performed according to the packet reversal correction processing flowchart of FIG. 5, the initial operation is performed because one packet is the first stream from the start of reception. Do. Normal operation is performed on packets 2 to 13.
[0052]
The 22 packets are processed in the order of S1, S2, and S3. In this case, the branch of S4 checks whether the number is within the guaranteed number range. Since the difference between the streams 13 and 22 is “9”, which is within the guaranteed number range, the process proceeds to S5. In the process of S5, since a sequence jump has occurred from the stream 13 that has requested decoding last, information is stored as a holding stream on the stream management table by the process of S11. The information is stored in the stream management table in the same processing order as.
[0053]
Thereafter, when the stream 25 is received, the processing of S1, S2, and S3 is performed. Since the processing is out of the guaranteed number range in the processing of S4, the process proceeds to S13. In the process at S13, the stream management table is searched for a stream one before the reception stream 25, that is, a stream of 24. Here, since there are the 24 streams held earlier, a loop check flag is set by the processing of S12, and the processing of S13 is repeated, and the next stream, 23, which is one stream before 24, is searched.
[0054]
Similarly, this process is repeated, and the search is continued until 22 is found. However, since the stream immediately before 22 is not held, the process proceeds to S14. In the process of S14, whether or not the loop has been passed is identified based on the loop check flag. Thus, the process proceeds to the process of S15, and a decoding request is made for the streams 22, 23, and 24.
[0055]
Thereafter, a decoding request of the stream 25 currently received is made in the processing of S16, and finally, the remaining held stream is invalidated by the processing of S17 by lowering the held stream flag. Thereafter, the normal operation is performed after the 26th packet.
(When packet reversal occurs once)
As shown in (c) of FIG. 6, when one inversion occurs (stream 11), the processing is performed according to the packet inversion correction processing flowchart of FIG. Perform the operation. The normal operation is performed on the packets 2 to 10, and the processing on the packets 12 and 13 is performed in the order of S1, S2 and S3.
[0056]
Then, since it is within the guaranteed number range in the process of S4, the process proceeds to S5. In the process of S5, since a sequence jump has occurred from the stream 10 for which decoding was last requested, information is stored as a holding stream on the stream management table by the process of S11.
[0057]
When the expected 11 packets are received, the processing is performed in the order of S1 to S4. In the process of S5, since the sequence skip has not occurred between the stream 10 that has made the last decoding request and the currently received stream 11, the process of S6 is performed and 11 is requested to be decoded.
[0058]
Next, the processing shifts to the processing of S7, and the stream management table is searched for the packet next to the 11 currently received in the processing of S7, that is, 12. Here, since the stream 12 held earlier exists, the decoding of the stream 12 is requested by the processing of S8, and the processing of S7 is repeated.
[0059]
Then, 13 which is the next number after 12 is searched. Since information is held in the stream management table for 13 as well as 12, the processing shifts to S 8 and a decoding request is made. Further, the process of S7 is repeated, but since there is no number 14 next to 13, the process ends. Thereafter, the processes after 14 perform the normal operation.
(When packet inversion occurs three times and the receiving order is complicated)
As shown in FIG. 6D, a sequence jump occurs, and two sequence jumps occur before an expected packet is received. Thereafter, when the expected packet reception order is complicated, the processing is performed according to the packet inversion correction processing flowchart of FIG.
[0060]
Since packet 1 is the first stream from the start of reception, an initial operation is performed. Normal operation is performed for packets 2 to 10, and packets are received in the order of 12, 13, 15, and 17. These packets are processed in the order of S1, S2, S3, S4, S5, and S11, and the information is managed in the stream management table.
[0061]
Next, the inverted packet 14 is received, but is processed in the order of S1 to S5, and since the sequence skipping occurs with the stream 10 that has made the last decoding request, it is the same as 12, 13, 15, and 17, The information is held in the stream management table. Further, 18, 16, and 19 are processed similarly to 14.
[0062]
Next, when 11 is received, the processing is performed in the order of S1 to S4. In the processing of S5, since the sequence skip does not occur from the last 10 which made the decoding request, the processing shifts to the processing of S6 and a decoding request is made. . Then, the process proceeds to S7.
[0063]
In the process of S7, the stream 12 following the 11 is searched. Since the information of the 12 streams is held in the stream management table, the process proceeds to S8, and the decoding of the 12 streams is requested. Thereafter, the processes of S7 and S8 are repeated, and decoding of the remaining held streams 13 to 19 is requested. Thereafter, normal operation is performed for packets 20 and thereafter.
[0064]
As described above, according to the present invention, even if a packet received from the IP network is inverted, it can be corrected. This correction effect can reduce image disturbance when packet inversion occurs, and is particularly effective for a stream in which packet inversion occurs frequently, such as MPEG4. can avoid.
[0065]
【The invention's effect】
According to the present invention, the following effects can be obtained.
(1) According to the first aspect of the invention, when decoding received packet data based on a sequence number, decoding is performed not in the order of packet arrival but in the order of sequence numbers. There is no disturbance, and a decrease in quality can be prevented.
(2) According to the second aspect of the present invention, even if the packet arrival order at the time of packet reception is out of order compared with the packet transmission, the packet order correction unit 13 performs the decoding process according to the packet transmission order. Thus, the decoded image is not disturbed, and the quality can be prevented from lowering.
(3) According to the third aspect of the present invention, the guaranteed number range for correcting the packet inversion is set in advance, and the packet order for packets arriving within the guaranteed number range is corrected. Therefore, there is no disorder in the decoded image, and a preferable image is obtained.
(4) According to the fourth aspect of the invention, if the number of packets is within the maximum number, the inversion can be corrected to prevent the quality of the decoded image from deteriorating.
(5) According to the fifth aspect of the present invention, by performing batch management of the streams, the packet order can be corrected, and the image quality can be maintained.
[0066]
As described above, according to the present invention, it is possible to provide a method and an apparatus for correcting a reverse stream packet, which can prevent quality deterioration such as image distortion even when a received packet is decoded.
[Brief description of the drawings]
FIG. 1 is a flowchart showing the principle of the method of the present invention.
FIG. 2 is a principle block diagram of the present invention.
FIG. 3 is a flowchart showing an example of the operation of the method of the present invention.
FIG. 4 is a diagram illustrating an example of a stream management table.
FIG. 5 is a flowchart illustrating an example of a packet reverse rotation correction process.
FIG. 6 is a diagram illustrating an example of packet reception.
FIG. 7 is a conceptual diagram of a conventional data transfer system.
FIG. 8 is a diagram illustrating an example of an internal configuration of an encoder.
FIG. 9 is a diagram illustrating an example of an internal configuration of a decoder.
FIG. 10 is a diagram illustrating a configuration example of an MPEG stream packet.
FIG. 11 is a flowchart illustrating an existing process when a receiving unit receives a packet.
[Explanation of symbols]
10 Packet receiver
11 RTP header information extraction unit
12 Sequence number extraction unit
13 Packet order correction unit

Claims (5)

In a system for flowing an MPEG stream packet received via an IP network and distributing images in real time, RTP header information is extracted from the MPEG stream packet received via the IP network (step 1),
Next, sequence number information indicating the packet transmission order in the RTP header is extracted (step 2),
An error in the packet reception order is identified based on the extracted sequence number, and processing is performed according to the packet transmission order (step 3).
A method for correcting a reverse stream packet. In a system that distributes MPEG stream packets over an IP network and distributes images in real time,
A packet receiving unit that receives an MPEG stream packet;
An RTP header information extraction unit that extracts an RTP header from the received packet;
A sequence number extracting unit for further extracting a packet sequence number from the extracted RTP header;
A packet order correction unit that corrects the order of packets based on the sequence number extracted from the sequence number extraction unit;
And a correction device for the reverse stream packet. When the packet inversion occurs, the packet order correction unit sets a guaranteed number range as a threshold value for assuring the degree of the packet inversion, and sets a range from the sequence number of the stream for which the last decoding request was made to the threshold value. 3. The apparatus for correcting a reverse stream packet according to claim 2, wherein: The said packet order correction | amendment part sets the maximum holding | maintenance number as a threshold value which holds the packet which reversed, and the value is the same as the guarantee number range of Claim 3 characterized by the above-mentioned. A correction device for a reverse stream packet according to the above description. 3. The reverse stream packet correction device according to claim 2, wherein a stream management table is provided for managing the held stream and the stream information for which the decoding request was made last, and the stream is collectively managed. .

Images