KR20130140190A - Methods and devices for coding and decoding the position of the last significant coefficient - Google Patents

Abstract

A method and apparatus are described for entropy coding data using an entropy coder to encode quantized transform domain coefficient data. The last significant coefficient information is signaled in the bitstream using two-dimensional coordinates for the last significant coefficient. The context for the bins of one of the coordinates is based in part on the value of the coordinate of the other of the coordinates. In one case, instead of signaling the last significant coefficient information, the number of nonzero coefficients is binarized and entropy encoded.

Description

Method and apparatus for coding and decoding the position of the last significant coefficient {METHODS AND DEVICES FOR CODING AND DECODING THE POSITION OF THE LAST SIGNIFICANT COEFFICIENT}

TECHNICAL FIELD This application generally relates to data compression, and more particularly, to encoders, decoders, and methods for coding and decoding last significant transform coefficients.

Data compression often uses entropy coding to encode decorrelated signals as bit sequences (ie, bitstreams), either lossy or lossless compression. Efficient data compression has a wide variety of applications, such as video, audio and video encoding. Conventional video encoding technology is the ITU-T H.264 / MPEG AVC video coding standard. This standard defines a number of different profiles for different applications, including the Main profile, Baseline profile and others. The next generation of video encoding standards is currently under development through the joint initiative of MPEG-ITU: High Efficiency Video Coding (HEVC).

There are a number of standards (including H.264) for encoding / decoding video and video, which use a lossy compression process to generate binary data. For example, H.264 includes a prediction operation to obtain residual data, followed by a DCT transform and quantization of DCT coefficients. The resulting data, including quantized coefficients, motion vectors, coding modes, and other related data, is then entropy coded to generate a data bitstream for transmission or storage on a computer readable medium. HEVC is also expected to have these features.

A number of coding schemes have been developed for encoding binary data. For example, JPEG images may be encoded using Huffman code. The H.264 standard enables two possible entropy coding processes: Context Adaptive Variable Length Coding (CAVLC) or Context Adaptive Binary Arithmetic Coding (CABAC). . CABAC brings more compression than CAVLC, but CABAC requires more computation. In any of these cases, the coding scheme processes the binary data to produce a serial bitstream of encoded data. At the decoder, the decoding scheme retrieves the bitstream and entropy decodes the serial bitstream to reconstruct binary data.

It would be beneficial to provide an improved encoder, decoder, and entropy coding and decoding method.

Reference will now be made to the accompanying drawings, which show, by way of example, exemplary embodiments of the present application.
1 is a block diagram of an encoder for encoding video.
2 is a block diagram of a decoder for decoding video.
3 is a block diagram of an encoding process.
4 is a simplified block diagram of an exemplary embodiment of an encoder.
5 is a simplified block diagram of an exemplary embodiment of a decoder.
6 illustrates a zigzag coding order for a 4x4 coefficient block.
7 schematically illustrates a portion of a bitstream.
FIG. 8 illustrates in flowchart form an exemplary method of entropy encoding last significant coefficient information. FIG.
FIG. 9 illustrates in flowchart form an exemplary method of entropy decoding a bitstream of encoded data to reconstruct quantized transform region coefficient data.
FIG. 10 illustrates in flowchart form an exemplary method of encoding a significance map. FIG.
FIG. 11 shows anti-diagonal grouping of coefficients in a 4 × 4 block. FIG.
Like reference numerals may be used in different drawings to indicate like elements.

The present application describes an apparatus, method and process for encoding and decoding binary data. Specifically, the present application describes a method and apparatus for coding and decoding the last significant coefficient position in a block-based coding scheme.

In one aspect, the present application describes a method for encoding quantized transform region coefficient data including last significant coefficient information. The method comprises binarizing each of the two positions of the two-dimensional coordinates of the last significant coefficient; Determining a context for each bin of one of the locations; Determining a context for each bin of the other of the locations, wherein the context of each bin of the other of the locations is based in part on the one of the locations; And entropy encoding the binarized positions based on the context determined for each bin of the binarized positions to produce encoded data.

In another aspect, the present application describes a method of decoding a bitstream of encoded data to reconstruct quantized transform region coefficient data. The method entropy decodes a portion of encoded data to generate two binary positions that define two-dimensional coordinates of the last significant coefficient, wherein entropy decode a portion of data is a position of one of the positions. Determining a context for each bin of, and determining a context for each bin of a location of the other one of the locations, wherein the context of each bin of the location of the other one of the locations is a location Based in part on the location of one of these; Entropy decoding a significant coefficient sequence based on the two-dimensional coordinates of the last significant coefficient; Entropy decoding level information based on the effective coefficient sequence; And reconstructing the quantized transform region coefficient data using the level information and the effective coefficient sequence.

In another aspect, the present application describes a computer readable medium storing computer executable program instructions that, when executed, are configured to cause a processor to perform the described encoding and / or decoding methods.

Those skilled in the art will appreciate other aspects and features of the present application by reviewing the following description of examples in conjunction with the accompanying drawings.

The following description relates generally to data compression, and in particular, to efficient encoding and decoding of finite alphabet sources, such as binary sources. In many of the examples given below, certain applications of this encoding and decoding scheme are given. For example, many of the examples below refer to video coding. It will be appreciated that the present application is not necessarily limited to video coding or image coding. This may be applicable to any type of data that is block based and subject to context based data encoding schemes including signaling the location of the last valid bit or symbol in the block.

