JPH09298748A - Method and device sending private data in mpeg bit stream in place of stuffing bit - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and system to use an additional band to eliminate stuffing bytes and to send private data and private stuff data in the system including variable bit rate video data in the form of a data packet. SOLUTION: At first, in the step 402, after a transport packet is given from a transport stream, in the step 404, the packet is checked. The check includes decision as to whether or not stuffing bytes are in existence (step 405) and decision where and how many bytes are in existence when in existence (step 407). Re-multiplexing is conducted in the step 408 by using information obtained in this check. That is, the stuffing bytes are replaced with private stuff data.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates generally to data recording and transmission using the MPEG standard, and in particular to MPE.
It relates to established standards for the transmission of "private data" and "stuffing bytes" in transport data streams according to the G standard.

[0002]

BACKGROUND OF THE INVENTION High Definition Television (HDTV)
It is continuing to replace the traditional television. Opening the way for this progress are various companies and organizations involved in the standards offered to the global HDTV market.

One of the gatherings of such companies is AT &
Known as the "Digital HDTV Grand Alliance" including T., David Sarnoff Research Center, Massachusetts Institute of Technology and others. An easy-to-understand overview of the developments made by this group is:
There is a paper (summer 1994) entitled "North American Digital Terrestrial HDTV: Grand Alliance HDTV System" by Robert Hopkins published as part of an IEEE transaction on consumer electronics. All of the teachings of this paper regarding the background and basics of HDTV systems, including the use of programs and transport packet streams, are incorporated herein by reference.

In addition to the Grand Alliance, much effort has also been put into place by the Moving Picture Experts Group (MPEG). MPEG is
HDT, which is a committee within the International Organization for Standardization (ISO)
Various standards are being established for the recording and transmission of V-data (eg, the format for the MPEG-2 standard transport packet stream).
The adopted standard is "The Video Section of Information Technology-General encoding of video and associated audio, ISO / IE
C 13818-2 "(November 1994) (hereinafter referred to as" video section ") and" System section of information technology-general encoding of moving images and accompanying audio,
ISO / IEC 13818-1 "(November 1994) (hereinafter referred to as" system section ") is regularly issued. The teachings of both standards on established standards and formats, including "stuffing" technology, are:
It is also incorporated by reference in the present specification.

The syntax of the MPEG-2 standard defines several layers of data records used to carry both audio and video data. For simplicity, the decoding of audio data will not be mentioned here. The encoded data that describes a video sequence is represented in several nested layers. That is, a sequence layer, a group of picture layer, a picture layer, a slice layer, and a macroblock layer. To aid in the transmission of this information, a digital data stream representing multiple video sequences is divided into a number of smaller units, each of these units corresponding to a packetized elementary stream (PES). It is contained in the packet. At the time of transmission, each PES packet is now divided into a plurality of fixed length transport packets. Each transport packet contains data for only one PES packet. The transport packet also includes a header with control information, sometimes including an adaptation field used in decoding the transport packet.

When an MPEG-2 encoded image is received, the transport decoder reconstructs the PES packet by decoding the transport packet. Now that the PES packet has been decrypted,
The MPEG-2 bitstream representing the image in the hierarchical record as described above is reconstructed. A given transport data stream carries multiple image sequences simultaneously, eg as interleaved transport packets. This flexibility allows the transmitter to switch between multiple formats, providing 4: 3 aspect ratio material according to one standard and widescreen (16: 9) material according to another. be able to.

Considering a method of implementing a system for delivering HDTV to consumers using the MPEG-2 standard, in general, as shown in the high level block diagram of FIG. The audio signals are input to the corresponding encoders 110 and 112, buffered in buffers 114 and 116 and carried to the system encoder / multiplexer 118 before being recorded by the recording unit 120 or transmitted by the transmitter unit 120. Do At the receive side, the signal is received by the system decoder / demultiplexer 122, buffered again in buffers 124 and 126, then decoded by decoders 128 and 130 and output as the original video and audio signals.

