USPatent applicationPatented

Video compression system

Granted 11 Apr 2006 · 2 office actions

Current assignee: Google · originally Snap-on Incorporated

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Paul G. Wilkins, James B. Bankoski, Eric L. Ameres, Scott J. La Varnway +2 · Examiner: Tommy D. Lee · AU 2624 · TC 2600

Application· this page
10/219,774
filed 15 Aug 2002
Publication
Not published
not published
Patent
US 7,027,654
granted 11 Apr 2006

Life of the application

15 dated events
⤢ drag to zoom20022004200620082010201220142016201820202022ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

An improved video compression system in which the coefficient transform is sped up via folding transposition of coefficients into the token extraction phase. This is accomplished by filling a group of blocks coefficient buffers with 0\'s before the start of coefficient decoding, extracting the token from the bitstream and placing any extracted coefficient value which is non zero into the transposed order that best suits the target processor.

Description

8 parts
›RELATED APPLICATIONS

This nonprovisional application claims domestic priority to prior provisional application Ser. No. 60/312,941, filed Aug. 16, 2001, and to provisional application Ser. No. 60/316,316, filed Aug. 31, 2001. Both provisional applications are incorporated herein by reference.

›PRIOR ART

U.S. Pat. Nos. 6,178,205; 6,167,164; and 6,188,799 entitled “AN EFFICIENT REAL TIME ALGORITHM TO SIMULTANEOUSLY REDUCE BLOCKING AND RINGING ARTIFACTS OF COMPRESSED VIDEO” by Min-Cheol Hong, Chang Mo Yon and Young Man Park, assigned to Digital Media Research Lab IEEE 1999.

›COMPUTER PROGRAM LISTING APPENDIX

The following computer software files, submitted herewith on one (1) CD-R compact disc, are incorporated by reference herein:

›BACKGROUND AND GENERAL DESCRIPTION

This application specifically relates to a method and apparatus for reducing the decode complexity of two dimensional inverse transforms on a vector process.

A typical digital video decoding system involves the following steps (among others).

For each block in a frame:

A) Extract quantized transform coefficients from the compressed bit-stream B) Perform inverse quantization to reconstruct the transform coefficients C) Perform an inverse transform (typically an IDCT) on the coefficients D) Add the resultant values to a block predictor E) Output the block results

The 2-dimensional inverse transform functions typically take a large portion of the time to decode a frame due to their complexity.

The invention described here attempts to reduce the decoder complexity on vector processing machines that are capable of doing the same operation to multiple values stored sequentially in a machine's registers by lowering the complexity of the 2 dimensional transform.

A 2-dimensional separable inverse transform performed on a block typically involves performing the following steps:

a) For each row of the block:

Perform the same 1-dimensional inverse transform on the transform coefficients.

b) For each column of the block column (resulting from (a)):

Perform the same 1-dimensional inverse transform on the transform coefficients.

Since the 1-dimensional inverse transform usually involves performing exactly the same operations on a number of rows or columns in the block, vector processors are often used to reduce the decoding time. This is typically accomplished by filing vector processing registers with a value from each of N rows in the block (see diagram). The operations of the inverse transform are then performed on the N rows in parallel. And then the vector processing registers are filled with values from each of the N columns in the block and the inverse transform is then performed on the N columns in parallel.

In order to fill the vector processing registers quickly with different values from each row a programmer typically has two options:

a) Transpose the coefficients so that the transform coefficients appear in the order that matches the vector processor and load them directly into the registers. b) Fill the vector registers one value at a time with the coefficient data.

Choice (a) requires numerous operations to perform the transpose and choice (b) requires numerous bit-mask AND/OR operations to place each coefficient into the register.

›SUMMARY OF THE INVENTION

This invention attempts to address these issues. To do so:

a) Fill an entire frame's coefficient buffers with 0 before the start of coefficient decoding. b) Extract the transform coefficient for a token from the bit-stream. c) If the coefficient value is non-zero place it in the transposed order that best suits the target vector processor.

This works better than performing the transpose or filling the vector registers one at a time as part of the inverse transform because there are typically many more zero than non-zero coefficients. As such we make only a few positional changes, and avoid doing one full transpose altogether.