Exemplary embodiments described herein relate to data compression of finite alphabetic sources. Accordingly, this description often refers to "symbols", which are elements of the alphabet. In some cases, the description herein refers to binary sources and symbols are referred to as bits. At times, the terms "symbol" and "bit" may be used interchangeably for a given example. It will be appreciated that a binary source is only one example of a finite alphabet source. This application is not limited to binary sources.

In the following description, exemplary embodiments are described with reference to the H.264 standard. Those skilled in the art will appreciate that this application is not limited to H.264 and may be applicable to other video coding / decoding standards, including possible future standards such as HEVC. It will also be appreciated that the present application is not necessarily limited to video coding / decoding and may be applicable to coding / decoding of any finite alphabet source.

Reference is now made to FIG. 1, which shows, in block diagram form, an encoder 10 that encodes video. Reference is also made to FIG. 2, which shows a block diagram of a decoder 50 for decoding video. It will be appreciated that each of the encoder 10 and decoder 50 described herein can be implemented on an application-specific or general purpose computing device that includes one or more processing elements and memory. will be. The operations performed by the encoder 10 or decoder 50 may optionally be implemented, for example, through an application-specific integrated circuit (ASIC) or through stored program instructions executable by a general purpose processor. have. The device may include additional software, including, for example, an operating system that controls basic device functions. Those skilled in the art will appreciate the range of devices and platforms on which encoder 10 or decoder 50 may be implemented when reviewed in the following description.

Encoder 10 receives video source 12 and generates an encoded bitstream 14. Decoder 50 receives encoded bitstream 14 and outputs decoded video frame 16. Encoder 10 and decoder 50 may be configured to operate in accordance with a number of video compression standards. For example, encoder 10 and decoder 50 may be H.264 / AVC compatible. In other embodiments, encoder 10 and decoder 50 may conform to other video compression standards, including advances in the H.264 / AVC standard, such as HEVC.

The encoder 10 includes a spatial predictor 21, a coding mode selector 20, a transform processor 22, a quantizer 24, and an entropy coder 26. As will be appreciated by those skilled in the art, the coding mode selector 20 may determine a suitable coding mode for the video source, e.g., whether the target frame / slice is of type I, P or B, and which particular within the frame / slice. Determines whether a macroblock (or coding unit) of is inter- or intra-coded. The transform processor 22 performs a transform on the spatial domain data. Specifically, transform processor 22 applies block-based transforms to transform spatial domain data into spectral components. For example, in many embodiments a discrete cosine transform (DCT) is used. In some cases, other transforms may be used, such as a discrete sine transform or the like. Applying the block-based transform to the block of pixel data results in a set of transform region coefficients. This set of transform domain coefficients is quantized by quantizer 24. The quantized coefficients and associated information (motion vector, quantization parameter, etc.) are then encoded by entropy coder 26.

Intra-coded frames / slices (ie, type I) are encoded with reference to other frames / slices. In other words, they do not use time prediction. However, intra-coded frames rely on spatial prediction within a frame / slice by the spatial predictor 21, as illustrated in FIG. 1. That is, when encoding a particular block, the data in the block can be compared with the data of the pixels in the vicinity of the blocks already encoded for that frame / slice. Using the prediction algorithm, the source data of the block can be converted to residual data. Transform processor 22 then encodes the residual data. H.264, for example, defines nine spatial prediction modes for a 4x4 transform block. In some embodiments, each of the nine modes may be used to process the block independently, and then rate-distortion optimization is used to select the best mode.

The H.264 standard also specifies the use of motion prediction / compensation to take advantage of temporal prediction. Accordingly, encoder 10 has a feedback loop that includes inverse quantizer 28, inverse transform processor 30, and inverse block processor 32. These elements reflect the decoding process implemented by the decoder 50 to play the frames / slices. Frame storage 34 is used to store the reproduced frames. In this way, motion prediction is based on being reconstructed at decoder 50, not the original frame, which may be different from the reconstructed frame due to the lossy compression involved in encoding / decoding. The motion predictor 36 uses the frame / slice stored in the frame store 34 as a source frame / slice for comparing with the current frame to identify similar blocks. Thus, for macroblocks to which motion prediction is applied, the "source data" encoded by transform processor 22 is the residual data coming from the motion prediction process. Residual data is pixel data indicating the difference (if any) between the reference block and the current block. Information about the reference frame and / or motion vector may not be processed by transform processor 22 and / or quantizer 24, instead entropy for encoding as part of the bitstream with quantized coefficients. May be provided to the coder 26.

Those skilled in the art will be familiar with the details and possible variations for implementing the H.264 encoder.

Decoder 50 includes entropy decoder 52, inverse quantization 54, inverse transform processor 56, spatial compensator 57, and inverse block processor 60. Frame buffer 58 provides reconstructed frames for use in applying motion compensation in motion compensator 62. Spatial compensator 57 represents the operation of reconstructing video data for a particular intra-coded block from a previously decoded block.

To recover the quantized coefficients, the bitstream 14 is received and decoded by the entropy decoder 52. During the entropy decoding process, side information may also be recovered, some of which may be provided to the motion compensation loop for use in motion compensation, if applicable. For example, entropy decoder 52 may reconstruct the motion vector and / or reference frame information for the inter-coded macroblock.

The quantized coefficients are then inverse quantized by inverse quantizer 54 to produce transform region coefficients, and the transform region coefficients are then inverse transformed by inverse transform processor 56 to regenerate "video data". In some cases, such as in an intra-coded macroblock, it will be appreciated that the regenerated "video data" is residual data for use in spatial compensation for previously decoded blocks in a frame. Spatial compensator 57 generates video data from pixel data and residual data from previously decoded blocks. In other cases, such as inter-coded macroblocks, the regenerated "video data" from inverse transform processor 56 is residual data for use in motion compensation for reference blocks from different frames. Both spatial compensation and motion compensation may be referred to herein as "predictive motion".