An important aspect of the example shown in FIG. 1 is that the buffering of the signal in the intermediate stage involves a variable delay, but the overall delay of the signal from the input to the output is substantially. Is required to be constant. This is accomplished by monitoring flow control and buffers.

As shown in FIG. 1, the delay from the input to the encoder to the output from the decoder, ie the presentation, is constant in this model,
The delay through each of the encoder and decoder buffers is variable. Not only is the delay through each of these buffers variable within the path of one elementary stream, but the individual buffer delays in the video and audio paths are also different from each other. Therefore, the relative position of the coded bits representing audio or video in the combined stream does not indicate synchronization information. The relative position of the encoded audio and video is limited only by the system target decoder (STD) model so that the decoder buffer can behave properly. Therefore, encoded audio and video representing audio and images that are to be played simultaneously can be separated by as much as a second in the encoded bit system. This value is the maximum decoder buffer delay allowed in the STD model. ST
Similar to the D model is the Video Buffering Verifier (VBV), which is described below in the "Video Section".

"A fixed rate coded video bitstream must meet the constraints imposed through the video buffering verifier (VBV) specified in this section ... VBV is a virtual decoder. Yes, this is conceptually connected to the output of the encoder. ... The encoded data is removed from the buffer as specified below. Bitstreams conforming to this specification must not overflow VBV. When low_delay is equal to zero, the bitstream should not underflow the VBV buffer. A high-level diagram showing an example of an STD model that operates in conjunction with an encoder is shown in FIG.

The requirement that the VBV buffer or STD model decoder must not underflow is so important that it can be said that it affects the quality of the product. To maintain constant bitrate video,
"Stuffing" takes place at various aspects of the system. "Stuffing" is the task of adding "don't care" information to the data stream merely to maintain the required bit rate.

For a transport stream packet carrying PES packets, P must be filled to fill the payload bytes of the transport stream packet to a level that can support the rate of data being transmitted.
Stuffing is used when there is insufficient ES packet data.

For example, stuffing is performed by defining an adaptation field that is longer than the sum of the lengths of the data elements within it.
As a result, the payload bytes remaining after the adaptation field can fit exactly the available PES packet data. Adaptation ·
Extra space in the field and / or payload can be filled with stuffing bytes.

FIG. 3 shows the format and field location for the transport packet stream, where each transport packet includes a header and a payload. The header of the transport packet contains multiple fields to indicate the presence of the adaptation field and control its length and content. In this adaptation field, another field is designated as "stuffing byte". The stuffing byte is also used in the payload of the transport packet.