Additional savings are achieved by an embodiment of this technique whereby the same coefficient for every block in the image is encoded in the bit-stream before moving on to the next coefficient. In this way, one look up can be performed for each coefficient in the transform to determine where to place the transform coefficient.

Since each processor has vector registers with different cardinality it is necessary to place the coefficients in the order that best suits the processor being used.

The specific embodiment uses an IDCT transform but the technique is equally applicable to any separable 2-dimensional transform, for example, the discrete wavelet transform or the generalized orthogonal transform.

›BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the embodiment.

FIG. 2 is an overview block diagram of the embodiment.

›DESCRIPTION OF THE PREFERRED EMBODIMENT · 1 of 2

The invention includes enhanced video processing and compression and is further described hereinafter.

The encoder uses a motion estimator, block based 8×8 Discrete Cosine Transform (DCT), a quantizer, a variable length encoder, and a loop filter for smoothing block edges in the reconstruction buffer. The decoder uses a variable length decoder and inverse quantizer, a motion compensator and a loop filter for smoothing block edges.

Two separate image artifacts are produced as a result of the quantization step. A blocking artifact is produced when quantization of the DCT coefficients in adjacent blocks produces pixel values on the shared block edge that differ on either side of the edge by a greater amount than in the original image. A ringing or mosquito artifact results from the quantization of higher frequency components of the transform around strong edges in the image. This means that the transform basis vectors do not reinforce and cancel correctly, producing edges in the reconstruction near to the strong edge that were not present in the original image.

The current invention embodies two separate but dependent filters that attempt to remove these image artifacts in a manner that is low on decoder complexity:

a) a de-blocking filter that reduces the blocking artifacts described above b) an edge-enhancement and de-ringing filter that attempts to reduce the mosquito noise or ringing artifacts at the same time it sharpens real text images.

A block diagram of the vectorized de-blocker is shown in FIG. 2 .

The de-blocking filter of FIG. 2 works as follows:

Define an array, BlockSadArray, that contains one entry for each 8×8 block in the image. Initialize each entry of BlockSadArray to the value 0. For every border between two 8×8 blocks of the image:

At each of the eight positions along the border, examine the 10 pixels that lie in a direction perpendicular to the border, five from each block on either side (see diagram). Label these 10 pixels x0 . . . x4 and x5 . . . x9, respectively. Computer the following sums at each of the eight positions on the border:

If the following condition is met:

Side 1 Sad< 3*T1/2 and

Side 2 Sad< 3*T2/2 and

Abs ( x 4 −x 5)< T 3,

then replace values x1 to x8 with low pass filtered values x1 to x8 as follows:

x 1′=( x 0+ x 0+ x 0+ x 1*2+ x 2+ x 3+ x 4+4)/8

x 2′=( x 0+ x 0+ x 1+ x 2*2+ x 3+ x 4+ x 5+4)/8

x 3′=( x 0+ x 1+ x 2+ x 3*2+ x 4+ x 5+ x 6+4)/8

x 4′=( x 1+ x 2+ x 3+ x 4*2+ x 5+ x 6+ x 7+4)/8

x 5′=( x 2+ x 3+ x 4+ x 5*2+ x 6+ x 7+ x 8+4)/8

x 6′=( x 3+ x 4+ x 5+ x 6*2+ x 7+ x 8+ x 9+4)/8

x 7′=( x 4+ x 5+ x 6+ x 7*2+ x 8+ x 9+ x 9+4)/8

x 8′=( x 5+ x 6+ x 7+ x 8*2+ x 9+ x 9+ x 9+4)/8

The invention encompasses the following novelty:

1: The decision as to whether or not to perform the de-blocking operation can easily be computed for several positions at a time using a vector processor (such as Intel Corporation Inc.'s MMX architecture) with very few operations. 2: The filter applied itself is much simpler than most and requires far fewer operations than those found in the prior art.

b) The edge enhancement and de-ringing filter works as follows:

For each 8×8 block in the image:

Let BSAV be the BlockSadArray value corresponding to the current block. Define three threshold values Medium Thresh, High Thresh, Highest Thresh that are computed as a function of the quantization level such that Highest Thresh>High Thresh>Medium Thresh IF (BSAV>Highest Thresh)

Apply the strong de-ringing filter in place to the block (described below) multiple times (based on how high BSAV is)

ELSE IF (BSAV>High Thresh)

Apply the strong de-ringing filter to the block (described below)

ELSE IF (BSAV>Medium Thresh)

Apply the weak de-ringing filter to the block (described below).

The strong de-ringing filter works as follows:

Calculate a maximum blurring modifier (HighModifier) and maximum sharpening modifier (LowModifier) by looking up a value based upon the level of quantization applied to the coefficients.

For the j th pixel in the i th image row, P i,j , do the following:

Calculate the following four values:

M 0 =DeringModifier(P i,j , P i−1,j )

M 1 =DeringModifier(P i,j , P i+1,j )

M 2 =DeringModifier(P i,j , P i,1−j )

M 3 =DeringModifier(P i,j , P i,−j+1 )

Where DeringModifier(X,&) is defined as follows:

Value=Constant+QuantizationLevel−Abs(X−Y) IF (Value<LowModifier)

Value=LowModifier

IF (Value>HighModifier)

Value=HighModifier

Replace Pixel P i,j with P i,j ′ computed as follows:

P i,j ′=( M 0 *P i−1j +M 1 *P i+1j +M 2 *P ij−1 +M 3 *P i,j+1 +(128−( M 0 +M 1 +M 2 +M 3 )* P i,j )/128

The deblocker uses simple linear calculations and one dimensional filters to remove deblocking artifacts and to gather information used by the deringer filter to determine how many iterations to apply its filter. The deringing filter encompasses a pixel to pixel spatially adaptive filter that can both blur and sharpen. It does so by collecting the difference between neighboring pixels into a two dimensional array, applying a simple function to this array and then using the result as a convolution kernel. Since the function can produce both positive and negative tapes, the filter can perform both deringing and sharpening.

The Weak de-ringing filter works exactly the same as above except that the High and Low Modifiers are smaller magnitude numbers and the DeringModifier Function works as follows:

Value=Constant+QuantizationLevel−2*Abs(X−Y) IF (Value<LowModifier)

Value=LowModifier

IF (Value>HighModifier)

Value=HighModifier

FIG. 1 describes the simplified process by which the 2d orthogonal transform works. The basic process is as follows: First initialize all of the coefficients for every block in a group of blocks to 0. Then determine the position of the best place in memory to place the first coefficient given the vector processor. Next extract the first coefficient for each block in a group of blocks, and write any non 0 coefficient to the appropriate location. Then determine the position of the best place in memory to place the second coefficient given the vector processor. Next extract the second coefficient for each block in a group of blocks, and write any non 0 coefficient to the appropriate location. Repeat this same process for each of the subsequent coefficients.

›DESCRIPTION OF THE PREFERRED EMBODIMENT · 2 of 2

Enclosed with this application is a CD-Rom with the preferred embodiment illustrated by providing a listing in Source Code of the method, system and steps of this invention. Following a reading of said CD-Rom, the invention herein is again summarized.

The novelty of this approach in comparison to others found in prior art includes:

1: The selection of different kernel modifiers based upon the difference between the target pixel and its neighbors which is an extremely simple and solely integer based linear calculation that may be efficiently implemented on a vector processor. 2: The ability of the filter to both sharpen real image edges and blur away ringing artifacts and mosquito noise. 3: The usages of completely different de-ringing functions based upon sum absolute difference value information gathered by the de-blocker. 4: The ability to run the de-ringing functions iteratively based on the BlockSad value for the block.

In summary, the following table identifies some of the advantages, features and benefits of this invention.

Having described this invention with regard to specific embodiments, it is to be understood that the description is not meant as a limitation since further modifications and variations may be apparent or may suggest themselves to those skilled in the art. It is intended that the present application cover all such modifications and variations as fall within the scope of the appended claims.

›Tables in the description — 2
Format:IBM Compatible
OS:Windows
Directory of CD
08/06/0201:53 p12,710blockmap.c
08/06/0201:53 p8,616blockmapping.c
08/06/0201:53 p1,884blockmapping.h
08/06/0201:53 p5,590borders.c
08/06/0201:53 p4,796cbitman.c
08/06/0201:53 p1,660cbitman.h
08/06/0201:53 p6,203cframew.c
08/06/0201:53 p1,510cframew.h
08/06/0201:53 p10,181cfrarray.c
08/06/0201:53 p1,376cfrarray.h
08/06/0201:53 p4,066codec_common.h
08/06/0201:53 p17,991compdll.h
08/06/0201:53 p18,253comp_globals.c
08/06/0201:53 p63,483coptfunctions.c
08/06/0201:53 p8,194coptfunctionsppc.c
08/06/0201:53 p91,862cscanyuv.c
08/06/0201:53 p3,351csystemdependant.c
08/06/0201:53 p31,760cwmtfunctions.c
08/06/0201:53 p2,677dct.h
08/06/0201:53 p36,952dct_decode.c
08/06/0201:53 p24,698ddecode.c
08/06/0201:53 p51,397deblock.c
08/06/0201:53 p67,131deblock_av.c
08/06/0201:53 p235,667deblockopt.c
08/06/0201:53 p97,589deblockwmtopt.c
08/06/0201:53 p34,241decodeandrecon.c
08/06/0201:53 p34,050dering.c
08/06/0201:53 p13,128dering_av.c
08/06/0201:53 p74,338deringopt.c
08/06/0201:53 p26,202deringwmtopt.c
08/06/0201:53 p15,347dframer.c
08/06/0201:53 p6,061doptsystemdependant.c
08/06/0201:53 p5,014dsystemdependant.c
08/06/0201:53 p15,146encode.c
08/06/0201:53 p13,282fdct.c
08/06/0201:53 p20,029fdct_av.c
08/06/0201:53 p28,841FilterOptMapca.c
08/06/0201:53 p7,873framecopy.c
08/06/0201:53 p22,745frameini.c
08/06/0201:53 p32,626frarray.c
08/06/0201:53 p953getinfo.c
08/06/0201:53 p11,819huffman.c
08/06/0201:53 p3,890huffman.h
08/06/0201:53 p52,378hufftables.h
08/06/0201:53 p36,321IDctMapCA.c
08/06/0201:53 p27,678idctpart.c
08/06/0201:53 p28,483idctpartppc.c
08/06/0201:53 p24,485idct_av.c
08/06/0201:53 p33,873loopfilter.c
08/06/0201:53 p18,704loopf_asm.c
08/06/0201:53 p21,372loopf_ppc.c
08/06/0201:53 p50,048mcomp.c
08/06/0201:53 p3,721mcomp.h
08/06/0201:53 p13,520misc_common.c
08/06/0201:53 p1,729misc_common.h
08/06/0201:53 p64,242mmxidct.c
08/06/0201:53 p36,143mmxrecon.c
08/06/0201:53 p19,616mventropy.c
08/06/0201:53 p3,055mventropy.h
08/06/0201:53 p30,648newloopfppc.c
08/06/0201:53 p48,799newlooptest_asm.c
08/06/0201:53 p43,844optfunctionsppc.c
08/06/0201:53 p16,328packvideo.c
08/06/0201:53 p16,487pbdll.h
08/06/0201:53 p27,588pbdll_if.c
08/06/0201:53 p10,769pb_globals.c
08/06/0201:53 p8,881pchost_mapca.h
08/06/0201:53 p32,370pickmodes.c
08/06/0201:53 p6,171postp.h
08/06/0201:53 p20,340postproc.c
08/06/0201:53 p3,515postproc_if.h
08/06/0201:53 p12,504predictmotion.c
08/06/0201:53 p1,253preproc.h
08/06/0201:53 p3,170preprocfunctions.c
08/06/0201:53 p502preprocconf.h
08/06/0201:53 p14,083preprocglobals.c
08/06/0201:53 p2,087preprocif.h
08/06/0201:53 p9,264preprocif.c
08/06/0201:53 p49,951quantize.c
08/06/0201:53 p3,835quantize.h
08/06/0201:53 p4,743quantindexmmx.c
08/06/0201:53 p4,489quantindexppc.c
08/06/0201:53 p10,807readtokensopt.c
08/06/0201:53 p15,450reconstruct.c
08/06/0201:53 p2,549reconstruct.h
08/06/0201:53 p1,703resource.h
08/06/0201:53 p23,818rowdiffscan.c
08/06/0201:53 p46,513scale.c
08/06/0201:53 p21,804scale_av.c
08/06/0201:53 p23,240simpledeblock_asm.c
08/06/0201:53 p12,240simpledeblocker.c
08/06/0201:53 p15,483simpledeblockppc.c
08/06/0201:53 p769StdAfx.h
08/06/0201:53 p1,661systemdependant.h
08/06/0201:53 p4,235timer.c
08/06/0201:53 p19,815tokenize.c
08/06/0201:53 p16,560transform.c
08/06/0201:53 p17,641unpack.c
08/06/0201:53 p18,895unpackvideo.c
08/06/0201:53 p30,389unpackvideoppc.c
08/06/0201:53 p4,738uoptsystemdependant.c
08/06/0201:53 p46,884vfwcomp.c
08/06/0201:53 p29,958vfwcomp_if.c
08/06/0201:53 p11,797vp31dtest.c
08/06/0201:53 p9,675vp31dxv.c
08/06/0201:53 p14,900vp31etest.c
08/06/0201:53 p2,334vp3d.h
08/06/0201:53 p134vp3eprefix.h
08/06/0201:53 p10,840vputil.c
08/06/0201:53 p13,669vputilasm.c
08/06/0201:53 p1,698vputil_if.h
08/06/0201:53 p64,250wmtidct.c
08/06/0201:53 p8,248wmtrecon.c
08/06/0201:53 p861xprintf.h
116 File(s)2,485,729bytes
0bytes free
FeatureDescription
Shar-A spatially adaptive kernel filter in which the kernel modifiers
pen/De-are determined by applying a non-continuous function on the
ringingpixel's neighborhood. The filter is capable of both sharpening
Filterand blurring depending on the neighborhood. Different functions
and number of iterations are used based upon the local variance
measures determined by the deblocking filter and the
quantization level used in building the block.
Simpli-An extremely simple 1 dimensional kernel filter is applied across
fied De-block boundaries that differs based upon the variance across the
blockerblock boundary and within the block border. The total amount
adjusted is determined by the quantization level.
MVThe selection process of a new motion vector is ties to the cost
costof transmitting that specific mv (a higher value costs more).
In addition the choice to use a mv is tied to the specific
quantization level of the frame. Error metrics that measured error
by performing a fdct and estimating the number of bits to
achieve perceptual losslessness (defined via several papers) is
employed. This measure was used to keep all of the costs in bits
and could thus properly weight the cost of a new mv against
the benefits.
IterativeAn iterative process is used for motion vector selection that in
MVthe first pass would mark all of the blocks as having a similar
adjust-enough mv to use the first mv encountered in the neighborhood
mentand in the second pass would pick a best mv for that
neighborhood.
DatarateA datarate control stepping mechanism is used that does not
controlallow any frame's quantization level to go above a certain
using alevel until an internal model of the player's buffer is
modelbeyond a certain point, at which point a new maximum level of
of thequantization is chosen. This same model of the player's buffer
playersis used to determine whether or not to drop frames (now with a
bufferdampened threshold on the buffer overrun). We also use the
model to decide when to undershoot the datarate to improve
buffer fullness. The model is used to decide when to
perform internal spatial resampling.
DatarateSelection of the quantizer is now performed after all of the
Controlmodes are chosen. A function based on an error metric for the
Usingframe which equals the sum of the errors for each selected block
Errorand the total number of blocks to be coded is used to
pick a quantizer.
AutoThe keyframing choice algorithm was made to take into account
Keytwo different factors: the percentage of the background that
Framingstays exactly the same, and the percentage improvement
in error score we get by using last frame predictors.
DCTNovel Optimization Technique. Since the typical block has very
Coef-few non zero coefficients, these coefficients are placed in trans-
ficientposed position as we read them off the bitstream rather than
Arrang-doing the transpose as part of the idct. The position these
ementare placed differs based upon the specific processor.
Quanti-Baseline set of values for mid range quality not best quality. For
zationhigher Q the table value = Q multilier * baseline value.
StrategyFor lower Q the table value is interpolated between the
baseline value and the minimum allowed value.
Round-Basically instead of rounding in a conventional way, e.g., 0.5–
ing and1.5 = >1 the rounding behavior is changed to reflect the
ZeroBindistribution of samples. Because there are a lot more samples in
Strategythe range 0.5–1.0 than in the range 1.0–1.5, the mean value for
the range 0.5–1.5 the is less than 1. To counter this the rounding
behavior is changed. For example, one might say that 0.65–
1.65 = >1.0. The aim here is to insure that the output value
after inverse quantization is close to the mean of the samples that
have ended up in that bin (and hence to minimize the mean
square error). Where this gets complicated is around zero.
Effectively the zero-bin size is increased somewhat. This is a
mixed blessing. Increasing the zero-bin size too much can cause
loss of sharpness (as observed in VP3.2) but it also has a
profound effect on the output bit rate for a given Q setting.
Thus at a fixed “bit rate” increasing the zero-bin
size results in a lower average Q and hence more accurate
coding of non-zero values.
In VP4 these trade offs of rounding factor and zero bin size are
adjusted according to the current Q value. At low Q (high
quality) a smaller zero bin size and more conventional rounding
is preferred, to insure sharpness. At higher Q, there is a shift
towards truncation and a larger zero-bin size. For example one
gets better results with a Q multiplier of 3.0 and a zero-bin
size of +/−0.9 than with a Q multiplier of 5.0 and a
zero bin size of +/−0.65.
MotionRather than applying a typical reconstruction loop filter a de-
Predic-blocking filter is applied only to the motion predictor of blocks
tionthat cross a block boundary. This gets around the problem with
Blockaccumulating dct errors and improves the prediction
De-of the block.
block-
ing
TokenAll coefficients for a block are transmitted in order, but the
Ordertokens used also account for some information about blocks that
Trans-have yet to be transmitted.
mittal
Updates
ContextFor modes, MVs and display fragments different token set
Basedprobabilities are chosen based upon the information transmitted
Entropynearby.
For modes and MVs a 2 dimensional context model with
additional variables (like frame type) that blends these 3 items
together into a set of probability distributions is used.
For DC and AC coefficients the token probability sets are
determined by a function of what the coefficient is, what plane
(Y, U, or V) it came from and a predetermined frame type.
A more complex model of the context and probabilities that
makes use of the neighboring blocks frame type and position
within the block is used to select between probability sets.
Improv-The same block in subsequent frames is now guaranteed to keep
ed re-getting a chance for update until no further coefficients are
coverygenerated for that block, irregardless of whether it is marked
blockas background material. This helps avoid staleness issues.
strategy
DatarateAs a final trap for huge datarate miscalculations the code is now
Miscal-capable of restarting the compression of a frame if there were
cula-a large error. This same technique is used to redo a
tionssection in the standalone lagged compressor.
PostThe manner in which we use a calculation based on bits per mhz
Process-is used to determine between postprocessing mechanisms is new.
ing
Choices

Claims as granted

14 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

4 codes
IPC · International Patent Classification
Section G — Physics
  • G06K9/40
USPC · US Patent Classification
382/236382/266382/260

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJul 2002Jan 2003Jul 2003Jan 2004Jul 2004Jan 2005Jul 2005Jan 2006Jul 2006USPTOApplicantNon-final rejectionResponse after non-finalFinal rejectionResponse after final
USPTOApplicanthover for detail · click to open
Pendency
3.7 y
1,335 days filing → grant
Office actions
2
non-final + final
Responses
3
no RCE
Interviews
1
examiner interview summaries
Examiner
Tommy D. Lee
art unit 2624 · TC 2600
Citations: 6 back · 77 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20022004200620082010201220142016201820202022Owner 1Owner 4Owner 5
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock