Pulse or digital communications – Bandwidth reduction or expansion – Television or motion video signal
Reexamination Certificate
2001-03-30
2004-08-17
Rao, Andy (Department: 2613)
Pulse or digital communications
Bandwidth reduction or expansion
Television or motion video signal
C375S240280
Reexamination Certificate
active
06778610
ABSTRACT:
BACKGROUND OF INVENTION
This invention relates to video compression, and more particularly to error recovery from errors in synchronization fields.
Video is an important 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 inventor realizes 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. The video object plane VOP start code is:
0000 0000 0000 0000 0000 0001 1011 0110.
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 macroblock 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. 2
is a table of codes for the resync markers that marks the beginning of a new video packet. An f_code for each VOP is encoded into a 3-bit field in the VOP header. When the VOP specifies that the frame's f_code is 1, then each video packet VP in the frame begins with a 17-bit resync marker:
0000 0000 0000 0000 1
which has an initial run of 16 zeros.
When f_code is set to 3, a 19-bit resync marker is used for all video packets in the frame, with an initial run of 18 zero bits. The f_code can be set to values from 1 to 7. For f_code=7, a 23-bit resync marker with an initial run of 22 zero bits is specified. Different values of f_code and the corresponding resync markers used are shown in the table, along with the lengths of the resync markers, which vary from 17 to 23 bits.
All resync markers begin with a long run of zero bits, from 16 to 22 bits of zero. Note that the VOP start code is 24 bits, longer than any possible resync marker. 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.
The f_code also specifies the motion-vector search range used by the encoder and thus the number of bits that can be used to encode the motion vector. For f_code=1, the maximum search range is [−32,31] half-pixels, or about +/−16 pixels, with a half-pixel resolution. The search range doubles for each higher value of f_code, to [−64,63] for f_code=2, up to [−2048,2047] for the maximum f_code=7. This provides a maximum search range of about 1K pixels.
Larger search ranges are desirable since the encoder is more likely to find a pixel match for a macroblock within a larger area of the image. Thus encoding efficiency improves when larger search ranges and larger f_codes are used.
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 always:
0000 0000 0000 0000 1
which has an initial run of 16 zeros. While useful for simplifying the search for resync markers, limiting the f_code to 1 also limits the motion-vector search range and thus the coding efficiency.
FIG. 3
is a diagram of an MPEG-4 decoder. The MPEG-4 bitstream is parsed by parser
50
, which searches for start-code and resync bit patterns. A bit-wise comparator can be used, comparing the last N bits received to a Q-bit pattern of the start code or resync marker. When the last N bits match the VOP start code, start-code and VOP header decoder
56
sends some of the VOP header information to bitstream decoder
52
and instructs it to decode the bits following the VOP header as the data fiel
Auvinen Stuart T.
Parsons Charles E
Rao Andy
RedRock Semiconductor, Ltd.
LandOfFree
Simultaneous search for different resync-marker patterns to... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Simultaneous search for different resync-marker patterns to..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Simultaneous search for different resync-marker patterns to... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3358009