The motion compensator 62 finds in the frame buffer 58 a reference block designated for a particular inter-coded macroblock. The motion compensator 62 is based on and does so with reference frame information and motion vectors specified for the inter-coded macroblocks. Motion compensator 62 then provides reference block pixel data for combining with the residual data to arrive at the regenerated video data for that macroblock.

As shown by deblocking processor 60, a deblocking process may then be applied to the reconstructed frame / slice. After deblocking, the frames / slices are output, for example, as decoded video frames 16 for display on a display device. It will be appreciated that a computer, set top box, video playback machine such as a DVD or Blu-ray player, and / or mobile handheld device may buffer decoded frames in memory for display on an output device.

Entropy coding is a fundamental part of all lossless and lossy compression schemes, including the video compression described above. The purpose of entropy coding is probably to represent the decorrelated signal (which is often modeled by a process that is independent but does not have the same distribution) as a bit sequence. The technique used to achieve this should not depend on how the decorrelated signal was generated, but could rely on the associated probability estimates for each symbol that would come out.

There are two common approaches to entropy coding that are actually used: the first is variable length coding that identifies an input symbol or input sequence by codeword, and the second is [0, 1) Range (or arithmetic) coding that encapsulates a sequence of subintervals of an interval, from which the original sequence can be reconstructed using probability distributions that define the intervals. Typically, range coding methods tend to provide better compression, while VLC methods have the potential to be faster. In either case, the symbols of the input sequence are from finite alphabet.

A special case of entropy coding is when the input alphabet is limited to binary symbols. Here, the VLC scheme must group the input symbols with the possibility of compression, but the efficient code construction is difficult because the probability distribution can change after each bit. As such, range encoding is thought to have greater compression because of its greater flexibility, but the actual application is hindered by the more computational demands of the arithmetic code.

A common problem with both of these encoding schemes is that they are in fact serial. In some important practical applications, such as high quality video decoding, the entropy decoder must reach very high output speeds, which can pose a problem for devices with limited processing power or speed.

One of the techniques used with some entropy coding schemes such as CAVLC and CABAC (both used in H.264 / AVC) is context modeling. In context modeling, each bit of the input sequence has a context, where the context can be given by some subset of other bits, such as bits preceding it, or by supplemental information, or both. In a first-order context model, the context may depend entirely on the previous bit (symbol). In many cases, the context model can be adaptive, so the probability associated with symbols for a given context can change as additional bits of the sequence are processed. In another case, the context of a given bit may depend on its position in the sequence (eg, the position or order of the coefficients in the matrix or block of coefficients).

Reference is made to FIG. 3, which shows a block diagram of an example encoding process 100. The encoding process 100 includes a context modeling component 104 and an entropy coder 106. The context modeling component 104 receives an input sequence x 102, which in this example is a bit sequence b ₀ , b ₁ ,..., B _n . In this illustrative example, the context modeling component 104 determines the context for each bit b _i , presumably based on one or more previous bits in the sequence or based on auxiliary information, and based on this context, Determine the probability p _i associated with that bit b _i , where this probability is the probability that the bit is a Least Probable Symbol (LPS). Depending on the protocol or application, the LPS may, in binary embodiments, be "0" or "1". Determining the probability may itself depend on previous bits / symbols for that same context.

The context modeling component outputs an input sequence, i.e. bits (b ₀ , b ₁ , ..., b _n ) with its respective probabilities (p ₀ , p ₁ , ..., p _n ). These probabilities are the estimated probabilities determined by the context model. This data is then input to an entropy coder 106 that encodes the input sequence using probability information. For example, entropy coder 106 may be a binary arithmetic coder. Entropy coder 106 outputs a bitstream 108 of encoded data.

Each bit of the input sequence is processed serially to update the context model, serial bits and probability information are provided to the entropy coder 106, and the entropy coder 106 then serializes the bits. It will be appreciated that the bitstream 108 is generated by entropy coding. As those skilled in the art will appreciate, in some embodiments, explicit probability information may not be passed from the context modeling component 104 to the entropy coder 106; Rather, in some cases, for each bit, the context modeling component 104 reflects the probability estimates made by the context modeling component 104 based on the context model and the current context of the input sequence 102. It will be appreciated that an index or other indicator may be sent to entropy coder 106. An index or other indicator represents a probability estimate associated with its corresponding bit.

In some embodiments, entropy coder 106 may have a parallel processing structure that encodes input sequence 102. In such embodiments, entropy coder 106 may include a plurality of entropy coders, each of which processes a portion of input sequence 102. In some cases, the input sequence may be demultiplexed and allocated between parallel entropy coders based on estimated probabilities associated with the respective bits. In other words, the bits from the input sequence 102 are assigned to one of the parallel entropy coders based on their estimated probability.

At the decoder, the encoded bitstream is decoded using the opposite process. In detail, the decoder performs the same context modeling and probability estimation process to determine the context of the next reconstructed symbol of the reconstructed sequence. Based on the context determined for the next reconstructed symbol, an estimated probability is determined. To obtain decoded symbols, an encoded bitstream, which may consist of codewords output by the entropy coder (s), is decoded. In order to obtain decoded symbols corresponding to the estimated probabilities, determining the context / probability is interleaved with decoding the codewords.

In a parallel encoding embodiment, the decoder may be configured to demultiplex the encoded bitstream into a plurality of decoded subsequences, each associated with an estimated probability. As a result of the context modeling and probability estimation, the reconstructed symbols are then selected from the associated decoding subsequences. It will be appreciated that in such implementations, decoding of the encoded bitstream may be considered to be de-interleave from context modeling and probability estimation.

From the following detailed description, it will be appreciated that the present application is applicable to serial or parallel entropy coding and decoding.

The present application proposes an encoding and decoding process in which the last significant coefficient position is encoded and the context of one of the axes of the position depends on the other axis.

The following examples specifically describe video encoding, in particular the encoding of the sequences sig [i, j] and last [i, j] defined in CABAC as defined in the ITU-T H.264 / AVC standard. May be mentioned. It will be appreciated that the present application is not limited to the encoding and decoding of these two specific sequences within CABAC, nor to the video encoding and decoding or the H.264 / AVC standard. The present application describes encoding and decoding methods and processes that can be applied to video, video, and, in some cases, other data sequences, including audio. The method and process herein is applicable to an encoding and decoding process involving encoding a last significant coefficient position and involving a context model where the position can be modeled as two-dimensional or two-dimensional. The examples below may refer to binary sources as examples, but the present application is more generally applicable to any finite alphabet source.

As described above, the exemplary video and image encoding and decoding process utilizes block-based transformation to transform residual data from the pixel domain to a transform domain. Exemplary block based transformations are 4x4 DCT or 8x8 DCT. In some applications, other sizes or types of transforms (such as DST or DFT) may be used. A matrix or set of transform data is then quantized by a quantizer to produce a matrix or set of quantized transform region coefficients. The present application is directed to a matrix of quantized transform region coefficients, a matrix, a set, meaning an ordered set of data in which the position of any of the coefficients can be specified by two-dimensional coordinates [x, y], Or block.

Entropy encoding of a block of quantized transform region coefficients is based on a context model. For example, in H.264 / AVC, a block is entropy encoded by first encoding the significance map. The significance map contains two sequences last [i, j] and sig [i, j]. The sequence sig [i, j] is a binary sequence indicating whether each position in the DCT block has a nonzero coefficient. The other sequence last [i, j] maps to nonzero coefficients in the DCT block and the nonzero coefficients correspond to the last zero of the DCT block (in the zigzag scan order used in H.264 and other transform domain image or video encoding schemes). Binary sequence that indicates whether or not a coefficient. Note that the index [i, j] is not a two-dimensional coordinate position in the block; Index i is the index for the block and index j is the index for the one-dimensional count position in the zigzag scan order described below.

The H.264 standard specifies the zigzag scan order for encoding the coefficients of a DCT block. For example, referring to a 4x4 DCT block, the H.264 standard encodes 16 coefficients in the zigzag order illustrated in FIG. As shown in FIG. 6, the scan order starts at the upper left corner of the block and follows the zigzag pattern to the lower right corner. If arranged in this coding order, the resulting sequence of coefficients for the ith block is X (i, 0), ..., X (i, 15).

The H.264 / AVC standard uses a way in which blocks are encoded sequentially. In other words, each sequence X (i, 0), ..., X (i, 15) is encoded in turn. The context model used in H.264 / AVC includes determining two binary sequences sig [i, j] and last [i, j] for each vector X [i, j]. Subsequently, the actual value of the coefficients (called the level) is also encoded.

To illustrate by way of example, consider the following example coefficient sequence X:

3, 5, 2, 0, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 i = 0

6, 4, 0, 3, 3, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 i = 1

4, 2, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 i = 2

The sequences sig [i, j] and last [i, j] for these coefficient sequences are as follows:

sig [0, j] = 1, 1, 1,0, 1, 1, 0, 1

last [0, j] = 0, 0, 0, 0, 0, 1

sig [1, j] = 1, 1, 0, 1, 1, 0, 1

last [1, j] = 0, 0, 0, 0, 1

sig [2, j] = 1, 1, 0, 0, 1

last [2, j] = 0, 0, 1

It will be appreciated that last [i, j] only contains values when sig [i, j] is nonzero, and that both sequences end after the last non-zero coefficient. As such, last [i, j] will not necessarily include the bits for every bit j in sig [i, j]. It will be appreciated that the length of these sequences may vary with coefficient values. Finally, if we know that the sig [i, j] sequence contains nonzero bits, whether there are any bits corresponding to the last [i, j] sequence-meaning that the encoding and decoding of these sequences are interleaved per bit position You will know well.

In the H.264 / AVC example, the probability (sometimes called "state") for a bit is determined based on its context. Specifically, determine the probability that a bit history for that same context is selected or assigned to that bit. For example, for a bit at the j th position in a given sequence, its probability is 64 possible probabilities, based on the history of the bits at the j th position in the previous sequences (i-1, etc.). It is selected from these.

As described above, the bits are encoded based on their probability. In some example embodiments, parallel encoding may be used, and in some cases, parallel encoding may include an entropy coder associated with each probability. In another exemplary embodiment, serial entropy encoding may be used. In either case, the entropy coder encodes the symbols based on their associated probabilities.

At the decoder, the same context modeling and probability estimation is done to reconstruct the sequence. Probability estimation is used to decode the encoded bitstream to obtain a reconstructed symbol. The symbols are selected from the decoded portions of the encoded bitstream and interleaved to form a sequence of reconstructed symbols based on the associated probabilities and context model of the symbols.

The syntax for residual blocks in H.264 / AVC using CABAC is described in the table below:

The table provides pseudo code for entropy decoding a bitstream comprising sig [i, j], last [i, j] and level information. The descriptor “ae (v)” refers to entropy decoding the bits from the bitstream to obtain the values indicated in that row in the table.

Note that in this syntax the bits of sig [i, j] and last [i, j] are interleaved. For example, the "if (coded_block_flag)" loop decodes bits from the sig [i, j] sequence (called significant_coeff_flag [i]), followed by last [i if non significant_coeff_flag [i] is nonzero. , j] decoding the bits from the sequence (called last_significant_coeff_flag [i]).

It will also be appreciated that this syntax depends on the sequence to signal the one-dimensional position of the last significant coefficient in the zigzag scan order for the block.

According to one aspect of the present application, this syntax is modified to signal the two-dimensional coordinates of the last significant coefficient in the block. For example, in a 4x4 block, the position of the last significant coefficient has x- and y-coordinates, where x and y are in the range between 0 and 3. This pair of coordinates can be passed in this syntax instead of the last [i, j] sequence.

The problem that arises is how to efficiently and effectively code the two-dimensional coordinates of the last significant coefficient. A further problem is whether modifications to the context model must be made for the encoding of this parameter.

According to one aspect of the present application, two-dimensional coordinates are encoded in sequence, in which case the value of the first coordinate is used in part to determine the context for encoding the second coordinate. This concept is based on some correlation between the values of the two coordinates in the pair, as observed empirically. The value of the x-coordinate tends to have a significant effect on the probability of the value for the corresponding y-coordinate. This relationship can be used to improve the efficiency of the encoding.

In one embodiment according to one aspect of the present application, a fixed length code is used to binarize the x- and y-coordinate values. In other embodiments, other binarization schemes may be used.

According to another aspect of the present application, the syntax for encoding the residual block is further modified to include a flag to signal that the last significant coefficient is the DC coefficient at [0,0]. This is common in practical implementations, and when this situation is signaled in the bitstream, the bitstream may not include the x- and y-coordinate values for the last significant coefficient in that situation, thereby compressing efficiency To improve.

In the description herein, the term "position" may sometimes be used to refer to x- or y-coordinates, as the case may be.

Although the exemplary embodiment described below specifies that the context for encoding bits of the y-position depends in part on the value of the x-position, the order is arbitrary. In another embodiment, the context for encoding the x-position may depend in part on the value of the y-position.

One exemplary embodiment of the syntax for encoding residual blocks, which is one aspect of the present application, is described in the following table:

From the pseudo code, note that the decoder initializes the values for the x-position (last_pos_x = 0) and the y-position (last_pos_y = 0), and then the flag last_0_flag to signal that the last significant coefficient is the DC coefficient. Is to read. This loop is performed immediately after only if last_0_flag does not indicate that the last significant coefficient is at [0,0]. In that case, the decoder then reads the values for last_pos_x and last_pos_y from the bitstream.

Also note that in this embodiment, if last_pos_x is 0, since the two-dimensional position in that situation cannot be [0,0] due to the flag setting, the y-position must be at least 1, so y- The position is encoded as decreasing its value by one. Due to this encoding syntax, when last_pos_x is set to 0, the value for last_pos_y is incremented by 1 to restore to its actual value. In this particular situation, reducing last_pos_y by 1 for encoding is for efficiency in entropy encoding.

After the two-dimensional coordinates have been read, the decoder continues reading the significant_coeff_flag [i] sequence from the bitstream. Index [i] sets the current pos x and pos_y values using a zigzag table for mapping the index to the coordinate position. When the pos_x and pos_y values coincide with the last_pos_x and last_pos_y values, respectively, the last_significent_coeff flag is set to stop reading the sig [i, j] sequence read as significant_coeff_flag [i] bit by bit.

Reference is now made to FIG. 7, which schematically illustrates the structure of a bitstream 200 generated in accordance with an aspect of the present application. A portion of the bitstream 200 illustrated in FIG. 7 represents data related to the residual block. A portion of the bitstream 200 is, as shown, a bitstream before entropy encoding or after entropy decoding. Entropy encoding may include CABAC, CAVLC, or other context based entropy coding schemes.

The leading flag is coded_block_flag. This flag is followed by last_0_flag, which signals the last significant coefficient coordinate of [0,0]. Subsequently, assuming that last_0_flag is not set, the bitstream 200 includes last _pos_x and last _pos_y values. This is followed by a sig [i, j] sequence, that is, a sequence of significant coefficients. Finally, a portion of the bitstream 200 contains level information. It will be appreciated that when last_0_flag is set, the last_pos_x, last_pos_y, and significant coefficient sequences are omitted.

In one embodiment, the last _pos_x and last _pos_y values are binarized using fixed-length binarization. The length of these binary values depends on the size of the transform matrix, i.e. the size of the block of quantized transform region coefficients.

Reference is now made to FIG. 8, which illustrates an example method 300 of encoding last significant coefficient data when encoding a residual block. Exemplary method 300 includes an operation 302 for determining the last significant coefficient coordinate. These coordinates are the x- and y-coordinates in the range from 0 to N-1 for the NxN transform block size. These coordinates can be referred to as x- and y-positions.

In operation 304, two locations are binarized. As discussed above, these locations can be binarized using fixed length binarization. The length of the binarized position may be Log ₂ (N). In other embodiments, other binarization schemes may be used.

Entropy encoding the binarized positions includes determining a context for each bin of the binarized positions. Accordingly, in operation 306, the context for each bin of one of the locations is determined. For the purposes of the example embodiment, the x-position may be considered the first position to be encoded. The context for each bin of the binarized x-position may be based on a number of factors. For example, in one embodiment, the context of each bin of the x-position may be based on the size of the transformation matrix. Previous bins, if any, of the x-position may also affect the context for subsequent bins of that x-position.

In operation 308, the context for each bin of the other of the locations (in this example, the y-position) is then determined. In determining the context for the bins in the y-position, this context depends in part on the value of the x-position. The context for the bins for the y-position may also depend in part on the size of the transformation matrix and the previous bins, if any, at the y-position.

In operation 310, the binarized positions are then entropy encoded according to their associated contexts as determined in step 306 and step 308. Entropy encoding may include CABAC, CAVLC, or any other suitable context based entropy encoding scheme.

Reference will now be made to FIG. 9, which shows a flowchart illustrating a method 400 of decoding a bitstream of encoded data to reconstruct quantized transform region coefficient data. The example method 400 shown in FIG. 9 includes processing a bitstream of encoded data using syntax similar to that described herein. In operation 402, a portion of the bitstream is entropy decoded to recover two binarized positions that define two-dimensional coordinates for the last significant coefficient. This operation includes determining a context for each bin of the first of the locations (eg, the x-position in one embodiment). The context may depend, for example, on the size of the transformation matrix and previously decoded bins, if any, of the x-position. Based on the context for each bin, and thus the estimated probability associated with it, entropy decoding of the bitstream determines the bin and consequently reconstructs the binarized x-position.

Operation 402 further includes determining the context of each bin at another location (in this example, the y-position). The context of each bin of the y-position may depend on the size of the transformation matrix and the previous bins, if any, of the y-position, but also on the value of the x-position. As a result of the entropy decoding of the bitstream according to the determined context for each bin and the estimated probability of the result, the binarized y-coordinate is reconstructed.

In operation 404, x-position and y-position are used to entropy decode the significant coefficient sequence from the bitstream. In operation 406, level information is recovered from the bitstream using entropy decoding. In operation 408 both effective coefficient sequence and level information are used to reconstruct the quantized transform region coefficient data.

In one exemplary implementation, the context for the bins of the x-position (if it is the first to be encoded in two-dimensional coordinates) is given as follows:

ctxIdxInc = binCtxOffset + binCtxInc

In this expression, ctxIdxInc is the context index for the given bean of last _pos_x. The variable binCtxOffset is the context offset based on the transform size. In one embodiment, the offset is determined according to the following table:

In this example, log2TrafoSize is the binary log of the transform matrix size, log ₂ (N).

Another variable in the expression for the context index is binCtxInc indicating the context index increment applied based on the values of the previous bins (if any) at last_pos_x. The binCtxInc variable can be determined according to the following table, for example:

In this example, binIdx is the index of the bin at last pos_x and b ₀ and b ₁ are the bins in the last_pos_x binary sequence at index 0 and index 1, respectively.

In an exemplary embodiment, the context for the beans of last_pos_y may be determined according to the following expression:

ctxIdxInc = binCtxOffsetO + 3 * binCtxOffset1 + binCtxInc

In this case, the context for the bin of last_pos_y depends on the size of the transformation matrix, the previous bins (if any) of last_pos_y, and the last_pos_x value. Specifically, the transformation matrix, in some embodiments, affects the context via the variable binCtxOffset0, which can be determined according to the following table:

Decoded bins of last_pos_y may, in some embodiments, affect the context via the variable binCtxInc, which may be determined according to the following table:

In this example, note that only the first bin at index 0 affects the context for any additional bins of last_pos_y.

Finally, the value of last_pos_x can affect the context for the bean of last_pos_y through the variable binCtxOffset1, which can be determined as follows:

If last_pos_x == 0,

binCtxOffset1 = 0

Otherwise,

binCtxOffset1 = Floor (Log2 (last _pos_x)) + 1

It will be appreciated that the above example is just one exemplary implementation where the context for the beans of last_pos_y depends on the value of last_pos_x. It will be appreciated that various other implementations can be realized with specific tables and context offsets that are empirically designed to suit a particular application.

The meaning of the context index may depend on the value of the quantization parameter QP. That is, different contexts can be used to code the same syntax with different QPs. However, these contexts can share the same context index. In one example embodiment, last_pos_x may be coded with Huffman code. The corresponding Huffman tree may depend on the value of QP. The context for the coding bins of last_pos_x may depend on the Huffman tree, whereby they are different in different QPs. For example, if one context is used for each QP, these contexts may share the same index 0, but may have different meanings.

In an alternative embodiment, instead of encoding the two-dimensional Cartesian coordinates x and y, the last effective coefficient position is represented by the anti-diagonal line with the coefficients and the relative position of the coefficients in that line. do. Reference is made to FIG. 11, which schematically illustrates a 4 × 4 coefficient block 600. Opposite line 602 is shown on block 600. Note that there are seven opposite angles indexed from 0 to 6. Lines 0 and 6 have only a single position corresponding to the x, y coordinates [0,0] and [3,3], respectively. The other opposite angles 602 have two to four positions, respectively. The locations may be indexed according to the convention of scan order. That is, indexing of locations on opposite angles may alternate in direction in each line. Thus, the representation of each coordinate in a 4x4 block can be expressed in opposite diagonal based two-dimensional coordinates [a, b] as follows:

[0,0] [1,0] [2,2] [3,0]

[1,1] [2,1] [3,1] [4,2]

[2,0] [3,2] [4,1] [5,0]

[3,3] [4,0] [5,1] [6,0]

Note that since it is not necessary to specify the second coordinate for the position on the line, the last positions [0,0] and [6,0] can be encoded with only their opposite diagonal numbers.

The [a, b] values can be encoded in a similar manner as described above for the two-dimensional coordinates x and y. The total number of coded bins for opposite diagonal index a is log ₂ (2N-1). The number of coded bins for position b of the coefficient on the line depends on the value a, 1 + log ₂ (a) for a <N and 1 + log ₂ (2 (N-1) − for a≥N). a) The context for encoding / decoding each bin is based on the value of the previous encoded / decoded bins.

In another alternative implementation, rather than encoding the two-dimensional coordinates for the last significant coefficient position, the encoder encodes the one-dimensional coordinates for the last significant position in consideration of the coefficient scan order. The coefficient scan order may be in zigzag order in H.264, or in any adaptive or non-adaptive scan order used in other transform domain image or video encoding schemes. In this implementation, instead of last_pos_x and last_pos_y, the encoder only encodes last_pos in the range from 0 to (N * N-1), where N is the size of the block of transform domain coefficients. If last_0_flag is used in the syntax, the range for last_pos need not include zero. In some cases, last_pos can be automatically reduced, so the decoder knows to add 1 to the last_pos value in order to realize the actual one-dimensional coordinates for the last significant coefficient position.

The last_pos value may be encoded in a similar manner as described above for one of the two-dimensional coordinates. The total number of coded bins for one-dimensional coordinate last_pos is 21og ₂ (N). The context for encoding / decoding each bin is based on the value of the previous encoded / decoded bins.

Note that, in an exemplary implementation, the worst number of coded bins for a two-dimensional (or one-dimensional) last significant coefficient position is N *, which is the worst number of coded bins for a conventional last [i, j] sequence. It is on the order of log ₂ (N) much smaller than N, thereby reducing the complexity in the entropy coding engine implementation.

In another aspect of the present application, it may be beneficial to use the last position encoding process described above for only certain blocks. In particular, this process may be more beneficial for blocks with more coefficients than a preset number. A block with a small number of coefficients can be encoded more efficiently using the sig [i, j] and last [i, j] syntax of the conventional interleaving scheme described above. Thus, in one embodiment, the encoder determines the number of nonzero coefficients (NNZ) in the block and, if NNZ is less than the threshold, using conventional syntax sig [i, j] and last [i, j] Encode the sequence. The threshold may be preset to 2, 3 or any other suitable value. If NNZ is greater than or equal to the threshold, the encoder uses the two-dimensional (or one-dimensional) last significant coefficient position encoding process described above.

This syntax may be configured to include a flag that signals to the decoder whether the NNZ for the block is less than the threshold. It also signals which significance map encoding process was used by the encoder. In some cases, last_0_flag may be removed because it is relatively efficient to signal a DC only block in a conventional significance map encoding process.

Reference is now made to FIG. 10, which illustrates, in simplified flow chart form, a method 500 for encoding a significance map. The method 500 is performed for each block of quantized transform region coefficients. The method includes determining an NNZ in a block at operation 502. In operation 504, the NNZ is compared with a preset threshold. If the NNZ is below the threshold, the encoder uses the significance map encoding of the conventional interleaving scheme, as shown in operation 506. If NNZ is greater than or equal to the threshold, at operation 508, the encoder encodes the last position coordinates, as described above.

It will be appreciated that the example methods above represent specific example applications for encoding and decoding a significance map, such as defined in H.264. This application is not limited to that particular exemplary application.

Reference is now made to FIG. 4, which shows a simplified block diagram of an exemplary embodiment of an encoder 900. Encoder 900 includes a processor 902, a memory 904, and an encoding application 906. Encoding application 906 may include a computer program or application that includes instructions stored in memory 904 and that configure processor 902 to perform steps or operations as described herein. For example, encoding application 906 may encode the bitstream and output the encoded bitstream in accordance with the last significant coefficient position encoding process described herein. The encoding application 906 may include an entropy encoder 26 configured to entropy encode the input sequence and output the bitstream using one or more of the processes described herein. It will be appreciated that the encoding application 906 may be stored on a computer readable medium, such as a compact disc, flash memory device, random access memory, hard drive, or the like.

In some embodiments, the processor 902 in the encoder 900 may be a single processing unit configured to implement the instructions of the encoding application 906. In addition, it will be appreciated that in some cases, some or all of the operations of encoding application 906 and one or more processing units may be implemented via an application-specific integrated circuit (ASIC) or the like.

Reference is now made to FIG. 5, which also shows a simplified block diagram of an exemplary embodiment of the decoder 1000. Decoder 1000 includes a processor 1002, a memory 1004, and a decoding application 1006. Decoding application 1006 may include a computer program or application stored in memory 1004 and including instructions that configure processor 1002 to perform steps or operations as described herein. Decoding application 1006 receives the bitstream encoded according to the last significant coefficient position encoding process described herein and, as described herein, the last significant coefficient position context modeling process for decoding the bitstream. May include an entropy decoder 1008 configured to reconstruct quantized transform region coefficient data using. It will be appreciated that the decoding application 1006 may be stored on a computer readable medium, such as a compact disc, flash memory device, random access memory, hard drive, or the like.

In some embodiments, processor 1002 in decoder 1000 may be a single processing unit configured to implement the instructions of decoding application 1006. In some other embodiments, processor 1002 may include two or more processing units capable of executing instructions in parallel. Multiple processing units can be logically or physically separate processing units. In addition, it will be appreciated that in some cases, some or all of the operations of decoding application 1006 and one or more processing units may be implemented via an application-specific integrated circuit (ASIC) or the like.

It is well understood that the decoder and / or encoder according to the present application may be implemented in a number of computing devices, including but not limited to servers, suitably programmed general purpose computers, set top television boxes, television broadcast equipment, and mobile devices. Will know. The decoder or encoder may be implemented through software that includes instructions that configure the processor to perform the functions described herein. Software instructions may be stored in any suitable computer readable memory, including CD, RAM, ROM, flash memory, and the like.

Encoders and decoders described herein and modules, routines, processes, threads, or other software components that implement the described methods / processes of configuring the encoder can be realized using standard computer programming techniques and languages. You will know well. This application is not limited to specific processors, computer languages, computer programming conventions, data structures, and other such implementation details. Those skilled in the art will appreciate that the described processes may be implemented as part of computer executable code stored in volatile or nonvolatile memory as part of an application-specific integrated chip (ASIC) or the like.

Certain adaptations and modifications may be made to the described embodiments. Accordingly, the embodiments discussed above are to be considered illustrative rather than restrictive.

Claims (18)

A method for encoding quantized transform domain coefficient data comprising last significant coefficient information, the method comprising:
Binarizing each of the two positions of the two-dimensional coordinates of the last significant coefficient;
Determining a context for each bin of one of the locations;
Determining a context for each bin of the other of the locations, the context of each bin of the other of the locations based in part on the one of the locations ; And
Entropy encoding the binarized positions based on a context determined for each of the bins of the binarized positions to produce encoded data.
And a method for encoding quantized transform region coefficient data. The method of claim 1,
And wherein said binarizing comprises encoding each of said two positions as a fixed length binary code. 3. The method according to claim 1 or 2,
Determining the context for each bin of the other one of the locations includes calculating a context index that specifies the determined context, wherein the context index is the one of the locations, the transform And a block size, and if present, calculated based on previous bins at the other one of the positions. 4. The method according to any one of claims 1 to 3,
Wherein the two positions comprise an x-position and a y-position within a block. The method of claim 1,
Determining the context for each bin of the other one of the locations includes calculating a context index that specifies the determined context, wherein the context index is a binary of the one of the locations. A method for encoding quantized transform domain coefficient data, which is based on a binary logarithm. The method according to any one of claims 1 to 5,
Prior to performing the binarization, determining the context for each bin of each location, and entropy encoding, determining that the two-dimensional coordinates are not [0,0]. , A method for encoding quantized transform domain coefficient data. 7. The method according to any one of claims 1 to 6,
Prior to said binarizing, determining a context for each bin of one of said locations, and determining a context for each bin of another of said locations, said quantized Counting the number of non-zero coefficients in the transform domain coefficient data and determining that the number meets or exceeds a threshold. An encoder for encoding quantized transform domain coefficient data, the encoder comprising:
A processor;
Memory; And
An encoding application, stored in the memory, comprising instructions for configuring the processor to encode the quantized transform region coefficient data by performing the method of any one of claims 1 to 7.
And an encoder for encoding the quantized transform region coefficient data. A method for decoding a bitstream of encoded data to reconstruct quantized transform region coefficient data,
Entropy decoding a portion of the encoded data to generate two binary positions that define two-dimensional coordinates of a last significant coefficient, wherein entropy decoding the portion of the data comprises:
Determining a context for each bin of one of the locations, and
Determining a context for each bin of the other one of the locations
Wherein the context of each bin of the other one of the locations is based in part on the one of the locations;
Entropy decoding a significant coefficient sequence based on the two-dimensional coordinates of the last significant coefficient;
Entropy decoding level information based on the valid coefficient sequence; And
Reconstructing the quantized transform region coefficient data using the level information and the effective coefficient sequence
And a bitstream of the encoded data. 10. The method of claim 9,
Wherein each of the two binarized locations comprises a fixed length binary code. 11. The method according to claim 9 or 10,
Entropy decoding the significant coefficient sequence comprises converting the two-dimensional coordinates of the last significant coefficient into a one-dimensional index representing the end of the significant coefficient sequence. How to. 12. The method according to any one of claims 9 to 11,
Determining the context for each bin of the other one of the locations includes calculating a context index that specifies the determined context, wherein the context index is the one of the locations, the transform And a block size, and if present, calculated based on previous bins at the other one of the locations. 13. The method according to any one of claims 9 to 12,
Wherein the two positions comprise an x-position and a y-position within the block. 10. The method of claim 9,
Determining the context for each bin of the other one of the locations includes calculating a context index that specifies the determined context, wherein the context index is a binary of the one of the locations. A method for decoding a bitstream of encoded data, which is based on a log. 15. The method according to any one of claims 9 to 14,
Prior to decoding the portion, further comprising entropy decoding a zero flag and determining from the zero flag that the two-dimensional coordinate position is not [0,0]. Method for decoding a bitstream. 16. The method according to any one of claims 9 to 15,
Entropy decoding a non-zero coefficient flag, and entropy decoding the portion based on the value of the non-zero coefficient flag. Method for decoding the. A decoder for decoding a bitstream of encoded data to reconstruct a sequence of symbols, the method comprising:
The symbols belong to a finite alphabet and the decoder
A processor;
Memory; And
17. A decoding application, stored in the memory, comprising instructions for configuring the processor to decode the bitstream by performing the method of any one of claims 9-16.
And a decoder for decoding the bitstream of the encoded data. 17. A computer readable medium storing computer executable instructions that, when executed by a processor, configure the processor to execute the method of any one of claims 1-7 or 9-16.

Images