However, as mentioned above, in the transport header, all of the values are typically logical ones (ie, "11111111"), and in the transport payload, all of the values are typically all logical zeros ( That is, using a stuffing byte that is "00000000" is a waste of system resources (eg, transmission bandwidth). Therefore, it is desired to more efficiently use the system resources that have been limited to "stuffing" until now.

[0016]

SUMMARY OF THE INVENTION In a system that uses stuffing bytes to fill a data stream, including variable bit rate video data in the form of data packets, the present invention eliminates stuffing bytes and private data (hereinafter Method and system for utilizing additional bandwidth for transmitting "private staff data"). The present invention examines a data packet that includes an indication of whether the stuffing byte is used in the data packet, and determines whether removing the stuffing byte according to a predetermined criteria qualifies the data packet. Check means for determining and responsive to the check means, means for removing stuffing bytes from the data packet and adding predetermined private stuff data to the data packet.

In one aspect of the invention, stuffing bytes are removed from the header portion of the data packet to obtain additional transmission bandwidth.

In another aspect of the invention, stuffing bytes are removed from the payload portion of the data packet to obtain additional transmission bandwidth. However, in both aspects, private stuff data is inserted in the header portion of the data packet.

[0019]

[Detailed Description] As described in the “Background” section, P
For transport stream packets carrying ES packets, stuffing is performed when there is insufficient PES packet data to fill the payload bytes of the transport stream packet to support the configured data rate. It is carried out. According to one method, stuffing is done by defining an adaptation field that is longer than the sum of the lengths of the data elements within it. As a result, the payload bytes remaining after the adaptation field can fit exactly the available PES packet data. The extra space in the adaptation field is filled with stuffing bytes. According to another method, stuffing is done by filling the unused part of the transport payload with zeros.

Widely applicable to variable bit rate video, the present invention utilizes "stuffing" dedicated resources that would otherwise be wasted to insert private data. In an embodiment of the present invention,
In order to utilize these resources, which were wasted in conventional methods, valuable private data is inserted in the transport stream instead of stuffing bits. That is, preferably, the re-multiplexing operation is performed so that the private data is used instead of the stuffing byte based on the existence of a predetermined condition (for example, the existence of the stuffing byte) in the field of the transport stream. The information required to use and must comply with the standard is generated and inserted appropriately.

It should be noted that although the present invention has been described as being broadly applicable to variable bit rate video,
It is inherently applicable to constant bit rate video.
That is, in the present invention, the modified video is always a variable bit rate video, but the original video to be processed and transmitted may be a constant bit rate video or a variable bit rate video.

The data used to replace the stuffing bytes is "private stuff" to distinguish it from typical private data that may otherwise be encoded in the transport stream.
Let's call it data.

When private stuff data is inserted into the transport stream, the private stuff data, if required, is a unique program identifier (PID) code that indicates that the current transport packet contains private stuff data. Can be sent with. As described in the system section, the PID is a 13-bit field in the transport stream header and indicates the type of data stored in the packet payload. Some PID values have been assigned and some are reserved. In an embodiment of the invention, the newly assigned PID value may be specified to indicate that the private data contained in a particular transport packet is in fact private stuff data rather than normal private data. . Decoding private stuff data will be easier at the receiving end if the newly assigned PID is used.

In addition to the stuffing bytes, some transport packets have a special null PI.
Specified as a null packet with D. Using the techniques described herein, the present invention allows null packets to be remultiplexed into private stuff data and all other suitable fields (eg,
By including the adaptation and private data fields) it is also possible to utilize the wasted resources of the null packet.

Furthermore, since stuffing bytes are used only "as needed", private stuff data is sent on a "burst" basis. That is, it is sent only when the video channel "desires" to send stuffing bytes. Information that may be sent as private staff data includes program reviews, program listings, etc. regarding programs to be subsequently transmitted.

By way of further background, in the system section, a syntax representation is provided for encoding / decoding the adaptation field of the transport header. This syntax is reproduced in Table 1.

[0027]

[Table 1]

As shown in Table 1, the stuffing bytes are placed in the transport header of the adaptation field as needed.

Referring to this syntax, the adaptation_field_lengt listed in Table 1 and shown in FIG.
h is ada immediately following adaptation_field_length
This is an 8-bit field that specifies the number of bytes in ptation_field. For example, in the exemplary embodiment, the value zero is used to insert a single stuffing byte in the transport stream packet.

Further, when the value of adaptation_field_control is "11", the value of adaptation_field_length is in the range of zero to 128. adaptation_field_
When the value of control is "10", adaptation_field_len
The value of gth is “183”.

Regarding the adaptation field,
stuffing_byte can be inserted by the encoder,
It is usually a fixed 8-bit value equal to "11111111". Once identified as the stuffing bit, this "don't care" information is discarded by the decoder at the receiving end.

Looking further at Table 1, in addition to the stuffing bytes, the standard syntax for adaptation fields provides private data. For example, as shown in FIG. 3, the two fields immediately preceding the stuffing byte field are designated as "5 flags" and "option field". The "Five Flags" field indicates whether or not the optional field is present, and if so, the optional field indicates the presence and length of the "transport private data". Similar relationships between fields are also shown in the syntax format of Table 1.

The stuffing byte can be used not only in the adaptation field of the transport header as described above, but also in the transport payload. According to the present invention, stuffing bytes may be removed from either the adaptation field or the transport payload to provide additional bandwidth for private stuff data. However, whether stuffing bytes are removed from the adaptation field and / or transport payload, or both, the private stuff data added to the packet in the embodiment of the invention is the transport header. It is added only to the adaptation field of.

FIG. 4a is a high level flow chart showing an example of the steps performed to accomplish the overall stuffing byte removal and replacement operation, also known as the "remultiplexing operation". Is.
This flow chart is for the purpose of generally describing stuffing byte substitution in either the adaptation field or the transport payload.

As shown in FIG. 4A, first, step 4
After a transport packet has been obtained from the transport stream at 02, step 404
At, the packet is inspected. This check includes a determination of whether stuffing bytes are present (step 405) and, if present, a determination of where and how many of them are present (step 407). Next, in step 408, a remultiplexing operation is performed using the information obtained during this inspection. That is, the stuffing bytes are replaced with private stuff data. Regarding each step described above, (b) of FIG. 4, FIG. 5 to FIG. 7 and (a) of FIG.
This will be described in more detail below with reference to (c).

FIG. 4 (b) is a high level flow chart diagram illustrating an embodiment of the steps performed by the present invention to replace the stuffing bytes in the adaptation field with private stuff data. As shown in FIG. 4B, first, step 4
At 10, a transport packet is obtained from the transport stream and then at step 412 the packet is examined. This inspection is the first
Includes a determination of whether the adaptation field is present (step 414). This determination is made by inspecting various fields. Next, if an adaptation field exists, it is determined whether private data exists in the adaptation field (step 416). In this embodiment, this determination is
This is done by examining the "Five Flags" field and the "Transport Private Data Length" field. If private data exists, the process ends. This is because in the embodiment of the present invention, such an adaptation field is not used for private staff data. Although it is not impossible to insert the private staff data when the private data already exists, in the present invention, the adaptation / data that already contains the private data is used.
I will not do anything that disturbs the field.

The description of the flowchart of FIG. 4B will be continued. If no private data is present, the remultiplexing operation is performed at step 420 after the location and number of stuffing bytes are determined at step 418 using information obtained from the various fields.

Next, the description will be made on the remultiplexing operation. Here, no matter how the adaptation field is changed, the change should be made in accordance with the established standard (that is, in accordance with the format shown in FIG. 3 and the syntax shown in Table 1). It is important to note that Therefore, if you want to replace the stuffing bytes in the adaptation field with private stuff data, not only is the private stuff data simply multiplexed into the data stream, but all of the right bits in the right field are matched accordingly. Will be set. For example, if in some adaptation fields the optional field was not present at the time of the first inspection, after the remultiplexing operation, it is possible to reflect that the optional field is present by saying "5 The "Flags" field is changed. In addition, the number of private stuff bytes is added to the "Transport Private Data Length" field to correctly indicate that the adaptation field has changed.

Those skilled in the art who are aware of established standards, including the standards incorporated by reference herein, may be present in an attempt to replace the stuffing bytes with private stuff data. By recognizing a wide variety of field combinations, it can be seen that all necessary fields must be modified during the remultiplexing operation to reflect the updated content of the adaptation fields. Let's do it.

It should be noted that the present invention is not limited to the understanding ability of those skilled in the art.
(a) ~ (c) are required to detect and remove stuffing bytes from a single transport payload,
FIG. 6 is a flow chart and field permutation diagram detailing the steps required to utilize the resulting extra bandwidth for transmitting private stuff data in the adaptation field in the transport layer.

It should be noted that the methods illustrated in FIGS. 5-7 and 8 (a)-(c) are as follows: 1) Based on the structure of the adaptation field (described above), the video in the transport packet Find the minimum required number of stuffing bytes, 2) detect the location of each video stuffing byte in the transport payload and remove those bytes from the payload, 3) place the private data in the adaptation field. This is a method of inserting and further 4) detecting the location of the picture header structure and replacing its VBV_DELAY value with 0xFFFF.

Further, in the method illustrated in FIGS. 5 to 7 and FIGS. 8A to 8C, 1) the program association table (PAT) and the program map table (PMT) have already been processed, It is also assumed that the target video elementary stream has already been recognized, and 2) the payload parsing of the transport payload containing the video elementary stream is from the first video sequence or before that. It shall start and end with a sequence end code.

Now, the description moves to FIGS. 5 to 7. In the process shown in these figures, several field sizes are tracked and many fields are examined in the transport header and payload. To that end, multiple variables are used throughout the process. In particular, the names of the variables shown below for each of FIGS. 5, 6 and 7 are:
The specific variables used for each flow chart and their corresponding definitions are shown.

Variables used in FIG . 5 Cnt_V_ZB = Video zero byte counter StrtCd_Fnd = Flag indicating start code discovery PictStrtCd_Fnd = Flag indicating picture start code discovery MIN_V_SB = Video stuffing that must be present in the TP packet Minimum number of bytes Cnt_V_SB = Counter for video stuffing bytes Cnt_Pyld_B = Counter for TP payload bytes Variable used in Fig. 6 PictStrtCd_Fnd = Flag indicating the discovery of the picture start code StrtCd_Fnd = Flag indicating the discovery of the start code Cnt_Pict_Hdr = Picture header structure variables used in the byte counter 7 in Cnt_Pyld_B = TP payload byte counter Cnt_V_SB = video stuffing byte counter Cnt_V_ZB = video zero byte counter Cnt_Cur_SB = current video staff Referring to flag Figure 5 displays a counter StrtCd_Fnd = start code found in Ngubaito, in step 510-514, the variables used in the process "Cnt_V_ZB", "StrtCd
"_Fnd" and "PictStrtCd_Fnd" are initialized. Preprocessing is performed in steps 516 and 518 to detect the next sync byte and verify that the PID is for an elementary video program.

In steps 520, 522 and 524, the process checks the adaptation field control field and the length field of the adaptation field, which is then present in the transport packet based on the result of the check. A variable indicating the minimum number of stuffing bytes that need to be set is set in steps 526 and 528.

Next, in step 530, it is determined whether private data is present in this adaptation field. Then, based on that determination, the variable indicating the minimum number of stuffing bytes that need to be present in the TP packet is set again in this process at step 532. here,
As described above, if it is determined that the private data already exists in the adaptation field, the process ends, and another process is newly started.

The process of FIG. 5 then jumps to the first byte of the payload at step 536, while at step 538 the variables "Cnt_V_SB" and "Cnt_Pyld_B".
Is initialized.

Now, step 540 which includes links leading to the flow charts shown in FIGS. 6 and 7.
Essentially corresponds to step 404 in FIG. 4 (a). Here, the number of stuffing bytes and their location are determined. The flowchart of FIG. 6 detects and tracks the start code in the payload, and the flowchart of FIG. 7 detects and counts the stuffing bytes. Tracking where and how many bytes are in each allows this process to eliminate stuffing bytes (which can bring additional bandwidth to private stuff data) and picture data. Allows you to save. In step 541, "Cn
By checking "t_V_SB", this variable is
You can check if it is larger than N_V_SB. The purpose of step 541 is to determine if the number of stuffing bytes found in this transport packet is greater than the minimum number of stuffing bytes that need to be present to complete remultiplexing. Make sure.

Finally, (step 4 in FIG. 4A)
In steps 542 and 544 (corresponding generally to 08), stuffing bytes are removed and private stuff data is remultiplexed with the appropriate control field changes, respectively. This remultiplexing operation represented by step 544, an example of which is shown in FIGS. 8 (a), (b) and (c), is described in more detail below.

Referring to FIG. 6, the process determines the format of the start code used by the meaningful data (eg, picture data) in the payload of the transport packet until the start code is encountered until the start code is encountered. Count the stuffing bytes in the payload. The syntax for the various start codes is shown in the video section. By carrying out this processing, it is possible to surely prevent the meaningful data carried by the transport packet payload from being disturbed.

As shown in steps 610 and 612, the process in FIG. 6 is performed in the same manner as PictStrtCd_Fnd or while StrtCd_Fnd is equal to "1".
It will continue to recognize and process this transport payload one byte at a time until there is a condition where both trtCd_Fnd and StrtCd_Fnd are equal to "0". When this condition is detected, the process shifts to the steps shown in FIG. 7 which try to track and identify the stuffing bytes.

In the meantime, if PictStrtCd_F
If nd is equal to “1”, then in step 630 Pi
Until ctStrtCd_Fnd is finally reset, the picture header bytes that follow are steps 614, 616, 6
Tracked and processed at 18, 620, 622, 624, 626 and 628. Also, if PictSt
If rtCd_Fnd is equal to "0" but StrtCd_Fnd is equal to "1", then PictStrtCd_Fnd is set in step 634 or the current byte of data is set in step 632 so that StrtCd_Fnd is reset in step 638. , 634, 636 and 638.

The variables PictStrtCd_Fnd and StrtCd_F
The state of nd may reflect the conditions processed and determined in the immediately preceding transport payload. That is, the picture data or stuffing bytes can overlap across one or more transport payloads. Therefore, if the previous transport payload ends with a start code, it should be taken into account when processing the current transport payload. This is because the transport packet is only part of a larger PES packet. For example, 3
Considering two consecutive transport packets, stuffing can start halfway through the payload of the first packet, continue through the full payload of the second packet, and end halfway through the third packet. . These types of conditions should be considered when detecting and removing stuffing bytes.

Referring to FIG. 7, the process proceeds to search for stuffing bytes. This search is done by carefully checking all bit values and tracking the location of the multiple points used to eliminate stuffing bytes after identifying them. Briefly, steps 710 and 712 process and count the zero bytes that are encountered. As a result, the byte to be processed is "0" corresponding to the NO exit path from step 710.
There is a high possibility that it will not be "x00", but will be "0x01" that indicates that the start code has been found, corresponding to the YES exit path of step 716. At this point, the variable StrtCd_Fnd used in FIG. 6 is set in step 718 to stop the stuffing byte counting operation. The actual number of stuffing bytes is Cnt_V_
Determined in step 720 by subtracting 2 from ZB. This is because the start code contains 23 logic 0's and one logic 1's. However, since step 716 only checks for seven logic 0's and one logic one, an additional 16 logic 0's (ie, 2 bytes of "0x0000") are not considered stuffing bytes.

Therefore, if in step 722 the number of stuffing bytes, Cnt_Cur_SB, is less than the payload byte count and is not equal to zero in step 724, it has been used to count and mark points of interest in payload processing. Cnt_
Variables such as Pyld_B and Cnt_V_SB are used to calculate and record the location and amount of stuffing bytes. Note that the number of stuffing bytes calculated during this process is then added in step 728 to the number of previously recorded stuffing bytes.

There is no reason to add any further explanation with respect to FIGS. 6 and 7. This is because the above description including the description described with reference to FIGS. 5 to 7 and (a) to (c) of FIG. 8 in the present specification has already been grasped and is incorporated in the present specification. This is because one of ordinary skill in the art who is already familiar with a number of established standards, including those standards, can understand the processes described in FIGS.

FIGS. 8A-8C show examples of transport packets before and after the process according to the present invention described in FIGS. 5-7. In particular, (a) of FIG. 8 is a field replacement diagram (that is, a diagram showing the original packet and the processed packet) regarding a transport packet that originally did not have an adaptation field. This figure corresponds to the YES path exiting from step 520 of FIG.
As shown in Figure 8 (a), the transport packet payload has its stuffing bytes removed, and the appropriate fields needed to represent the transport headers that carry private data. Has been generated, and the packet has been reassembled so that the payload no longer contains stuffing bytes. The various newly formed fields (eg the length of the adaptation field) as seen in the name below where the processed transport packet is shown.
Many of the values placed in the are obtained from the state of each variable (eg, Cnt_V_SB) used during the processing in FIGS.

FIG. 8B shows a case in which the transport packet includes an adaptation field, but the length of the adaptation field is zero bytes. This figure shows step 52 of FIG.
Corresponds to the YES path from 2 and 524. Again, the stuffing bytes have been stripped from the transport payload and the appropriate adaptation field has been created and / or modified according to the value of the variable.

FIG. 8C shows still another embodiment in the case where the adaptation field exists, but the length of the adaptation field is not equal to zero, and there is no private. This figure corresponds to the NO path emerging from step 530 of FIG. In this case as well, the same stuffing byte removal and adaptation field change are performed.

FIG. 9 is a block diagram showing an embodiment of a private stuff processor preferably used in the present invention. In FIG. 9, the transport stream is acquired in the buffer 910 at the same time as being monitored by the analyzer 912. The analyzer 912 uses steps 402 to 404 in FIG.
Most of the processing corresponding to steps 410 to 418 in (b) is performed, and in payload processing, processing including all steps shown in FIGS. 5 to 7 except step 544 is performed. Next, the analyzer 912
Gives an instruction to the remultiplexer 914 as to whether to perform a remultiplexing operation and what information to use. Remultiplexer 914
Performs the processing corresponding to steps 408, 420 and 544. Also in this case, the transport stream provided by the buffer 910 is temporarily delayed by the buffer 916. Buffers 910 and 916 are generally used to compensate for the processing delays of analyzer 912 and remultiplexer 914, respectively. The controller 918 performs miscellaneous control operations, including controlling the data flow through these buffers, and ultimately, whether the transport packet exits through the multiplexer 920, that is, the processed remultiplexer 916. Determines if there is output.

