RFC-editor clarifications for draft-bankoski-vp8-bitstream-06
Change-Id: I0fce82782684cdc492d0a139b4978104a4d06136
modified: text_src/02.00__vp8-bitstream__format-overview.txt
modified: text_src/04.00__vp8-bitstream__overview-of-compressed-data-format.txt
modified: text_src/05.00__vp8-bitstream__overview-of-the-decoding-process.txt
modified: text_src/06.00__vp8-bitstream__description-of-algorithms.txt
modified: text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
modified: text_src/07.01__vp8-bitstream__underlying-theory-of-coding.txt
modified: text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
modified: text_src/08.00__vp8-bitstream__compressed-data-components.txt
modified: text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
modified: text_src/08.02__vp8-bitstream__tree-coding-example.txt
modified: text_src/09.00__vp8-bitstream__frame-header.txt
modified: text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
modified: text_src/09.02__vp8-bitstream__color-space-and-pixel-type-key-frames-only.txt
modified: text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
modified: text_src/09.05__vp8-bitstream__token-partition-and-partition-data-offsets.txt
modified: text_src/09.06__vp8-bitstream__dequantization-indices.txt
modified: text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt
modified: text_src/09.10__vp8-bitstream__remaining-frame-header-data-non-key-frame.txt
modified: text_src/09.11__vp8-bitstream__remaining-frame-header-data-key-frame.txt
modified: text_src/10.00__vp8-bitstream__segment-based-feature-adjustments.txt
modified: text_src/11.01__vp8-bitstream__mbskipcoeff.txt
modified: text_src/11.02__vp8-bitstream__luma-modes.txt
modified: text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
modified: text_src/12.01__vp8-bitstream__mbskipcoeff.txt
modified: text_src/12.02__vp8-bitstream__chroma-prediction.txt
modified: text_src/12.03__vp8-bitstream__luma-prediction.txt
modified: text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
modified: text_src/13.01__vp8-bitstream__mb-without-non-zero-coefficient-values.txt
modified: text_src/13.02__vp8-bitstream__coding-of-individual-coefficient-values.txt
modified: text_src/13.03__vp8-bitstream__token-probabilities.txt
modified: text_src/13.04__vp8-bitstream__token-probability-updates.txt
modified: text_src/13.05__vp8-bitstream__default-token-probability-table.txt
modified: text_src/14.01__vp8-bitstream__dequantization.txt
modified: text_src/14.03__vp8-bitstream__implementation-of-wht-inversion.txt
modified: text_src/14.04__vp8-bitstream__implementation-of-dct-inversion.txt
modified: text_src/14.05__vp8-bitstream__summation-of-predictor-and-residue.txt
modified: text_src/15.02__vp8-bitstream__simple-filter.txt
modified: text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
modified: text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
modified: text_src/16.03__vp8-bitstream__mode-and-motion-vector-contexts.txt
modified: text_src/18.01__vp8-bitstream__bounds-on-and-adjustment-of-motion-vectors.txt
modified: text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
modified: text_src/18.04__vp8-bitstream__filter-properties.txt
modified: text_src/a.01_vp8-bitstream__frame_tag.txt
modified: text_src/a.02_vp8-bitstream__frame_header.txt
modified: text_src/a.03_vp8-bitstream__mb_header.txt
modified: text_src/atch1/dixie.c
modified: text_src/atch1/dixie.h
modified: text_src/atch1/predict.c
modified: text_src/atch1/tokens.c
modified: text_src/atch1/vp8_prob_data.h
modified: text_src/atch1/vpx_codec_internal.h
modified: text_src/atch1/vpx_decoder_compat.h
modified: text_src/atch1/vpx_image.h
Remove unused References file (see XML template instead).
Change-Id: Icc160cf3150e790cdb72eb503b8915472748393e
deleted: ../text_src/20.00__vp8-bitstream__references.txt
A few late edit re -06 questions.
Change-Id: Ibc52444f2ecf19bcd2dc2628d2490ec35b1cde67
modified: text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt
modified: text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
diff --git a/text_src/02.00__vp8-bitstream__format-overview.txt b/text_src/02.00__vp8-bitstream__format-overview.txt
index f690458..323e639 100644
--- a/text_src/02.00__vp8-bitstream__format-overview.txt
+++ b/text_src/02.00__vp8-bitstream__format-overview.txt
@@ -18,7 +18,7 @@
Pixels are always treated, at a minimum, at the level of subblocks, which may be thought of as the "atoms" of the VP8 algorithm. In particular, the 2x2 chroma blocks corresponding to 4x4 Y subblocks are never treated explicitly in the data format or in the algorithm specification.
-The DCT and WHT always operate at a 4x4 resolution. The DCT is used for the 16Y, 4U and 4V subblocks. The WHT is used (with some but not all prediction modes) to encode a 4x4 array comprising the average intensities of the 16 Y subblocks of a macroblock. These average intensities are, up to a constant normalization factor, nothing more that the zero<sup>th</sup> DCT coefficients of the Y subblocks. This "higher-level" WHT is a substitute for the explicit specification of those coefficients, in exactly the same way as the DCT of a subblock substitutes for the specification of the pixel values comprising the subblock. We consider this 4x4 array as a _second-order_ subblock called Y2, and think of a macroblock as containing 24 "real" subblocks and, sometimes, a 25th "virtual" subblock. This is dealt with further in Chapter 13.
+The DCT and WHT always operate at a 4x4 resolution. The DCT is used for the 16Y, 4U and 4V subblocks. The WHT is used (with some but not all prediction modes) to encode a 4x4 array comprising the average intensities of the 16 Y subblocks of a macroblock. These average intensities are, up to a constant normalization factor, nothing more that the 0th DCT coefficients of the Y subblocks. This "higher-level" WHT is a substitute for the explicit specification of those coefficients, in exactly the same way as the DCT of a subblock substitutes for the specification of the pixel values comprising the subblock. We consider this 4x4 array as a _second-order_ subblock called Y2, and think of a macroblock as containing 24 "real" subblocks and, sometimes, a 25th "virtual" subblock. This is dealt with further in Chapter 13.
The frame layout used by the reference decoder may be found in the file `vpx_image.h`.
diff --git a/text_src/04.00__vp8-bitstream__overview-of-compressed-data-format.txt b/text_src/04.00__vp8-bitstream__overview-of-compressed-data-format.txt
index 9936fb4..e3331d6 100644
--- a/text_src/04.00__vp8-bitstream__overview-of-compressed-data-format.txt
+++ b/text_src/04.00__vp8-bitstream__overview-of-compressed-data-format.txt
@@ -25,5 +25,5 @@
A related matter is that seeking within a partition is not supported. The data must be decompressed and processed (or at least stored) in the order in which it occurs in the partition.
-While this document specifies the ordering of the partition data correctly, the details and semantics of this data are discussed in a more logical fashion to facilitate comprehension. For example, the frame header contains updates to many probability tables used in decoding per-macroblock data. The latter is often described before the layouts of the probabilities and their updates, even though this is the opposite of their order in the bitstream.
+While this document specifies the ordering of the partition data correctly, the details and semantics of this data are discussed in a more logical fashion to facilitate comprehension. For example, the frame header contains updates to many probability tables used in decoding per-macroblock data. The per-macroblock data is often described before the layouts of the probabilities and their updates, even though this is the opposite of their order in the bitstream.
diff --git a/text_src/05.00__vp8-bitstream__overview-of-the-decoding-process.txt b/text_src/05.00__vp8-bitstream__overview-of-the-decoding-process.txt
index 2e4632a..ca998dd 100644
--- a/text_src/05.00__vp8-bitstream__overview-of-the-decoding-process.txt
+++ b/text_src/05.00__vp8-bitstream__overview-of-the-decoding-process.txt
@@ -6,7 +6,7 @@
Most implementations will wish to "pad" these buffers with "invisible" pixels that extend a moderate number of pixels beyond all four edges of the visible image. This simplifies interframe prediction by allowing all (or most) prediction blocks -- which are _not_ guaranteed to lie within the visible area of a prior frame -- to address usable image data.
-Regardless of the amount of padding chosen, the invisible rows above (below) the image are filled with copies of the top (bottom) row of the image; the invisible columns to the left (right) of the image are filled with copies of the leftmost (rightmost) visible row; and the four invisible corners are filled with copies of the corresponding visible corner pixels. The use of these prediction buffers (and suggested sizes for the _halo_) will be elaborated on in the discussion of motion vectors, interframe prediction, and sub-pixel interpolation later in this document.
+Regardless of the amount of padding chosen, the invisible rows above (or below) the image are filled with copies of the top (or bottom) row of the image; the invisible columns to the left (or right) of the image are filled with copies of the leftmost (or rightmost) visible row; and the four invisible corners are filled with copies of the corresponding visible corner pixels. The use of these prediction buffers (and suggested sizes for the _halo_) will be elaborated on in the discussion of motion vectors, interframe prediction, and sub-pixel interpolation later in this document.
As will be seen in the description of the frame header, the image dimensions are specified (and can change) with every key frame. These buffers (and any other data structures whose size depends on the size of the image) should be allocated (or re-allocated) immediately after the dimensions are decoded.
@@ -22,7 +22,7 @@
Regardless of the prediction method, the residue DCT signal is decoded, dequantized, reverse-transformed, and added to the prediction buffer to produce the (almost final) reconstruction value of the macroblock, which is stored in the correct position of the current frame buffer.
-The residue signal consists of 24 (sixteen Y, four U, and four V) 4x4 quantized and losslessly-compressed DCT transforms approximating the difference between the original macroblock in the uncompressed source and the prediction buffer. For most prediction modes, the zero<sup>th</sup> coefficients of the sixteen Y subblocks are expressed via a 25th WHT of the second-order virtual Y2 subblock discussed above.
+The residue signal consists of 24 (sixteen Y, four U, and four V) 4x4 quantized and losslessly-compressed DCT transforms approximating the difference between the original macroblock in the uncompressed source and the prediction buffer. For most prediction modes, the 0th coefficients of the sixteen Y subblocks are expressed via a 25th WHT of the second-order virtual Y2 subblock discussed above.
_Intra-prediction_ exploits the spatial coherence of frames. The 16x16 luma (Y) and 8x8 chroma (UV) components are predicted independently of each other using one of four simple means of pixel propagation, starting from the already-reconstructed (16-pixel long luma, 8-pixel long chroma) row above and column to the left of the current macroblock. The four methods are:
diff --git a/text_src/06.00__vp8-bitstream__description-of-algorithms.txt b/text_src/06.00__vp8-bitstream__description-of-algorithms.txt
index 48383a3..36bc114 100644
--- a/text_src/06.00__vp8-bitstream__description-of-algorithms.txt
+++ b/text_src/06.00__vp8-bitstream__description-of-algorithms.txt
@@ -54,7 +54,7 @@
{:lang="c"}
-We occasionally need to discuss mathematical functions involving honest-to-goodness "infinite precision" real numbers. The DCT is first described via the cosine function [[ cos ]]; the ratio of the lengths of the circumference and diameter of a circle is denoted [[ pi ]]; at one point, we take a (base [[ 1//2 ]]) logarithm denoted [[ log ]]; and [[ pow( x, y) ]] denotes [[ x ]] raised to the power [[ y ]]. If [[ x = 2 ]] and [[ y ]] is a small non-negative integer, [[ pow( 2, y) ]] may be expressed in C as `1 << y`.
+We occasionally need to discuss mathematical functions involving honest-to-goodness "infinite precision" real numbers. The DCT is first described via the cosine function [[ cos ]]; the ratio of the lengths of the circumference and diameter of a circle is denoted [[ pi ]]; at one point, we take a (base [[ 1//2 ]]) logarithm denoted [[ log ]]; and [[ pow(x, y) ]] denotes [[ x ]] raised to the power [[ y ]]. If [[ x = 2 ]] and [[ y ]] is a small non-negative integer, [[ pow(2, y) ]] may be expressed in C as `1 << y`.
Finally, we sometimes need to divide signed integers by powers of two, that is, we occasionally right-shift signed numbers. The behavior of such shifts (i.e., the propagation of the sign bit) is, perhaps surprisingly, not defined by the C language itself and is left up to individual compilers. Because of the utility of this frequently needed operation, it is at least arguable that it should be defined by the language (to naturally propagate the sign bit) and, at a minimum, should be correctly implemented by any reasonable compiler. In the interest of strict portability, we attempt to call attention to these shifts when they arise.
diff --git a/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt b/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
index fc2c98b..cc3192e 100644
--- a/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
+++ b/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
@@ -22,5 +22,5 @@
Because most of the bools in the VP8 datastream have zero-probabilities nowhere near [[ 1//2 ]], the compression provided by the `bool_encoder` is critical to the performance of VP8.
-The bool coder used by VP8 is a variant of an arithmetic coder. An excellent discussion of arithmetic coding (and other lossless compression techniques) can be found in the book _Text Compression_ by Timothy C. Bell, John G. Cleary, and Ian H. Witten, published in 1990 by Prentice-Hall.
+The boolean coder used by VP8 is a variant of an arithmetic coder. An excellent discussion of arithmetic coding (and other lossless compression techniques) can be found in the book _Text Compression_ by Timothy C. Bell, John G. Cleary, and Ian H. Witten, published in 1990 by Prentice-Hall.
diff --git a/text_src/07.01__vp8-bitstream__underlying-theory-of-coding.txt b/text_src/07.01__vp8-bitstream__underlying-theory-of-coding.txt
index 21bb449..66fff7d 100644
--- a/text_src/07.01__vp8-bitstream__underlying-theory-of-coding.txt
+++ b/text_src/07.01__vp8-bitstream__underlying-theory-of-coding.txt
@@ -2,7 +2,7 @@
#### 7.1 Underlying Theory of Coding {#h-07-01}
-The basic idea used by the bool coder is to consider the entire data stream (either of the partitions in our case) as the binary expansion of a single number [[ x ]] with [[ 0 <= x < 1 ]]. The bits (or bytes) in [[ x ]] are of course written from high to low order and if [[ b[j] (B[j]) ]] is the [[ j^(th) ]] bit (byte) in the partition, the value [[ x ]] is simply the sum (starting with [[ j = 1 ]]) of [[ pow(2, -j) * b[j] ]] or [[ pow(256, -j) * B[j] ]].
+The basic idea used by the boolean coder is to consider the entire data stream (either of the partitions in our case) as the binary expansion of a single number [[ x ]] with [[ 0 <= x < 1 ]]. The bits (or bytes) in [[ x ]] are of course written from high to low order and if [[ b[j] (B[j]) ]] is the [[ j^(th) ]] bit (byte) in the partition, the value [[ x ]] is simply the sum (starting with [[ j = 1 ]]) of [[ pow(2, -j) * b[j] ]] or [[ pow(256, -j) * B[j] ]].
Before the first bool is coded, all values of [[ x ]] are possible.
diff --git a/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt b/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
index e0a45ee..0122dfd 100644
--- a/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
+++ b/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
@@ -2,11 +2,11 @@
#### 7.2 Practical Algorithm Description {#h-07-02}
-VP8's bool coder works with 8-bit probabilities [[ p ]]. The range of such [[ p ]] is [[ 0 <= p <= 255 ]]; the actual probability represented by [[ p ]] is [[ p//256 ]]. Also, the coder is designed so that decoding of a bool requires no more than an 8-bit comparison and so that the state of both the encoder and decoder can be easily represented using a small number of unsigned 16-bit integers.
+VP8's boolean coder works with 8-bit probabilities [[ p ]]. The range of such [[ p ]] is [[ 0 <= p <= 255 ]]; the actual probability represented by [[ p ]] is [[ p//256 ]]. Also, the coder is designed so that decoding of a bool requires no more than an 8-bit comparison and so that the state of both the encoder and decoder can be easily represented using a small number of unsigned 16-bit integers.
-The details are most easily understood if we first describe the algorithm using bit-at-a-time input and output. Aside from the ability to maintain a position in this bitstream and write/read bits, the encoder also needs the ability to add [[ 1 ]] to the bits already output; after writing [[ n ]] bits, adding [[ 1 ]] to the existing output is the same thing as adding [[ pow( 2, -n) ]] to [[ x ]].
+The details are most easily understood if we first describe the algorithm using bit-at-a-time input and output. Aside from the ability to maintain a position in this bitstream and write/read bits, the encoder also needs the ability to add [[ 1 ]] to the bits already output; after writing [[ n ]] bits, adding [[ 1 ]] to the existing output is the same thing as adding [[ pow(2, -n) ]] to [[ x ]].
-Together with the bit position, the encoder must maintain two unsigned 8-bit numbers which we call [[ "bottom" ]] and [[ "range" ]]. Writing [[ w ]] for the [[ n ]] bits already written and [[ S = pow( 2, - n - 8) ]] for the scale of the current bit position one byte out, we have the following constraint on all future values [[ v ]] of [[ w ]] (including the final value [[ v = x ]]):
+Together with the bit position, the encoder must maintain two unsigned 8-bit numbers which we call [[ "bottom" ]] and [[ "range" ]]. Writing [[ w ]] for the [[ n ]] bits already written and [[ S = pow(2, - n - 8) ]] for the scale of the current bit position one byte out, we have the following constraint on all future values [[ v ]] of [[ w ]] (including the final value [[ v = x ]]):
[[ w + ( S * "bottom" ) <= v < w + ( S * ( "bottom" + "range" ) ) ]]
diff --git a/text_src/08.00__vp8-bitstream__compressed-data-components.txt b/text_src/08.00__vp8-bitstream__compressed-data-components.txt
index 4e57e2c..69f6dfe 100644
--- a/text_src/08.00__vp8-bitstream__compressed-data-components.txt
+++ b/text_src/08.00__vp8-bitstream__compressed-data-components.txt
@@ -17,7 +17,6 @@
| `F? X` | | A flag which, if true, is followed by a piece of data `X`.
| `F? X:Y` | | A flag which, if true, is followed by `X` and, if false, is followed by `Y`. Also used to express a value where `Y` is an implicit default (not encoded in the data stream), as in [[ F? P(8):255 ]], which expresses an optional probability: if the flag is true, the probability is specified as an 8-bit literal, while if the flag is false, the probability defaults to `255`.
| `B(p)? X` | `B(p)? X:Y` | Variants of the above using a boolean indicator whose probability is not necessarily `128`.
-| `X` | | Multi-component field, the specifics of which will be given at a more appropriate point in the discussion.
| `T` | | Tree-encoded value from small alphabet.
The last type requires elaboration. We often wish to encode something whose value is restricted to a small number of possibilities (the alphabet).
diff --git a/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt b/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
index e60c262..fbfc63e 100644
--- a/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
+++ b/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
@@ -6,7 +6,7 @@
It is most convenient to represent the values using small positive integers, typically an enum counting up from zero. The largest alphabet (used to code DCT coefficients, described in Chapter 13 that is tree-coded by VP8 has only 12 values. The tree for this alphabet adds 11 interior nodes and so has a total of 23 positions. Thus, an 8-bit number easily accommodates both a tree position and a return value.
-A tree may then be compactly represented as an array of (pairs of) 8-bit integers. Each (even) array index corresponds to an interior node of the tree;, the zero<sup>th</sup> index of course corresponds to the root of the tree. The array entries come in pairs corresponding to the left (0) and right (1) branches of the subtree below the interior node. We use the convention that a positive (even) branch entry is the index of a deeper interior node, while a nonpositive entry [[ v ]] corresponds to a leaf whose value is [[ -v ]].
+A tree may then be compactly represented as an array of (pairs of) 8-bit integers. Each (even) array index corresponds to an interior node of the tree;, the 0th index of course corresponds to the root of the tree. The array entries come in pairs corresponding to the left (0) and right (1) branches of the subtree below the interior node. We use the convention that a positive (even) branch entry is the index of a deeper interior node, while a nonpositive entry [[ v ]] corresponds to a leaf whose value is [[ -v ]].
The node probabilities associated to a tree-coded value are stored in an array whose indices are half the indices of the corresponding tree positions. The length of the probability array is one less than the size of the alphabet.
diff --git a/text_src/08.02__vp8-bitstream__tree-coding-example.txt b/text_src/08.02__vp8-bitstream__tree-coding-example.txt
index 070d8bb..d7549dc 100644
--- a/text_src/08.02__vp8-bitstream__tree-coding-example.txt
+++ b/text_src/08.02__vp8-bitstream__tree-coding-example.txt
@@ -12,7 +12,7 @@
DC_PRED, /* predict DC using row above and column to the left */
V_PRED, /* predict rows using row above */
H_PRED, /* predict columns using column to the left */
- TM_PRED, /* propagate second differences a la "true motion" */
+ TM_PRED, /* propagate second differences a la "True Motion" */
B_PRED, /* each Y subblock is independently predicted */
@@ -64,5 +64,5 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-Since it greatly facilitates re-use of reference code and since there is no real reason to do otherwise, it is strongly suggested that any decoder implementation use exactly the same enumeration values and probability table layouts as described in this document (and in the reference code) for all tree-coded data in VP8.
+Since it greatly facilitates re-use of reference code, and since there is no real reason to do otherwise, it is strongly suggested that any decoder implementation use exactly the same enumeration values and probability table layouts as those described in this document (and in the reference code) for all tree-coded data in VP8.
diff --git a/text_src/09.00__vp8-bitstream__frame-header.txt b/text_src/09.00__vp8-bitstream__frame-header.txt
index c57a83d..990a22f 100644
--- a/text_src/09.00__vp8-bitstream__frame-header.txt
+++ b/text_src/09.00__vp8-bitstream__frame-header.txt
@@ -2,5 +2,5 @@
### Chapter 9: Frame Header {#h-09-00}
-The uncompressed data chunk at the start of each frame and the first part of the first data partition contains information pertaining to the frame as a whole. We list the fields in the order of occurrence, giving details for some of the fields. Other details are postponed until a more logical point in our overall description. Most of the header decoding occurs in the reference decoder file `dixie.c`.
+The uncompressed data chunk at the start of each frame and the first part of the first data partition contains information pertaining to the frame as a whole. We list the fields in the order of occurrence. Most of the header decoding occurs in the reference decoder file `dixie.c`.
diff --git a/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt b/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
index 0dca022..76f8bbb 100644
--- a/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
+++ b/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
@@ -37,7 +37,7 @@
The following source code segment illustrates validation of the start code and reading the width, height and scale factors for a key frame.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-unsigned char *c = pbi->Source+3;
+unsigned char *c = pbi->source+3;
// vet via sync code
if(c[0]!=0x9d||c[1]!=0x01||c[2]!=0x2a)
diff --git a/text_src/09.02__vp8-bitstream__color-space-and-pixel-type-key-frames-only.txt b/text_src/09.02__vp8-bitstream__color-space-and-pixel-type-key-frames-only.txt
index c5e0ddb..c4e2efc 100644
--- a/text_src/09.02__vp8-bitstream__color-space-and-pixel-type-key-frames-only.txt
+++ b/text_src/09.02__vp8-bitstream__color-space-and-pixel-type-key-frames-only.txt
@@ -1,6 +1,6 @@
-#### 9.2 Color Space and Pixel Type (Key Frames-only) {#h-09-02}
+#### 9.2 Color Space and Pixel Type (Key Frames Only) {#h-09-02}
| Field | Value
diff --git a/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt b/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
index 620dd15..446851f 100644
--- a/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
+++ b/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
@@ -3,17 +3,23 @@
#### 9.3 Segment-based Adjustments {#h-09-03}
-This subsection contains probability and value information for implementing segment adaptive adjustments to default decoder behaviors. The data in this section is used in the decoding of the ensuing per-segment information and applies to the entire frame. When segment adaptive adjustments are enabled, each macroblock will be assigned a segment ID. Macroblocks with the same segment ID belong to same segment, and have the same adaptive adjustments over default baseline values for the frame. The adjustments can be quantization level or loop filter strength.
+This subsection contains probability and value information for implementing segment adaptive adjustments to default decoder behaviors. The data in this section is used in the decoding of the ensuing per-segment information and applies to the entire frame. When segment adaptive adjustments are enabled, each macroblock will be assigned a segment ID. Macroblocks with the same segment ID belong to same segment, and have the same adaptive adjustments over default baseline values for the frame. The adjustments can be quantizer level or loop filter strength.
-The context for decoding this feature at macroblock level is provided by a subsection in the frame header, which contains::
+The context for decoding this feature at the macroblock level is provided by a subsection in the frame header, which contains:
- 1. A `segmentation_enabled` Flag which if `1` (`0`), enables (disables) the feature for this frame. The remaining fields occur if the feature is enabled.
- 2. `L(1)` indicates if the segment map is updated for the current frame (`update_mb_segmentaton_map`)
- 3. `L(1)` indicates if the segment feature data items are updated for the current frame
- 4. If flag in 3 is `1`, the following fields occur:
- 1. `L(1)` the mode of segment feature data, can be absolute value mode or delta value mode, later mode, feature data is the difference against current frame defaults.
- 2. Segment feature data items are decoded segment by each segment for each segment feature. For every data item, a one bit flag indicating if the item is `0` or a non-zero value to be decoded. If there is non-zero value, the value is decoded as a magnitude `L(n)` followed by a one bit sign (`L(1)`, `0` for positive and `1` for negative). The length `n` can be looked up from a pre-defined length table for all feature data.
- 5. If flag in 2 is `1`, the probabilities of the decoding tree for segment map are decoded from the bitstream. Each probability is decoded with one bit flag indicating if the probability is the default value of `255` (flag is `0`), or the probability is an 8-bit value, `L(8)`, from the bitstream.
+ 1. A `segmentation_enabled` flag that enables the feature for this frame if set to `1`, and disables it if set to `0`. The following fields occur if the feature is enabled.
-The layout and semantics supporting this feature at the macroblock level will be described in Chapter 10.
+ 2. `L(1)` indicates if the segment map is updated for the current frame (`update_mb_segmentation_map`).
+
+ 3. `L(1)` indicates if the segment feature data items are updated for the current frame (`update_segment_feature_data`).
+
+ 4. If Item 3 above (`update_segment_feature_data`) is `1`, the following fields occur:
+
+ a. `L(1)` the mode of segment feature data (`segment_feature_mode`) can be absolute value mode (`0`) or delta value mode (`1`).
+
+ b. Segment feature data items are decoded segment by segment for each segment feature. For every data item, a one-bit flag indicates whether the item is `0`, or a non-zero value to be decoded. If the value is non-zero, then the value is decoded as a magnitude `L(n)`, followed by a one-bit sign (`L(1)` -- `0` for positive and `1` for negative). The length `n` can be looked up from a pre-defined length table for all feature data.
+
+ 5. If the `L(1)` flag as noted in Item 2 above is set to `1`, the probabilities of the decoding tree for the segment map are decoded from the bitstream. Each probability is decoded with a one-bit flag indicating whether the probability is the default value of `255` (flag is set to `0`) or an 8-bit value, `L(8)`, from the bitstream.
+
+The layout and semantics supporting this feature at the macroblock level are described in Chapter 10.
diff --git a/text_src/09.05__vp8-bitstream__token-partition-and-partition-data-offsets.txt b/text_src/09.05__vp8-bitstream__token-partition-and-partition-data-offsets.txt
index 2a90356..054778d 100644
--- a/text_src/09.05__vp8-bitstream__token-partition-and-partition-data-offsets.txt
+++ b/text_src/09.05__vp8-bitstream__token-partition-and-partition-data-offsets.txt
@@ -12,7 +12,7 @@
| 1 | 0 | 4
| 1 | 1 | 8
-Offsets are embedded in the bitstream to provide the decoder direct access to token partitions. If the number of data partitions is greater then 1, the size of each partition (except the last) is written in 3 bytes (24 bits). The size of the last partition is the remainder of the data not used by any of the previous partitions. The partitioned data are consecutive in the bitstream, so the size can also be used to calculate the offset of each partition. The following pseudo code illustrates how the size/offset is defined by the three bytes in the bitstream.
+Offsets are embedded in the bitstream to provide the decoder direct access to token partitions. If the number of data partitions is greater then 1, the size of each partition (except the last) is written in 3 bytes (24 bits). The size of the last partition is the remainder of the data not used by any of the previous partitions. The partitioned data are consecutive in the bitstream, so the size can also be used to calculate the offset of each partition. The following pseudocode illustrates how the size/offset is defined by the three bytes in the bitstream.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/09.06__vp8-bitstream__dequantization-indices.txt b/text_src/09.06__vp8-bitstream__dequantization-indices.txt
index d26f678..b599a3a 100644
--- a/text_src/09.06__vp8-bitstream__dequantization-indices.txt
+++ b/text_src/09.06__vp8-bitstream__dequantization-indices.txt
@@ -5,7 +5,7 @@
All residue signals are specified via a quantized 4x4 DCT applied to the Y, U, V, or Y2 subblocks of a macroblock. As detailed in Chapter 14, before inverting the transform, each decoded coefficient is multiplied by one of six dequantization factors, the choice of which depends on the plane (Y, chroma = U or V, Y2) and coefficient position (DC = coefficient 0, AC = coefficients 1-15). The six values are specified using 7-bit indices into six corresponding fixed tables (the tables are given in Chapter 14).
-The first 7-bit index gives the dequantization table index for Y plane AC coefficients, called yac_qi. It is always coded and acts as a baseline for the other 5 quantization indices, each of which is represented by a delta from this baseline index. Following is pseudo code for reading the indices:
+The first 7-bit index gives the dequantization table index for Y plane AC coefficients, called yac_qi. It is always coded and acts as a baseline for the other 5 quantization indices, each of which is represented by a delta from this baseline index. Following is pseudocode for reading the indices:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt b/text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt
index 50f8f89..8297cea 100644
--- a/text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt
+++ b/text_src/09.09__vp8-bitstream__dct-coefficient-probability-update.txt
@@ -3,7 +3,7 @@
#### 9.9 DCT Coefficient Probability Update {#h-09-09}
-Contains a partial update of the probability tables used to decode DCT coefficients. These tables are maintained across interframes but are of course replaced with their defaults at the beginning of every key frame.
+Contains updates to the probability tables used to decode DCT coefficients. For each of the probabilities in the tables, there is an L(1) flag indicating if the probability is updated for the current frame, and if the L(1) is 1, there follows an additional 8 bit value representing the new probability value. These tables are maintained across interframes but are of course replaced with their defaults at the beginning of every key frame.
The layout and semantics of this field will be taken up in Chapter 13.
diff --git a/text_src/09.10__vp8-bitstream__remaining-frame-header-data-non-key-frame.txt b/text_src/09.10__vp8-bitstream__remaining-frame-header-data-non-key-frame.txt
index 4df0253..47282d1 100644
--- a/text_src/09.10__vp8-bitstream__remaining-frame-header-data-non-key-frame.txt
+++ b/text_src/09.10__vp8-bitstream__remaining-frame-header-data-non-key-frame.txt
@@ -5,14 +5,14 @@
| Index | Description
| --------- | -----------------------------------------------------
-| `L(1)` | `mb_no_coeff_skip`. This flag indicates at the frame level if skipping of macroblocks with no non-zero coefficients is enabled. If it is set to `0` then `prob_skip_false` is not read and `mb_skip_coeff` is forced to `0` for all macroblocks (see Sections 11.1 and 12.1).
-| `L(8)` | `prob_skip_false` = probability used for decoding a macroblock level flag, which indicates if a macroblock has any non-zero coefficients. Only read if `mb_no_coeff_skip` is `1`.
+| `L(1)` | `mb_no_skip_coeff`. This flag indicates at the frame level if skipping of macroblocks with no non-zero coefficients is enabled. If it is set to `0` then `prob_skip_false` is not read and `mb_skip_coeff` is forced to `0` for all macroblocks (see Sections 11.1 and 12.1).
+| `L(8)` | `prob_skip_false` = probability used for decoding a macroblock level flag, which indicates if a macroblock has any non-zero coefficients. Only read if `mb_no_skip_coeff` is `1`.
| `L(8)` | `prob_intra` = probability that a macroblock is "intra" predicted, that is, predicted from the already-encoded portions of the current frame as opposed to "inter" predicted, that is, predicted from the contents of a prior frame.
| `L(8)` | `prob_last` = probability that an inter-predicted macroblock is predicted from the immediately previous frame, as opposed to the most recent golden frame or altref frame..
| `L(8)` | `prob_gf` = probability that an inter-predicted macroblock is predicted from the most recent golden frame, as opposed to the altref frame
| `F` | If true, followed by four `L(8)`s updating the probabilities for the different types of intra-prediction for the Y plane. These probabilities correspond to the four interior nodes of the decoding tree for intra Y modes in an interframe, that is, the even positions in the `ymode_tree` array given above.
| `F` | If true, followed by three `L(8)`s updating the probabilities for the different types of intra-prediction for the chroma planes. These probabilities correspond to the even positions in the `uv_mode_tree` array given above.
-| `X` | Motion vector probability update. The details will be given after the discussion of motion vector decoding.
+| `X` | Motion vector probability update. Details are given in 17.2, Probability Updates.
Decoding of this portion of the frame header is handled in the reference decoder file `dixie.c`.
diff --git a/text_src/09.11__vp8-bitstream__remaining-frame-header-data-key-frame.txt b/text_src/09.11__vp8-bitstream__remaining-frame-header-data-key-frame.txt
index ee1a8d7..6aa8d5d 100644
--- a/text_src/09.11__vp8-bitstream__remaining-frame-header-data-key-frame.txt
+++ b/text_src/09.11__vp8-bitstream__remaining-frame-header-data-key-frame.txt
@@ -5,8 +5,8 @@
| Index | Description
| ------------ | -------------
-| `L(1)` | `mb_no_coeff_skip`. This flag indicates at the frame level if skipping of macroblocks with no non-zero coefficients is enabled. If it is set to `0` then `prob_skip_false` is not read and `mb_skip_coeff` is forced to `0` for all macroblocks (see Sections 11.1 and 12.1).
-| `L(8)` | `prob_skip_false` = Probability used for decoding a macroblock level flag, which indicates if a macroblock has any non-zero coefficients. Only read if `mb_no_coeff_skip` is `1`.
+| `L(1)` | `mb_no_skip_coeff`. This flag indicates at the frame level if skipping of macroblocks with no non-zero coefficients is enabled. If it is set to `0` then `prob_skip_false` is not read and `mb_skip_coeff` is forced to `0` for all macroblocks (see Sections 11.1 and 12.1).
+| `L(8)` | `prob_skip_false` = Probability used for decoding a macroblock level flag, which indicates if a macroblock has any non-zero coefficients. Only read if `mb_no_skip_coeff` is `1`.
Decoding of this portion of the frame header is handled in the reference decoder file `modemv.c`.
diff --git a/text_src/10.00__vp8-bitstream__segment-based-feature-adjustments.txt b/text_src/10.00__vp8-bitstream__segment-based-feature-adjustments.txt
index 1addcfa..1243286 100644
--- a/text_src/10.00__vp8-bitstream__segment-based-feature-adjustments.txt
+++ b/text_src/10.00__vp8-bitstream__segment-based-feature-adjustments.txt
@@ -3,7 +3,7 @@
### Chapter 10: Segment-based Feature Adjustments {#h-10-00}
-Every macroblock may optionally override some of the default behaviors of the decoder. Specifically, VP8 uses segment based adjustments to support changing quantizer level and loop filter level for a macroblock. When the segment-based adjustment feature is enabled for a frame, each macroblock within the frame is coded with a `segment_id`. This effectively segments all the macroblocks in the current frame into a number of different segments. Macroblocks within the same segment behave exactly the same for quantizer and loop filter level adjustments.
+Every macroblock may optionally override some of the default behaviors of the decoder. Specifically, VP8 uses segment-based adjustments to support changing quantizer level and loop filter level for a macroblock. When the segment-based adjustment feature is enabled for a frame, each macroblock within the frame is coded with a `segment_id`. This effectively segments all the macroblocks in the current frame into a number of different segments. Macroblocks within the same segment behave exactly the same for quantizer and loop filter level adjustments.
If both the `segmentation_enabled` and `update_mb_segmentation_map` flags in subsection B of the frame header take a value of `1`, the prediction data for each (intra- or inter-coded) macroblock begins with a specification of `segment_id` for the current macroblock. It is decoded using this simple tree ...
diff --git a/text_src/11.01__vp8-bitstream__mbskipcoeff.txt b/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
index 252299e..c7d4d25 100644
--- a/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
+++ b/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
@@ -3,5 +3,5 @@
#### 11.1 mb_skip_coeff {#h-11-01}
-The single bool flag is decoded using `prob_skip_false` if and only if `mb_no_coeff_skip` is set to `1` (see sections 9.10 and 9.11). If `mb_no_coeff_skip` is set to `0` then this value defaults to `0`.
+The single bool flag is decoded using `prob_skip_false` if and only if `mb_no_skip_coeff` is set to `1` (see sections 9.10 and 9.11). If `mb_no_skip_coeff` is set to `0` then this value defaults to `0`.
diff --git a/text_src/11.02__vp8-bitstream__luma-modes.txt b/text_src/11.02__vp8-bitstream__luma-modes.txt
index 68ecdf7..6bff4c3 100644
--- a/text_src/11.02__vp8-bitstream__luma-modes.txt
+++ b/text_src/11.02__vp8-bitstream__luma-modes.txt
@@ -12,7 +12,7 @@
DC_PRED, /* predict DC using row above and column to the left */
V_PRED, /* predict rows using row above */
H_PRED, /* predict columns using column to the left */
- TM_PRED, /* propagate second differences a la "true motion" */
+ TM_PRED, /* propagate second differences a la "True Motion" */
B_PRED, /* each Y subblock is independently predicted */
@@ -55,7 +55,7 @@
B_DC_PRED, /* predict DC using row above and column
to the left */
B_TM_PRED, /* propagate second differences a la
- "true motion" */
+ "True Motion" */
B_VE_PRED, /* predict rows using row above */
B_HE_PRED, /* predict columns using column to the left */
diff --git a/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt b/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
index 136b31d..3ca817f 100644
--- a/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
+++ b/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
@@ -13,7 +13,7 @@
4. Many macroblocks will of course be coded using a 16x16 luma prediction mode. For the purpose of predicting ensuing subblock modes (only), such macroblocks derive a subblock mode, constant throughout the macroblock, from the 16x16 luma mode as follows: `DC_PRED` uses `B_DC_PRED`, `V_PRED` uses `B_VE_PRED`, `H_PRED` uses `B_HE_PRED`, and `TM_PRED` uses `B_TM_PRED`.
- 5. Although we discuss interframe modes later, we remark here that, while interframes do use all the intra-coding modes described here and below, the subblock modes in an interframe are coded using a single constant probability array that does not depend on any context.
+ 5. Although we discuss interframe modes later in Section 16, we remark here that, while interframes do use all the intra-coding modes described here and below, the subblock modes in an interframe are coded using a single constant probability array that does not depend on any context.
The dependence of subblock mode probability on the nearby subblock mode context is most easily handled using a three-dimensional constant array:
diff --git a/text_src/12.01__vp8-bitstream__mbskipcoeff.txt b/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
index 46998ae..066459b 100644
--- a/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
+++ b/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
@@ -3,5 +3,5 @@
#### 12.1 mb_skip_coeff {#h-12-01}
-The single bool flag is decoded using `prob_skip_false` if and only if `mb_no_coeff_skip` is set to `1` (see Sections 9.10 and 9.11). If `mb_no_coeff_skip` is set to `0` then this value defaults to `0`.
+The single bool flag is decoded using `prob_skip_false` if and only if `mb_no_skip_coeff` is set to `1` (see Sections 9.10 and 9.11). If `mb_no_skip_coeff` is set to `0` then this value defaults to `0`.
diff --git a/text_src/12.02__vp8-bitstream__chroma-prediction.txt b/text_src/12.02__vp8-bitstream__chroma-prediction.txt
index 28ee016..237fd9c 100644
--- a/text_src/12.02__vp8-bitstream__chroma-prediction.txt
+++ b/text_src/12.02__vp8-bitstream__chroma-prediction.txt
@@ -15,8 +15,7 @@
Otherwise, if the current macroblock lies on the top row of the frame, the average of the 8 pixels in L is used; if it lies in the left column of the frame, the average of the 8 pixels in A is used. Note that the averages used in these exceptional cases are not the same as those that would be arrived at by using the out-of-bounds A and L values defined for V_PRED and H_PRED. In the case of the leftmost macroblock on the top row of the frame the 8x8 block is simply filled with the constant value `128`.
-For `DC_PRED`, apart from the exceptional case of the top left macroblock,
-we are averaging either 16 or 8 pixel values to get a single prediction value that fills the 8x8 block. The rounding is done as follows:
+For `DC_PRED`, apart from the exceptional case of the top-left macroblock, we are averaging either 16 or 8 pixel values to get a single prediction value that fills the 8x8 block. The rounding is done as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/12.03__vp8-bitstream__luma-prediction.txt b/text_src/12.03__vp8-bitstream__luma-prediction.txt
index 8e3379a..fd82a1f 100644
--- a/text_src/12.03__vp8-bitstream__luma-prediction.txt
+++ b/text_src/12.03__vp8-bitstream__luma-prediction.txt
@@ -49,7 +49,7 @@
Pixel B[4][4], /* Y subblock prediction buffer */
const Pixel *A, /* A[0]...A[7] = above row, A[-1] = P */
const Pixel *L, /* L[0]...L[3] = left column, L[-1] = P */
- intra_bmode mode /* enum is in section 11.1 above */
+ intra_bmode mode /* enum is in section 11.2 above */
) {
Pixel E[9]; /* 9 already-constructed edge pixels */
E[0] = L[3]; E[1] = L[2]; E[2] = L[1]; E[3] = L[0];
@@ -217,5 +217,5 @@
The reference decoder implementation of subblock intra-prediction may be found
-in `reconintra4x4.c`.
+in `predict.c`.
diff --git a/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt b/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
index 11314d8..0c0a35b 100644
--- a/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
+++ b/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
@@ -7,7 +7,7 @@
VP8 works exclusively with 4x4 DCTs and WHTs, applied to the 24 (or 25 with the Y2 subblock) 4x4 subblocks of a macroblock. The ordering of macroblocks within any of the "residue" partitions in general follows the same raster-scan as used in the first "prediction" partition.
-For all intra- and inter-prediction modes apart from `B_PRED` (intra: whose Y subblocks are independently predicted) and `SPLIT_MV` (inter) each macroblock's residue record begins with the Y2 component of the residue, coded using a WHT. `B_PRED` and `SPLIT_MV` coded macroblocks omit this WHT, instead specifying the 0<sup>th</sup> DCT coefficient of each of the 16 Y subblocks as part of its DCT.
+For all intra- and inter-prediction modes apart from `B_PRED` (intra: whose Y subblocks are independently predicted) and `SPLITMV` (inter) each macroblock's residue record begins with the Y2 component of the residue, coded using a WHT. `B_PRED` and `SPLIT_MV` coded macroblocks omit this WHT and specify the 0th DCT coefficient in each of the 16 Y subblocks.
After the optional Y2 block, the residue record continues with 16 DCTs for the Y subblocks, followed by 4 DCTs for the U subblocks, ending with 4 DCTs for the V subblocks. The subblocks occur in the usual order.
diff --git a/text_src/13.01__vp8-bitstream__mb-without-non-zero-coefficient-values.txt b/text_src/13.01__vp8-bitstream__mb-without-non-zero-coefficient-values.txt
index 11caeba..d8b4e47 100644
--- a/text_src/13.01__vp8-bitstream__mb-without-non-zero-coefficient-values.txt
+++ b/text_src/13.01__vp8-bitstream__mb-without-non-zero-coefficient-values.txt
@@ -3,5 +3,5 @@
#### 13.1 MB Without non-Zero Coefficient Values {#h-13-01}
-If the flag within macroblock mode info indicates that a macroblock does not have any non-zero coefficients, the decoding process of DCT coefficients is skipped for the macroblock.
+If the flag within macroblock MODE_INFO indicates that a macroblock does not have any non-zero coefficients, the decoding process of DCT coefficients is skipped for the macroblock.
diff --git a/text_src/13.02__vp8-bitstream__coding-of-individual-coefficient-values.txt b/text_src/13.02__vp8-bitstream__coding-of-individual-coefficient-values.txt
index 6a9cda4..2bbfd90 100644
--- a/text_src/13.02__vp8-bitstream__coding-of-individual-coefficient-values.txt
+++ b/text_src/13.02__vp8-bitstream__coding-of-individual-coefficient-values.txt
@@ -32,7 +32,7 @@
}
dct_token;
-const tree_index coef_tree [2 * (num_dct_tokens - 1)] =
+const tree_index coeff_tree [2 * (num_dct_tokens - 1)] =
{
-dct_eob, 2, /* eob = "0" */
-DCT_0, 4, /* 0 = "10" */
diff --git a/text_src/13.03__vp8-bitstream__token-probabilities.txt b/text_src/13.03__vp8-bitstream__token-probabilities.txt
index da58239..3c340a0 100644
--- a/text_src/13.03__vp8-bitstream__token-probabilities.txt
+++ b/text_src/13.03__vp8-bitstream__token-probabilities.txt
@@ -7,7 +7,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Prob coef_probs [4] [8] [3] [num_dct_tokens-1];
+Prob coeff_probs [4] [8] [3] [num_dct_tokens-1];
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
@@ -23,7 +23,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-coef_bands [c]
+coeff_bands [c]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
@@ -32,7 +32,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-const int coef_bands [16] = {
+const int coeff_bands [16] = {
0, 1, 2, 3, 6, 4, 5, 6, 6, 6, 6, 6, 6, 6, 6, 7
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -57,7 +57,7 @@
The fourth, and final, dimension of the token probability array is of course indexed by (half) the position in the token tree structure, as are all tree probability arrays.
-The below pseudo-code illustrates the decoding process. Note that criteria, functions, etc. delimited with `**` are either dependent on decoder architecture or are elaborated on elsewhere in this document.
+The below pseudocode illustrates the decoding process. Note that criteria, functions, etc. delimited with `**` are either dependent on decoder architecture or are elaborated on elsewhere in this document.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -98,15 +98,15 @@
for( i = firstCoeff ; i < 16 ; ++i )
{
- ctx2 = coef_bands[i];
- probTable = coef_probs[plane][ctx2][ctx3];
+ ctx2 = coeff_bands[i];
+ probTable = coeff_probs[plane][ctx2][ctx3];
/* skip first code (dct_eob) if previous token was DCT_0 */
if( prevCoeffWasZero )
- token = treed_read ( d, **coef_tree_without_eob**,
+ token = treed_read ( d, **coeff_tree_without_eob**,
probTable );
else
- token = treed_read ( d, coef_tree, probTable );
+ token = treed_read ( d, coeff_tree, probTable );
if( token == dct_eob )
break;
@@ -148,5 +148,5 @@
{:lang="c"}
-While we have in fact completely described the coefficient decoding procedure, the reader will probably find it helpful to consult the reference implementation, which can be found in the file `detokenize.c`.
+While we have in fact completely described the coefficient decoding procedure, the reader will probably find it helpful to consult the reference implementation, which can be found in the file `tokens.c`.
diff --git a/text_src/13.04__vp8-bitstream__token-probability-updates.txt b/text_src/13.04__vp8-bitstream__token-probability-updates.txt
index c7e7318..38edbd8 100644
--- a/text_src/13.04__vp8-bitstream__token-probability-updates.txt
+++ b/text_src/13.04__vp8-bitstream__token-probability-updates.txt
@@ -5,7 +5,7 @@
As mentioned above, the token-decoding probabilities may change from frame to frame. After detection of a key frame, they are of course set to their defaults shown in Section 13.5; this must occur before decoding the remainder of the header, as both key frames and interframes may adjust these probabilities.
-The layout and semantics of the coefficient probability update record (Section I of the frame header) are straightforward. For each position in the `coef_probs` array there occurs a fixed-probability bool indicating whether or not the corresponding probability should be updated. If the bool is true, there follows a `P(8)` replacing that probability. Note that updates are cumulative, that is, a probability updated on one frame is in effect for all ensuing frames until the next key frame, or until the probability is explicitly updated by another frame.
+The layout and semantics of the coefficient probability update record (Section I of the frame header) are straightforward. For each position in the `coeff_probs` array there occurs a fixed-probability bool indicating whether or not the corresponding probability should be updated. If the bool is true, there follows a `P(8)` replacing that probability. Note that updates are cumulative, that is, a probability updated on one frame is in effect for all ensuing frames until the next key frame, or until the probability is explicitly updated by another frame.
The algorithm to effect the foregoing is simple:
@@ -16,8 +16,8 @@
int k = 0; do {
int t = 0; do {
- if( read_bool( d, coef_update_probs [i] [j] [k] [t]))
- coef_probs [i] [j] [k] [t] = read_literal( d, 8);
+ if( read_bool( d, coeff_update_probs [i] [j] [k] [t]))
+ coeff_probs [i] [j] [k] [t] = read_literal( d, 8);
} while( ++t < num_dct_tokens - 1);
} while( ++k < 3);
@@ -31,7 +31,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-const Prob coef_update_probs [4] [8] [3] [num_dct_tokens-1] =
+const Prob coeff_update_probs [4] [8] [3] [num_dct_tokens-1] =
{
{
{
diff --git a/text_src/13.05__vp8-bitstream__default-token-probability-table.txt b/text_src/13.05__vp8-bitstream__default-token-probability-table.txt
index 91ea983..58cbbf0 100644
--- a/text_src/13.05__vp8-bitstream__default-token-probability-table.txt
+++ b/text_src/13.05__vp8-bitstream__default-token-probability-table.txt
@@ -7,7 +7,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-const Prob default_coef_probs [4] [8] [3] [num_dct_tokens - 1] =
+const Prob default_coeff_probs [4] [8] [3] [num_dct_tokens - 1] =
{
{
{
diff --git a/text_src/14.01__vp8-bitstream__dequantization.txt b/text_src/14.01__vp8-bitstream__dequantization.txt
index 9377535..7952d1b 100644
--- a/text_src/14.01__vp8-bitstream__dequantization.txt
+++ b/text_src/14.01__vp8-bitstream__dequantization.txt
@@ -3,7 +3,7 @@
#### 14.1 Dequantization {#h-14-01}
-After decoding the DCTs/WHTs as described above, each (quantized) coefficient in each subblock is multiplied by one of six dequantization factors, the choice of factor depending on the plane (Y2, Y, or chroma) and position (DC = coefficient zero, AC = any other coefficient). If the current macroblock has overridden the quantization level (as described in Chapter 10) then the six factors are looked up from two dequantization tables with appropriate scaling and clamping using the single index supplied by the override. Otherwise, the frame-level dequantization factors (as described in Section 9.6) are used. In either case, the multiplies are computed and stored using 16-bit signed integers.
+After decoding the DCTs/WHTs as described above, each (quantized) coefficient in each subblock is multiplied by one of six dequantization factors, the choice of factor depending on the plane (Y2, Y, or chroma) and position (DC = coefficient zero, AC = any other coefficient). If the current macroblock has overridden the quantizer level (as described in Chapter 10) then the six factors are looked up from two dequantization tables with appropriate scaling and clamping using the single index supplied by the override. Otherwise, the frame-level dequantization factors (as described in Section 9.6) are used. In either case, the multiplies are computed and stored using 16-bit signed integers.
The two dequantization tables, which may also be found in the reference decoder file `dequant_data.h`, are as follows.
diff --git a/text_src/14.03__vp8-bitstream__implementation-of-wht-inversion.txt b/text_src/14.03__vp8-bitstream__implementation-of-wht-inversion.txt
index 0b9465b..f127926 100644
--- a/text_src/14.03__vp8-bitstream__implementation-of-wht-inversion.txt
+++ b/text_src/14.03__vp8-bitstream__implementation-of-wht-inversion.txt
@@ -90,5 +90,5 @@
It should be noted, a conforming decoder should implement the inverse transform using exactly the same rounding to achieve bit-wise matching output to the output of the process specified by the above "C" source code.
-The reference decoder WHT inversion may be found in the files `invtrans.c` and `idctllm.c`.
+The reference decoder WHT inversion may be found in the file `idct_add.c`.
diff --git a/text_src/14.04__vp8-bitstream__implementation-of-dct-inversion.txt b/text_src/14.04__vp8-bitstream__implementation-of-dct-inversion.txt
index d00ca9b..dfeaada 100644
--- a/text_src/14.04__vp8-bitstream__implementation-of-dct-inversion.txt
+++ b/text_src/14.04__vp8-bitstream__implementation-of-dct-inversion.txt
@@ -87,5 +87,5 @@
{:lang="c"}
-The reference decoder DCT inversion may be found in the files `invtrans.c` and `idctllm.c`.
+The reference decoder DCT inversion may be found in the file `idct_add.c`.
diff --git a/text_src/14.05__vp8-bitstream__summation-of-predictor-and-residue.txt b/text_src/14.05__vp8-bitstream__summation-of-predictor-and-residue.txt
index 71b2e32..8fe75b1 100644
--- a/text_src/14.05__vp8-bitstream__summation-of-predictor-and-residue.txt
+++ b/text_src/14.05__vp8-bitstream__summation-of-predictor-and-residue.txt
@@ -9,5 +9,5 @@
VP8 also supports a mode where the encoding of a bitstream guarantees all reconstructed pixel values between 0 and 255, compliant bitstreams of such requirements have the `clamp_type` bit in the frame header set to 1. In such case, the `clamp255` is no longer required.
-The summation process is the same, regardless of the (intra or inter) mode of prediction in effect for the macroblock. The reference decoder implementation of reconstruction may be found in the file `recon.c`.
+The summation process is the same, regardless of the (intra or inter) mode of prediction in effect for the macroblock. The reference decoder implementation of reconstruction may be found in the file `idct_add.c`.
diff --git a/text_src/15.02__vp8-bitstream__simple-filter.txt b/text_src/15.02__vp8-bitstream__simple-filter.txt
index a06c72e..069ea78 100644
--- a/text_src/15.02__vp8-bitstream__simple-filter.txt
+++ b/text_src/15.02__vp8-bitstream__simple-filter.txt
@@ -7,7 +7,7 @@
Note that the simple filter only applies to luma edges. Chroma edges are left unfiltered.
-Roughly speaking, the idea of loop filtering is, within limits, to reduce the difference between pixels straddling an edge. Differences in excess of a threshold (associated to the `loop_filter_level`) are assumed to be "natural" and are unmodified; differences below the threshold are assumed to be artifacts of quantization and the (partially) separate coding of blocks, and are reduced via the procedures described below. While the `loop_filter_level` is in principle arbitrary, the levels chosen by a VP8 compressor tend to be correlated to quantization levels.
+Roughly speaking, the idea of loop filtering is, within limits, to reduce the difference between pixels straddling an edge. Differences in excess of a threshold (associated to the `loop_filter_level`) are assumed to be "natural" and are unmodified; differences below the threshold are assumed to be artifacts of quantization and the (partially) separate coding of blocks, and are reduced via the procedures described below. While the `loop_filter_level` is in principle arbitrary, the levels chosen by a VP8 compressor tend to be correlated to quantizer levels.
Most of the filtering arithmetic is done using 8-bit signed operands (having a range -128 to +127, inclusive), supplemented by 16-bit temporaries holding results of multiplies.
@@ -46,7 +46,7 @@
{:lang="c"}
-An actual implementation would of course use inline functions or macros to accomplish these trivial procedures (which are used by both the normal and simple loop filters). An optimal implementation would probably express them in machine language, perhaps using SIMD vector instructions. On many SIMD processors, the saturation accomplished by the above clamping function is often folded into the arithmetic instructions themselves, obviating the explicit step taken here.
+An actual implementation would of course use inline functions or macros to accomplish these trivial procedures (which are used by both the normal and simple loop filters). An optimal implementation would probably express them in machine language, perhaps using single instruction, multiple data (SIMD) vector instructions. On many SIMD processors, the saturation accomplished by the above clamping function is often folded into the arithmetic instructions themselves, obviating the explicit step taken here.
To simplify the specification of relative pixel positions, we use the word before to mean "immediately above" (for a vertical segment straddling a horizontal edge) or "immediately to the left of" (for a horizontal segment straddling a vertical edge) and the word after to mean "immediately below" or "immediately to the right of".
diff --git a/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt b/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
index e402749..2149a84 100644
--- a/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
+++ b/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
@@ -22,7 +22,7 @@
{:lang="c"}
-The probability table used to decode this tree is variable. As described in [Chapter 9](#h-09-00), it (along with the similarly-treated UV table) can be updated by field J of the frame header. Similar to the coefficient-decoding probabilities, such updates are cumulative and affect all ensuing frames until the next key frame or explicit update. The default probabilities for the Y and UV tables are
+The probability table used to decode this tree is variable. As described in [Chapter 11](#h-11-00), it (along with the similarly-treated UV table) can be updated by field J of the frame header. Similar to the coefficient-decoding probabilities, such updates are cumulative and affect all ensuing frames until the next key frame or explicit update. The default probabilities for the Y and UV tables are
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt b/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
index 7433386..13c8316 100644
--- a/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
+++ b/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
@@ -7,7 +7,7 @@
The next datum is then another bool, `B( prob_last)`, selecting the reference frame. If 0, the reference frame is previous frame (last frame); if 1, another bool (`prob_gf`) selects the reference frame between golden frame (0) or altref frame (1). The probabilities `prob_last` and `prob_gf` are set in field J of the frame header.
-Together with setting the reference frame, the purpose of inter-mode decoding is to set a motion vector for each of the sixteen Y subblocks of the current macroblock. This then defines the calculation of the inter-prediction buffer (detailed in Chapter 18). While the net effect of inter-mode decoding is straightforward, the implementation is somewhat complex; the (lossless) compression achieved by this method justifies the complexity.
+Together with setting the reference frame, the purpose of inter-mode decoding is to set a motion vector for each of the sixteen Y subblocks of the current macroblock. These settings then define the calculation of the inter-prediction buffer (detailed in Chapter 18). While the net effect of inter-mode decoding is straightforward, the implementation is somewhat complex; the (lossless) compression achieved by this method justifies the complexity.
After the reference frame selector comes the mode (or motion vector reference) applied to the macroblock as a whole, coded using the following enumeration and tree. Setting `mv_nearest = num_ymodes` is a convenience that allows a single variable to unambiguously hold an inter- or intraprediction mode.
diff --git a/text_src/16.03__vp8-bitstream__mode-and-motion-vector-contexts.txt b/text_src/16.03__vp8-bitstream__mode-and-motion-vector-contexts.txt
index b5afe71..49362ae 100644
--- a/text_src/16.03__vp8-bitstream__mode-and-motion-vector-contexts.txt
+++ b/text_src/16.03__vp8-bitstream__mode-and-motion-vector-contexts.txt
@@ -5,7 +5,7 @@
The probability table used to decode the `mv_ref`, along with three reference motion vectors used by the selected mode, is calculated via a survey of the already-decoded motion vectors in (up to) 3 nearby macroblocks.
-The algorithm generates a sorted list of distinct motion vectors adjacent to the search site. The `best_mv` is the vector with the highest score. The `nearest_mv` is the non-zero vector with the highest score. The `near_mv` is the non-zero vector with the next highest score. The number of motion vectors coded using the `SPLITMV` mode is scored using the same weighting and is returned with the scores of the best, nearest, and near vectors.
+The algorithm generates a sorted list of distinct motion vectors adjacent to the search site. The `best_mv` is the vector with the highest score. The `mv_nearest` is the non-zero vector with the highest score. The `mv_near` is the non-zero vector with the next highest score. The number of motion vectors coded using the `SPLITMV` mode is scored using the same weighting and is returned with the scores of the best, nearest, and near vectors.
The three adjacent macroblocks above, left, and above-left are considered in order. If the macroblock is intra-coded, no action is taken. Otherwise, the motion vector is compared to other previously found motion vectors to determine if it has been seen before, and if so contributes its weight to that vector, otherwise enters a new vector in the list. The above and left vectors have twice the weight of the above-left vector.
@@ -60,7 +60,7 @@
The vector `best_mv` is used as a base for explicitly-coded motion vectors.
-The first three entries in the return value `cnt` are (in order) weighted census values for "zero", "nearest", and "near" vectors. The final value indicates the extent to which `SPLIT_MV` was used by the neighboring macroblocks. The largest possible "weight" value in each case is 5.
+The first three entries in the return value `cnt` are (in order) weighted census values for "zero", "nearest", and "near" vectors. The final value indicates the extent to which `SPLITMV` was used by the neighboring macroblocks. The largest possible "weight" value in each case is 5.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/18.01__vp8-bitstream__bounds-on-and-adjustment-of-motion-vectors.txt b/text_src/18.01__vp8-bitstream__bounds-on-and-adjustment-of-motion-vectors.txt
index 127e7d8..b68f24c 100644
--- a/text_src/18.01__vp8-bitstream__bounds-on-and-adjustment-of-motion-vectors.txt
+++ b/text_src/18.01__vp8-bitstream__bounds-on-and-adjustment-of-motion-vectors.txt
@@ -28,7 +28,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-Furthermore, if the version number in the frame tag specifies only full-pel chroma motion vectors, then the fractional parts of both components of the vector are truncated to zero, as illustrated in the following pseudo-code (assuming 3 bits of fraction for both luma and chroma vectors):
+Furthermore, if the version number in the frame tag specifies only full-pel chroma motion vectors, then the fractional parts of both components of the vector are truncated to zero, as illustrated in the following pseudocode (assuming 3 bits of fraction for both luma and chroma vectors):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -38,7 +38,7 @@
{:lang="c"}
-Earlier in this document we described the `vp8_clamp_mv()` function to limit "nearest" and "near" motion vector predictors inside specified margins within the frame boundaries. Additional clamping is performed for `NEW_MV` macroblocks, for which the final motion vector is clamped again after combining the "best" predictor and the differential vector decoded from the stream.
+Earlier in this document we described the `vp8_clamp_mv()` function to limit "nearest" and "near" motion vector predictors inside specified margins within the frame boundaries. Additional clamping is performed for `NEWMV` macroblocks, for which the final motion vector is clamped again after combining the "best" predictor and the differential vector decoded from the stream.
-However, the secondary clamping is not performed for `SPLIT_MV` macroblocks, meaning that any subblock's motion vector within the `SPLIT_MV` macroblock may point outside the clamping zone. These non-clamped vectors are also used when determining the decoding tree context for subsequent subblocks' modes in the `vp8_mvCont()` function.
+However, the secondary clamping is not performed for `SPLITMV` macroblocks, meaning that any subblock's motion vector within the `SPLITMV` macroblock may point outside the clamping zone. These non-clamped vectors are also used when determining the decoding tree context for subsequent subblocks' modes in the `vp8_mvCont()` function.
diff --git a/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt b/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
index 98f7701..0635a08 100644
--- a/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
+++ b/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
@@ -13,7 +13,7 @@
The two interpolations are essentially identical. Each uses an (at most) six-tap filter (the choice of which of course depends on the one-dimensional offset). Thus, every calculated pixel references at most three pixels before (above or to-the-left of) it and at most three pixels after (below or to-the-right of) it. The horizontal interpolation must calculate two extra rows above and three extra rows below the 4x4 block, to provide enough samples for the vertical interpolation to proceed.
-Depending on the reconstruction filter type given in the field `Version Number` in the frame tag, either a bicubic or a bilinear tap set is used.
+Depending on the reconstruction filter type given in the field `version number` in the frame tag, either a bicubic or a bilinear tap set is used.
The exact implementation of subsampling is as follows.
diff --git a/text_src/18.04__vp8-bitstream__filter-properties.txt b/text_src/18.04__vp8-bitstream__filter-properties.txt
index e644416..d7dea60 100644
--- a/text_src/18.04__vp8-bitstream__filter-properties.txt
+++ b/text_src/18.04__vp8-bitstream__filter-properties.txt
@@ -7,7 +7,7 @@
All digital signals are of course sampled in some fashion. The case where the inter-sample spacing (say in time for audio samples, or space for pixels) is uniform, that is, the same at all positions, is particularly common and amenable to analysis. Many aspects of the treatment of such signals are best-understood in the frequency domain via Fourier Analysis, particularly those aspects of the signal that are not changed by shifts in position, especially when those positional shifts are not given by a whole number of samples.
-Non-integral translates of a sampled signal are a textbook example of the foregoing. In our case of non-integral motion vectors, we wish to say what the underlying image "really is" at these pixels we don't have values for but feel that it makes sense to talk about. The correctness of this feeling is predicated on the underlying signal being band-limited, that is, not containing any energy in spatial frequencies that cannot be faithfully rendered at the pixel resolution at our disposal. In one dimension, this range of "OK" frequencies is called the Nyquist band; in our two-dimensional case of integer-grid samples, this range might be termed a Nyquist rectangle. The finer the grid, the more we know about the image, and the wider the Nyquist rectangle.
+Non-integral translates of a sampled signal are a textbook example of the foregoing. In our case of non-integral motion vectors, we wish to say what the underlying image "really is" at these pixels; although we don't have values for them, we feel that it makes sense to talk about them. The correctness of this feeling is predicated on the underlying signal being band-limited, that is, not containing any energy in spatial frequencies that cannot be faithfully rendered at the pixel resolution at our disposal. In one dimension, this range of "OK" frequencies is called the Nyquist band; in our two-dimensional case of integer-grid samples, this range might be termed a Nyquist rectangle. The finer the grid, the more we know about the image, and the wider the Nyquist rectangle.
It turns out that, for such band-limited signals, there is indeed an exact mathematical formula to produce the correct sample value at an arbitrary point. Unfortunately, this calculation requires the consideration of every single sample in the image, as well as needing to operate at infinite precision. Also, strictly speaking, all band-limited signals have infinite spatial (or temporal) extent, so everything we are discussing is really some sort of approximation.
@@ -15,7 +15,7 @@
Another basic fact about approximations to "truly correct" subsampling is that, the wider the subrectangle (within the Nyquist rectangle) of spatial frequencies one wishes to "pass" (that is, correctly render) or, put more accurately, the closer one wishes to approximate the ideal transfer function, the more samples of the original signal must be considered by the subsampling, and the wider the calculation precision necessitated.
-The filters chosen by VP8 were chosen, within the constraints of 4 or 6 taps and 7-bit precision, to do the best possible job of handling the low spatial frequencies near the zero<sup>th</sup> DC frequency along with introducing no resonances (places where the absolute value of the frequency response exceeds one).
+The filters chosen by VP8 were chosen, within the constraints of 4 or 6 taps and 7-bit precision, to do the best possible job of handling the low spatial frequencies near the 0th DC frequency along with introducing no resonances (places where the absolute value of the frequency response exceeds one).
The justification for the foregoing has two parts. First, resonances can produce extremely objectionable visible artifacts when, as often happens in actual compressed video streams, filters are applied repeatedly. Second, the vast majority of energy in real-world images lies near DC and not at the high-end.
diff --git a/text_src/20.00__vp8-bitstream__references.txt b/text_src/20.00__vp8-bitstream__references.txt
deleted file mode 100644
index 9d8023e..0000000
--- a/text_src/20.00__vp8-bitstream__references.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-
-
-### Chapter 20: References {#h-20-00}
-
-
- 1. "ITU BT.601: Studio encoding parameters of digital television
- for standard 4:3 and wide screen 16:9 aspect ratios",
- International Telecommunication Union, Jan, 2007
- 2. _Text Compression_ by Timothy C. Bell, John G. Cleary and Ian H.
- Witten, Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1990
- 3. _The C Programming Language (2nd edition)_ by Brian Kernighan
- and Dennis Ritchie, Prentice Hall, Englewood Cliffs, NJ, USA,
- 1988
- 4. _Practical Fast 1-D DCT Algorithms with 11 Multiplications_ by
- Christoph Loeffler, Adriaan Ligtenberg and George S. Moschytz,
- Proceedings of the International Conference on Acoustics, Speech,
- and Signal Processing, 1989
- 5. "A Mathematical Theory of Communication" by C.E. Shannon, _Bell
- System Technical Journal_, vol. 27, pp. 379-423, 623-656, July,
- October, 1948
-
diff --git a/text_src/a.01_vp8-bitstream__frame_tag.txt b/text_src/a.01_vp8-bitstream__frame_tag.txt
index dd8aaa6..157ce28 100644
--- a/text_src/a.01_vp8-bitstream__frame_tag.txt
+++ b/text_src/a.01_vp8-bitstream__frame_tag.txt
@@ -18,7 +18,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-unsigned char *c = pbi->Source;
+unsigned char *c = pbi->source;
unsigned int tmp;
tmp = (c[2] << 16) | (c[1] << 8) | c[0];
@@ -47,7 +47,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-unsigned char *c = pbi->Source + 6;
+unsigned char *c = pbi->source + 6;
unsigned int tmp;
tmp = (c[1] << 8) | c[0];
diff --git a/text_src/a.02_vp8-bitstream__frame_header.txt b/text_src/a.02_vp8-bitstream__frame_header.txt
index d0d1693..67a4480 100644
--- a/text_src/a.02_vp8-bitstream__frame_header.txt
+++ b/text_src/a.02_vp8-bitstream__frame_header.txt
@@ -34,7 +34,7 @@
| ` refresh_last` | L(1) |
| `}` | |
| `token_prob_update()` | |
-| `mb_no_coeff_skip` | L(1) |
+| `mb_no_skip_coeff` | L(1) |
{:.col1-pre}
@@ -44,7 +44,7 @@
| `if (!key_frame) {` | |
| ` prob_intra` | L(8) |
| ` prob_last` | L(8) |
-| ` prob_golden` | L(8) |
+| ` prob_gf` | L(8) |
| ` intra_16x16_prob_update_flag` | L(1) |
| ` if (intra_16x16_prob_update_flag) {` | |
| ` for (i = 0; i < 4; i++)` | |
@@ -75,11 +75,11 @@
* `sign_bias_golden` controls the sign of motion vectors when the golden frame is referenced ([9.7](#h-09-07))
* `sign_bias_alternate` controls the sign of motion vectors when the alternate frame is referenced ([9.7](#h-09-07))
* `refresh_last` determines if the current decoded frame refreshes the last frame reference buffer ([9.8](#h-09-08))
- * `mb_no_coeff_skip` enables or disables the skipping of macroblocks containing no non-zero coefficients ([9.10](#h-09-10))
+ * `mb_no_skip_coeff` enables or disables the skipping of macroblocks containing no non-zero coefficients ([9.10](#h-09-10))
* `prob_skip_false` the probability that the macroblock is not skipped (flag indicating skipped macroblock is false) ([9.10](#h-09-10))
* `prob_intra` the probability of an intra macroblock ([9.10](#h-09-10))
* `prob_last` the probability that the last reference frame is used for inter prediction ([9.10](#h-09-10))
- * `prob_golden` the probability that the golden reference frame is used for inter prediction ([9.10](#h-09-10))
+ * `prob_gf` the probability that the golden reference frame is used for inter prediction ([9.10](#h-09-10))
* `intra_16x16_prob_update_flag` indicates if the branch probabilies used in the decoding of luma intra prediction mode are updated ([9.10](#h-09-10))
* `intra_16x16_prob` the branch probabilities of the luma intra prediction mode decoding tree
* `intra_chroma_prob_update_flag` indicates if the branch probabilies used in the decoding of chroma intra prediction mode are updated ([9.10](#h-09-10))
diff --git a/text_src/a.03_vp8-bitstream__mb_header.txt b/text_src/a.03_vp8-bitstream__mb_header.txt
index c7df363..994aea5 100644
--- a/text_src/a.03_vp8-bitstream__mb_header.txt
+++ b/text_src/a.03_vp8-bitstream__mb_header.txt
@@ -14,8 +14,8 @@
|------------------------ ----------------------|-------|
| `if (segmentation_map_update) {` | |
| ` segment_id` | T |
-| `if (mb_no_coeff_skip) {` | |
-| ` mb_coeff_skip` | B(p) |
+| `if (mb_no_skip_coeff) {` | |
+| ` mb_skip_coeff` | B(p) |
| `}` | |
| `if (!key_frame) {` | |
| ` is_inter_mb` | B(p) |
@@ -54,7 +54,7 @@
* `segment_id` indicates to which segment the macroblock belongs ([10](#h-10-00))
- * `mb_coeff_skip` indicates if the macroblock contains any coded coefficients or not ([11.1](#h-11-01))
+ * `mb_skip_coeff` indicates if the macroblock contains any coded coefficients or not ([11.1](#h-11-01))
* `is_inter_mb` indicates if the macroblock is intra or inter coded ([16](#h-16-00))
* `mb_ref_frame_sel1` selects the reference frame to be used; last frame (0), golden/alternate (1) ([16.2](#h-16-02))
* `mb_ref_frame_sel2` selects whether the golden (0) or alternate reference frame (1) is used ([16.2](#h-16-02))
@@ -68,7 +68,7 @@
| residual_data() | Type |
| ----------------------------------------------------- | ----- |
-| `if (!mb_coeff_skip) {` | |
+| `if (!mb_skip_coeff) {` | |
| ` if ( (is_inter_mb && mv_mode != SPLITMV) \|\|` | |
| ` (!is_inter_mb && intra_y_mode != B_PRED) ) {` | |
| ` residual_block() /* Y2 */` | |
diff --git a/text_src/atch1/dixie.c b/text_src/atch1/dixie.c
index f68fb59..883f7fb 100644
--- a/text_src/atch1/dixie.c
+++ b/text_src/atch1/dixie.c
@@ -37,8 +37,8 @@
/* Read coefficient probability updates */
for (i = 0; i < BLOCK_TYPES; i++)
- for (j = 0; j < COEF_BANDS; j++)
- for (k = 0; k < PREV_COEF_CONTEXTS; k++)
+ for (j = 0; j < COEFF_BANDS; j++)
+ for (k = 0; k < PREV_COEFF_CONTEXTS; k++)
for (l = 0; l < ENTROPY_NODES; l++)
if (bool_get(bool,
k_coeff_entropy_update_probs
diff --git a/text_src/atch1/dixie.h b/text_src/atch1/dixie.h
index 05e6be2..84a75a5 100644
--- a/text_src/atch1/dixie.h
+++ b/text_src/atch1/dixie.h
@@ -108,13 +108,13 @@
enum
{
- BLOCK_TYPES = 4,
- PREV_COEF_CONTEXTS = 3,
- COEF_BANDS = 8,
- ENTROPY_NODES = 11,
+ BLOCK_TYPES = 4,
+ PREV_COEFF_CONTEXTS = 3,
+ COEFF_BANDS = 8,
+ ENTROPY_NODES = 11,
};
-typedef unsigned char coeff_probs_table_t[BLOCK_TYPES][COEF_BANDS]
-[PREV_COEF_CONTEXTS]
+typedef unsigned char coeff_probs_table_t[BLOCK_TYPES][COEFF_BANDS]
+[PREV_COEFF_CONTEXTS]
[ENTROPY_NODES];
diff --git a/text_src/atch1/predict.c b/text_src/atch1/predict.c
index b056ff8..6294a90 100644
--- a/text_src/atch1/predict.c
+++ b/text_src/atch1/predict.c
@@ -1421,7 +1421,7 @@
if (col == ctx->mb_cols)
{
- /* Extend the last row by four pixels for intra prediction.
+ /* Extend the last row by four pixels for intra-prediction.
* This will be propagated later by copy_down.
*/
uint32_t *extend = (uint32_t *)(img.y + 15 * img.stride);
diff --git a/text_src/atch1/tokens.c b/text_src/atch1/tokens.c
index eb00523..414de09 100644
--- a/text_src/atch1/tokens.c
+++ b/text_src/atch1/tokens.c
@@ -61,7 +61,7 @@
0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3,
4, 5, 4, 5, 6, 7, 6, 7, 8
};
-#define X(n) ((n) * PREV_COEF_CONTEXTS * ENTROPY_NODES)
+#define X(n) ((n) * PREV_COEFF_CONTEXTS * ENTROPY_NODES)
static const unsigned int bands_x[16] =
{
X(0), X(1), X(2), X(3), X(6), X(4), X(5), X(6),
diff --git a/text_src/atch1/vp8_prob_data.h b/text_src/atch1/vp8_prob_data.h
index 1e4cccb..f4256ec 100644
--- a/text_src/atch1/vp8_prob_data.h
+++ b/text_src/atch1/vp8_prob_data.h
@@ -1,6 +1,6 @@
static const
-unsigned char k_coeff_entropy_update_probs[BLOCK_TYPES][COEF_BANDS]
-[PREV_COEF_CONTEXTS]
+unsigned char k_coeff_entropy_update_probs[BLOCK_TYPES][COEFF_BANDS]
+[PREV_COEFF_CONTEXTS]
[ENTROPY_NODES] =
{
{
@@ -185,8 +185,8 @@
static const
-unsigned char k_default_coeff_probs [BLOCK_TYPES][COEF_BANDS]
-[PREV_COEF_CONTEXTS][ENTROPY_NODES] =
+unsigned char k_default_coeff_probs [BLOCK_TYPES][COEFF_BANDS]
+[PREV_COEFF_CONTEXTS][ENTROPY_NODES] =
{
{ /* block type 0 */
{ /* coeff band 0 */
diff --git a/text_src/atch1/vpx_codec_internal.h b/text_src/atch1/vpx_codec_internal.h
index 8e990a0..9e991c5 100644
--- a/text_src/atch1/vpx_codec_internal.h
+++ b/text_src/atch1/vpx_codec_internal.h
@@ -229,7 +229,7 @@
vpx_codec_iter_t *iter);
-/*\brief e_xternal Memory Allocation memory map get iterator
+/*\brief External Memory Allocation memory map get iterator
*
* Iterates over a list of the memory maps requested by the decoder.
* The iterator storage should be initialized to NULL to start the
@@ -246,7 +246,7 @@
vpx_codec_iter_t *iter);
-/*\brief e_xternal Memory Allocation memory map set iterator
+/*\brief External Memory Allocation memory map set iterator
*
* Sets a memory descriptor inside the decoder instance.
*
@@ -303,7 +303,7 @@
#define NOT_IMPLEMENTED 0
-/*!\brief Decoder algorithm interface interface
+/*!\brief Decoder algorithm interface
*
* All decoders \ref MUST expose a variable of this type.
*/
@@ -370,7 +370,6 @@
} dec;
struct
{
- int tbd;
struct vpx_fixed_buf cx_data_dst_buf;
unsigned int cx_data_pad_before;
unsigned int cx_data_pad_after;
@@ -415,7 +414,7 @@
/* Internal Utility Functions
*
- * The following functions are indended to be used inside algorithms
+ * The following functions are intended to be used inside algorithms
* as utilities for manipulating vpx_codec_* data structures.
*/
struct vpx_codec_pkt_list
diff --git a/text_src/atch1/vpx_decoder_compat.h b/text_src/atch1/vpx_decoder_compat.h
index 3563697..79c5a29 100644
--- a/text_src/atch1/vpx_decoder_compat.h
+++ b/text_src/atch1/vpx_decoder_compat.h
@@ -467,7 +467,7 @@
*
* This callback is invoked by the decoder to notify the
* application of the availability of partially decoded image
- * data. The
+ * data.
*/
typedef void (*vpx_dec_put_slice_cb_fn_t)(void *user_priv,
const vpx_image_t *img,
diff --git a/text_src/atch1/vpx_image.h b/text_src/atch1/vpx_image.h
index 80e0499..d61617d 100644
--- a/text_src/atch1/vpx_image.h
+++ b/text_src/atch1/vpx_image.h
@@ -154,7 +154,7 @@
#define PLANE_V VPX_PLANE_V
#define PLANE_ALPHA VPX_PLANE_ALPHA
#endif
- unsigned char *planes[4]; /**< pointer to the top left pixel
+ unsigned char *planes[4]; /**< pointer to the top-left pixel
q for each plane */
int stride[4]; /**< stride between rows for each plane */
