Pulse or digital communications – Bandwidth reduction or expansion – Television or motion video signal
Reexamination Certificate
2001-03-02
2004-04-27
Kelley, Chris (Department: 2613)
Pulse or digital communications
Bandwidth reduction or expansion
Television or motion video signal
C375S240280, C375S369000
Reexamination Certificate
active
06728318
ABSTRACT:
BACKGROUND OF INVENTION
This invention relates to video compression, and more particularly to error recovery from errors in synchronization fields.
Video is a key part of a rich multimedia experience. Personal computers (PC's) and various other computing devices have delivered video feeds to users over the Internet. However, processing of video bitstreams or feeds is among the most data-intensive of all common computing applications. Limited communication-line bandwidth has reduced the quality of Internet video, which is often delivered in small on-screen windows with jerky movement.
To mitigate the problems of large video streams, various video-compression techniques have been deployed. Compression standards, such as those developed by the motion-picture-experts group (MPEG), have been widely adopted. These compression techniques are lossy techniques, since some of the picture information is discarded to increase the compression ratio. However, compression ratios of 99% or more have been achieved with minimal noticeable picture degradation.
Portable hand-held devices such as personal-digital-assistants and cellular telephones are widely seen today. Wireless services allow these devices to access data networks and even view portions of web pages. Currently the limited bandwidth of these wireless networks limits the web viewing experience to mostly text-based portions of web pages. However, future wireless networks are being planned that should have much higher data transmission rates, allowing graphics and even video to be transmitted to portable computing and communication devices.
Although proponents of these next-generation wireless networks believe that bandwidths will be high enough for high-quality video streams, the inventors realize that the actual data rates delivered by wireless networks can be significantly lower than theoretical maximum rates, and can vary with conditions and local interference. Due to its high data requirements, video is likely to be the most sensitive service to any reduced data rates. Interference can cause intermittent dropped data over the wireless networks.
Next-generation compression standards have been developed for transmitting video over such wireless networks. The MPEG-4 standard provides a more robust compression technique for transmission over wireless networks. Recovery can occur when parts of the MPEG-4 bitstream is corrupted.
FIG. 1
shows a MPEG-4 bitstream that is composed of video object planes and video packets. The video is sent as a series of picture frames known as video object planes (VOP). These picture frames are replaced at a fixed rate, such as every 30 milliseconds to give the illusion of picture movement. Rather than transmit every pixel on each line, the picture is divided into macroblocks and compressed by searching for similar macroblocks in earlier or later frames and then replacing the macroblock with a motion vector or data changes.
Video object planes VOP
10
,
12
are two frames in a sequence of many frames that form a video stream. Pixel data in these planes are compressed using macroblock-compression techniques that are well-known and defined by the MPEG-4 standard. The compressed picture data is divided into several video packets (VP) for each video object plane VOP.
Each video object plane begins with a VOP start code, such as VOP start code
20
which begins VOP #
1
(
10
), an VOP start code
21
, which begins VOP #
2
(
12
). First video object plane VOP
10
has VOP header
22
that follows VOP start code
20
, and data field
24
which contains the beginning of the picture data for VOP
10
. After a predetermined amount of data, such as 100 to 1000 bits, a new video packet begins with resync marker
30
and VP header
32
. Data field
34
continues with the picture data for VOP
10
. Other video packets follow, each beginning with a resync marker and VP header, followed by a data field with more of the picture data for VOP
10
. The last video packet VP #N in VOP
10
begins with resync marker
31
and VP header
33
, and is followed by the final picture data for VOP
10
, in data field
35
.
The second video object plane VOP
12
begins with VOP start code
21
and VOP header
23
, and is followed by data field
25
, which has the first picture data for the second picture frame, VOP
12
. Other video packets follow for VOP
12
.
The VOP headers include a VOP coding type (I, P, or B), VOP time, rounding type, quantization scale, f-code, while the VP headers include a macroblock number for the first macroblock in the packet, quantization scale, VOP coding type and time. The headers can include other information as well.
The VOP start codes and VP resync markers contain unique bit patterns that do not occur in the headers or data fields.
FIG. 2A
shows a video object plane VOP start code. This code is defined by the MPEG-4 standard. The start code is 000001 B6 in Hexadecimal notation. The start code begins with a string of 23 zero bits. The picture data in the data fields are encoded so that they never have such a long string or run of zero bits. Likewise, the headers do not have such a long run of zero bits. Thus the start code is unique within the video bitstream, allowing a bitstream decoder to easily detect the start code.
FIG. 2B
is a table of codes for the resync markers that marks the beginning of a new video packet. The f-code specifies the motion vector search range and the number of bits that can be used to encode the motion vector. For f-code=1, the maximum search range is +/−16 pixels, with a half-pixel resolution.
All resync markers begin with a long run of zero bits, from 16 to 22 bits of zero. Note that the VOP start code has a longer run of 23 zero bits, allowing the VOP start code to be distinguished from the VP resync markers.
A simplification of the MPEG-4 standard sets the f-code to 1 for all video packets. This simplification is known as simple profile level 0. In this case the resync markers are:
0000 0000 0000 0000 1
which has an initial run of 16 zeros.
FIG. 3
is a diagram of an MPEG-4 decoder. The MPEG-4 bitstream is parsed by parser
50
, which searched for start-code and resync bit patterns. A bit-wise comparator can be used, comparing the last Q bits received to a Q-bit pattern of the start code or resync marker. When the last Q bits match the VOP start code, start-code decoder
56
instructs bitstream decoder
52
to decode the following bits as the VOP header, followed by the data field of the initial video packet. The picture data from the data field is output as the video data for further processing of motion vectors and macroblocks (de-compression).
When the last Q bits received by parser
50
match a resync bit pattern, resync marker decoder
58
instructs bitstream decoder
52
to decode the following bits as the VP header, followed by the data field for the video packet. The picture data from the data field is output as the video data for further processing of motion vectors and macroblocks.
When the bit pattern is neither a start code, nor a resync marker or their headers, macroblock decoder
55
decodes the data fields into the macroblock descriptions, motion vectors, and discrete cosine transform (DCT) coefficients of the picture data.
Errors can be detected when an invalid motion vector or discrete cosine transform (DCT) code is found. However, there is no standard error-detection method. When an error is detected by bitstream decoder
52
parser
50
is instructed to search for the next VOP start-code or VP resync marker. Any data in the bitstream is ignored once the error occurs until the next start code or resync marker is found. When start-code decoder
56
finds a start code in the bitstream, decoding can continue with the next VOP header. The data following the VOP header is processed, but any video data after the error until the VOP header is discarded since the location of the macroblocks and motion vectors in the bitstream are uncertain due to loss of sync from the error. Backward decoding may be used to recover som
Lin Tao
Molloy Stephen
Auvinen Stuart T.
Kelley Chris
Parsons Charles
RedRock Semiconductor, Ltd.
LandOfFree
Error recovery of corrupted MPEG-4 bitstreams using fuzzy... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Error recovery of corrupted MPEG-4 bitstreams using fuzzy..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Error recovery of corrupted MPEG-4 bitstreams using fuzzy... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3221789