It should be noted that only the flowchart widely used for processing the stuffing bytes in the adaptation field is shown ((b) in FIG. 4), but those skilled in the art can understand the information disclosed in the present specification and the known method. By utilizing this information, it will be easy to detect and remove the stuffing bytes from the adaptation field and to create or modify the field in the adaptation field. For example, the corresponding field permutation diagram in this case would be that the original transport packet would contain stuffing bytes before the TP payload, and the processed transport packet would have new private data in the adaptation field ( That is, it is very similar to (c) of FIG. 8 except that it includes private stuff data at the appropriate private data location but does not include stuffing bytes. In addition, each field location described in Table 1 and shown in FIG. 3 provides the details necessary to detect and remove stuffing bytes from the adaptation field.

While the present invention has been described and described as being implemented in the form of a method and apparatus for using private stuff data in place of stuffing bytes in an MPEG encoded data stream, the present invention has been shown above. The details are not limited to the specific details, and various modifications can be made to the details within the scope equivalent to the appended claims and without departing from the concept of the present invention.

[Brief description of drawings]

FIG. 1 (Prior Art) is a high level block diagram illustrating an example of a digital multi-program transmission / reception system.

FIG. 2 (Prior Art) FIG.
2 is a high-level block diagram shown with a portion of the system shown in FIG.

FIG. 3 (Prior Art) is a diagram showing an example of a format for a transport packet stream used in cooperation with the system shown in FIGS. 1 and 2, including each field designation.

FIG. 4 (a) is a high level flow chart diagram illustrating an example of steps performed by the present invention to replace stuffing bytes with widely private stuff data. (b) is a high level flow chart diagram illustrating an example of the steps performed by the present invention to replace the stuffing bytes in the adaptation field with private stuff data.

FIG. 5 is a flow chart diagram illustrating an embodiment of steps performed by the present invention to replace stuffing bytes in a packet payload with private stuff data.

FIG. 6 is a flowchart showing an embodiment of a start code processing technique preferably used in the embodiment shown in FIG.

7 is a flowchart showing an embodiment of a stuffing byte search technique preferably used in the embodiment shown in FIG.

8 (a)-(c) are diagrams illustrating three embodiments of stuffing byte replacement operations performed by the techniques shown in FIGS. 5-7, respectively.

FIG. 9 is a high-level functional block diagram showing an embodiment of an encoder preferably used in the present invention.

Claims (18)

[Claims] 1. A stuffing byte is used instead of the stuffing byte in a system using stuffing bytes to fill a data stream and including constant bit rate video data in the form of data packets and variable bit rate video data. A system using data, wherein analyzing the data packet including an indication of whether or not the stuffing byte is used in the data packet, and removing the stuffing byte according to predetermined criteria is performed. Responsive to the checking means for removing the stuffing byte from the data packet and adding predetermined private stuff data to the data packet; Equipped and have the system. 2. The system of claim 1, wherein the data packet includes a header portion and a payload portion, and the stuffing byte has its location detected in the header portion. 3. The system of claim 1, wherein the data packet includes a header portion and a payload portion, and the stuffing byte has its location detected in the payload portion. 4. The data packet includes a header portion and a payload portion, the data packet further including an indication as to whether private data is carried by the header portion of the data packet, and The system of claim 1, wherein the predetermined criterion is the absence of private data carried by the header portion of the data packet. 5. The system of claim 1, wherein the data packet includes a header portion and a payload portion, and the private stuff data is inserted within an adaptation field in the header portion. 6. A stuffing byte is used to fill a data stream, and the stuffing byte is removed from a data packet in a system including constant bit rate video data in the form of a data packet and variable bit rate video data. A method for generating an additional band by transmitting the private stuff data by using the additional band and analyzing the data packet including an indication of whether or not a stuffing byte is used in the data packet. And, in response to the parsing step, removing the stuffing byte from the data packet, determining whether the stuffing byte is eligible for the data packet according to a predetermined criterion. Additional biography Generating a band, by adding a predetermined private stuff data into the data packet, the method comprising the steps of: using said additional transmission bandwidth. 7. The method of claim 6, wherein the data packet includes a header portion and a payload portion, and the stuffing bytes are removed from the header portion. 8. The method of claim 6, wherein the data packet includes a header portion and a payload portion, and the stuffing bytes are removed from the payload portion. 9. The data packet includes a header portion and a payload portion, the data packet further including an indication as to whether private data is carried by the header portion of the data packet, and 7. The method of claim 6, wherein the predetermined criterion is the absence of private data carried by the header portion of the data packet. 10. The method of claim 6, wherein the data packet includes a header portion having an adaptation field and a payload portion, and the private stuff data is added by being inserted into the adaptation field. The method described. 11. In a system that uses stuffing bytes to fill a data stream and includes fixed bit rate video data in the form of data packets and variable bit rate video data, instead of the stuffing bytes, private stuffing bytes. A system using data, wherein means for analyzing the data packet including an indication as to whether or not the stuffing byte is used in the data packet, and the stuffing byte for the data packet are responsive to the checking means. And re-multiplexing means for removing from the data packet and adding predetermined private stuff data to the data packet. 12. The system of claim 11, wherein the data packet includes a header portion and a payload portion, and the stuffing byte has its location detected in the header portion. 13. The system of claim 11, wherein the data packet includes a header portion and a payload portion, and the stuffing byte has its location detected in the payload portion. 14. The system of claim 1, wherein the data packet includes a header portion and a payload portion and the private stuff data is inserted in an adaptation field within the header portion. 15. A system for using stuffing bytes to fill a data stream and including constant bit rate video data and variable bit rate video data in the form of data packets, wherein the stuffing bytes are removed from the data packets. A method for generating an additional band by transmitting the private stuff data by using the additional band and analyzing the data packet including an indication of whether or not a stuffing byte is used in the data packet. Generating an additional transmission band by removing the stuffing bytes from the data packet in response to the analyzing step, and adding the predetermined private stuff data to the data packet. A step of using a band. 16. The method of claim 15, wherein the data packet includes a header portion and a payload portion, and the stuffing byte is removed from the header portion. 17. The data packet includes a header portion and a payload portion, and the stuffing byte is removed from the payload portion.
The method described in. 18. The method of claim 15, wherein the data packet includes a header portion having an adaptation field and a payload portion, and the private stuff data is added by being inserted in the adaptation field. The method described.