Sync to published RFC 6386 text.
Change-Id: I9f4b56c11e882fc4f37bdbae65a55cfa8f63312d
diff --git a/text_src/00.05__vp8-bitstream__license.txt b/text_src/00.05__vp8-bitstream__license.txt
index 8d90f1e..456761c 100644
--- a/text_src/00.05__vp8-bitstream__license.txt
+++ b/text_src/00.05__vp8-bitstream__license.txt
@@ -1,7 +1,26 @@
-### Patent License {#h-00-05}
+### Patent License {#h-00-05}
-"This implementation" means the copyrightable works distributed by Google as part of the WebM Project.
+"This implementation" means the copyrightable works distributed by
+Google as part of the WebM Project.
-Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8. This grant does not include claims that would be infringed only as a consequence of further modification of this implementation. If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.
\ No newline at end of file
+Google hereby grants to you a perpetual, worldwide, non-exclusive,
+no-charge, royalty-free, irrevocable (except as stated in this
+section) patent license to make, have made, use, offer to sell, sell,
+import, transfer, and otherwise run, modify and propagate the
+contents of this implementation of VP8, where such license applies
+only to those patent claims, both currently owned by Google and
+acquired in the future, licensable by Google that are necessarily
+infringed by this implementation of VP8. This grant does not include
+claims that would be infringed only as a consequence of further
+modification of this implementation. If you or your agent or
+exclusive licensee institute or order or agree to the institution of
+patent litigation against any entity (including a cross-claim or
+counterclaim in a lawsuit) alleging that this implementation of VP8
+or any code incorporated within this implementation of VP8
+constitutes direct or contributory patent infringement, or inducement
+of patent infringement, then any patent rights granted to you under
+this License for this implementation of VP8 shall terminate as of the
+date such litigation is filed.
+
diff --git a/text_src/00.06__vp8-bitstream__copyright.txt b/text_src/00.06__vp8-bitstream__copyright.txt
index 0ff5bdd..e2d362c 100644
--- a/text_src/00.06__vp8-bitstream__copyright.txt
+++ b/text_src/00.06__vp8-bitstream__copyright.txt
@@ -1,8 +1,9 @@
-### Copyright {#h-00-06}
+### Copyright {#h-00-06}
-*This specification is made available under a [Creative Commons Attribution 3.0 License][1].*
+*This specification is made available under a [Creative Commons
+Attribution 3.0 License][1].*
[1]: http://creativecommons.org/licenses/by/3.0/
diff --git a/text_src/01.00__vp8-bitstream__introduction.txt b/text_src/01.00__vp8-bitstream__introduction.txt
index b283101..3bca36c 100644
--- a/text_src/01.00__vp8-bitstream__introduction.txt
+++ b/text_src/01.00__vp8-bitstream__introduction.txt
@@ -1,18 +1,59 @@
-### Chapter 1: Introduction {#h-01-00}
+### Section 1: Introduction {#h-01-00}
-This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. It is intended to be used in conjunction with and as a guide to the reference decoder source code provided in Attachment One. If there are any conflicts between this narrative and the reference source code, the reference source code should be considered correct. The bitstream is defined by the reference source code and not this narrative.
+This document describes the VP8 compressed video data format,
+together with a discussion of the decoding procedure for the format.
+It is intended to be used in conjunction with, and as a guide to, the
+reference decoder source code provided in Attachment One
+(Section 20). If there are any conflicts between this narrative and
+the reference source code, the reference source code should be
+considered correct. The bitstream is defined by the reference source
+code and not this narrative.
-Like many modern video compression schemes, VP8 is based on decomposition of frames into square subblocks of pixels, prediction of such subblocks using previously constructed blocks, and adjustment of such predictions (as well as synthesis of unpredicted blocks) using a discrete cosine transform (hereafter abbreviated as DCT). In one special case, however, VP8 uses a "Walsh-Hadamard" transform (hereafter abbreviated as WHT) instead of a DCT.
+Like many modern video compression schemes, VP8 is based on
+decomposition of frames into square subblocks of pixels, prediction
+of such subblocks using previously constructed blocks, and adjustment
+of such predictions (as well as synthesis of unpredicted blocks)
+using a discrete cosine transform (hereafter abbreviated as DCT). In
+one special case, however, VP8 uses a Walsh-Hadamard transform
+(hereafter abbreviated as WHT) instead of a DCT.
-Roughly speaking, such systems reduce datarate by exploiting the temporal and spatial coherence of most video signals. It is more efficient to specify the location of a visually similar portion of a prior frame than it is to specify pixel values. The frequency segregation provided by the DCT and WHT facilitate the exploitation of both spatial coherence in the original signal and the tolerance of the human visual system to moderate losses of fidelity in the reconstituted signal.
+Roughly speaking, such systems reduce datarate by exploiting the
+temporal and spatial coherence of most video signals. It is more
+efficient to specify the location of a visually similar portion of a
+prior frame than it is to specify pixel values. The frequency
+segregation provided by the DCT and WHT facilitates the exploitation
+of both spatial coherence in the original signal and the tolerance of
+the human visual system to moderate losses of fidelity in the
+reconstituted signal.
-VP8 augments these basic concepts with, among other things, sophisticated usage of contextual probabilities. The result is a significant reduction in datarate at a given quality.
+VP8 augments these basic concepts with, among other things,
+sophisticated usage of contextual probabilities. The result is a
+significant reduction in datarate at a given quality.
-Unlike some similar schemes (the older MPEG formats, for example), VP8 specifies exact values for reconstructed pixels. Specifically, the specification for the DCT and WHT portions of the reconstruction does not allow for any "drift" caused by truncation of fractions. Rather, the algorithm is specified using fixed-precision integer operations exclusively. This greatly facilitates the verification of the correctness of a decoder implementation as well as avoiding difficult-to-predict visual incongruities between such implementations.
+Unlike some similar schemes (the older MPEG formats, for example),
+VP8 specifies exact values for reconstructed pixels. Specifically,
+the specification for the DCT and WHT portions of the reconstruction
+does not allow for any "drift" caused by truncation of fractions.
+Rather, the algorithm is specified using fixed-precision integer
+operations exclusively. This greatly facilitates the verification of
+the correctness of a decoder implementation and also avoids
+difficult-to-predict visual incongruities between such
+implementations.
-It should be remarked that, in a complete video playback system, the displayed frames may or may not be identical to the reconstructed frames. Many systems apply a final level of filtering (commonly referred to as postprocessing) to the reconstructed frames prior to viewing. Such postprocessing has no effect on the decoding and reconstruction of subsequent frames (which are predicted using the completely-specified reconstructed frames) and is beyond the scope of this document. In practice, the nature and extent of this sort of postprocessing is dependent on both the taste of the user and on the computational facilities of the playback environment.
+It should be remarked that, in a complete video playback system, the
+displayed frames may or may not be identical to the reconstructed
+frames. Many systems apply a final level of filtering (commonly
+referred to as postprocessing) to the reconstructed frames prior to
+viewing. Such postprocessing has no effect on the decoding and
+reconstruction of subsequent frames (which are predicted using the
+completely specified reconstructed frames) and is beyond the scope of
+this document. In practice, the nature and extent of this sort of
+postprocessing is dependent on both the taste of the user and on the
+computational facilities of the playback environment.
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 [RFC2119].
diff --git a/text_src/02.00__vp8-bitstream__format-overview.txt b/text_src/02.00__vp8-bitstream__format-overview.txt
index 323e639..5adf610 100644
--- a/text_src/02.00__vp8-bitstream__format-overview.txt
+++ b/text_src/02.00__vp8-bitstream__format-overview.txt
@@ -1,24 +1,73 @@
-### Chapter 2: Format Overview {#h-02-00}
+### Section 2: Format Overview {#h-02-00}
-VP8 works exclusively with an 8-bit YUV 4:2:0 image format. In this format, each 8-bit pixel in the two chroma planes (U and V) corresponds positionally to a 2x2 block of 8-bit luma pixels in the Y plane; coordinates of the upper left corner of the Y block are of course exactly twice the coordinates of the corresponding chroma pixels. When we refer to pixels or pixel distances without specifying a plane, we are implicitly referring to the Y plane or to the complete image, both of which have the same (full) resolution.
+VP8 works exclusively with an 8-bit YUV 4:2:0 image format. In this
+format, each 8-bit pixel in the two chroma planes (U and V)
+corresponds positionally to a 2x2 block of 8-bit luma pixels in the
+Y plane; coordinates of the upper left corner of the Y block are of
+course exactly twice the coordinates of the corresponding chroma
+pixels. When we refer to pixels or pixel distances without
+specifying a plane, we are implicitly referring to the Y plane or to
+the complete image, both of which have the same (full) resolution.
-As is usually the case, the pixels are simply a large array of bytes stored in rows from top to bottom, each row being stored from left to right. This "left to right" then "top to bottom" raster-scan order is reflected in the layout of the compressed data as well.
+As is usually the case, the pixels are simply a large array of bytes
+stored in rows from top to bottom, each row being stored from left to
+right. This "left to right" then "top to bottom" raster-scan order
+is reflected in the layout of the compressed data as well.
-Provision has been made in the VP8 bitstream header for the support of a secondary YUV color format, in the form of a reserved bit.
+Provision has been made in the VP8 bitstream header for the support
+of a secondary YUV color format, in the form of a reserved bit.
-Occasionally, at very low datarates, a compression system may decide to reduce the resolution of the input signal to facilitate efficient compression. The VP8 data format supports this via optional upscaling of its internal reconstruction buffer prior to output (this is completely distinct from the optional postprocessing discussed earlier, which has nothing to do with decoding per se). This upsampling restores the video frames to their original resolution. In other words, the compression/decompression system can be viewed as a "black box", where the input and output is always at a given resolution. The compressor might decide to "cheat" and process the signal at a lower resolution. In that case, the decompressor needs the ability to restore the signal to its original resolution.
+Occasionally, at very low datarates, a compression system may decide
+to reduce the resolution of the input signal to facilitate efficient
+compression. The VP8 data format supports this via optional
+upscaling of its internal reconstruction buffer prior to output (this
+is completely distinct from the optional postprocessing discussed
+earlier, which has nothing to do with decoding per se). This
+upsampling restores the video frames to their original resolution.
+In other words, the compression/decompression system can be viewed as
+a "black box", where the input and output are always at a given
+resolution. The compressor might decide to "cheat" and process the
+signal at a lower resolution. In that case, the decompressor needs
+the ability to restore the signal to its original resolution.
-Internally, VP8 decomposes each output frame into an array of macroblocks. A macroblock is a square array of pixels whose Y dimensions are 16x16 and whose U and V dimensions are 8x8. Macroblock-level data in a compressed frame occurs (and must be processed) in a raster order similar to that of the pixels comprising the frame.
+Internally, VP8 decomposes each output frame into an array of
+macroblocks. A macroblock is a square array of pixels whose Y
+dimensions are 16x16 and whose U and V dimensions are 8x8.
+Macroblock-level data in a compressed frame occurs (and must be
+processed) in a raster order similar to that of the pixels comprising
+the frame.
-Macroblocks are further decomposed into 4x4 subblocks. Every macroblock has 16 Y subblocks, 4 U subblocks, and 4 V subblocks. Any subblock-level data (and processing of such data) again occurs in raster order, this time in raster order within the containing macroblock.
+Macroblocks are further decomposed into 4x4 subblocks. Every
+macroblock has 16 Y subblocks, 4 U subblocks, and 4 V subblocks. Any
+subblock-level data (and processing of such data) again occurs in
+raster order, this time in raster order within the containing
+macroblock.
-As discussed in further detail below, data can be specified at the levels of both macroblocks and their subblocks.
+As discussed in further detail below, data can be specified at the
+levels of both macroblocks and their subblocks.
-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.
+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 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 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 than 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 Section 13.
-The frame layout used by the reference decoder may be found in the file `vpx_image.h`.
+The frame layout used by the reference decoder may be found in the
+file `vpx_image.h` (Section 20.23).
diff --git a/text_src/03.00__vp8-bitstream__compressed-frame-types.txt b/text_src/03.00__vp8-bitstream__compressed-frame-types.txt
index fc8c3cb..cfc515e 100644
--- a/text_src/03.00__vp8-bitstream__compressed-frame-types.txt
+++ b/text_src/03.00__vp8-bitstream__compressed-frame-types.txt
@@ -1,16 +1,47 @@
-### Chapter 3: Compressed Frame Types {#h-03-00}
+### Section 3: Compressed Frame Types {#h-03-00}
There are only two types of frames in VP8.
-_Intraframes_ (also called _key frames_ and, in MPEG terminology, _I-frames_) are decoded without reference to any other frame in a sequence, that is, the decompressor reconstructs such frames beginning from its "default" state. Key frames provide random access (or seeking) points in a video stream.
+_Intraframes_ (also called _key frames_ and, in MPEG terminology,
+_I-frames_) are decoded without reference to any other frame in a
+sequence; that is, the decompressor reconstructs such frames
+beginning from its "default" state. Key frames provide random access
+(or seeking) points in a video stream.
-_Interframes_ (also called _prediction frames_ and, in MPEG terminology, _P-frames_) are encoded with reference to prior frames, specifically all prior frames up to and including the most recent key frame. Generally speaking, the correct decoding of an interframe depends on the correct decoding of the most recent key frame and all ensuing frames. Consequently, the decoding algorithm is not tolerant of dropped frames: In an environment in which frames may be dropped or corrupted, correct decoding will not be possible until a key frame is correctly received.
+_Interframes_ (also called _prediction frames_ and, in MPEG terminology,
+_P-frames_) are encoded with reference to prior frames, specifically
+all prior frames up to and including the most recent key frame.
+Generally speaking, the correct decoding of an interframe depends on
+the correct decoding of the most recent key frame and all ensuing
+frames. Consequently, the decoding algorithm is not tolerant of
+dropped frames: In an environment in which frames may be dropped or
+corrupted, correct decoding will not be possible until a key frame is
+correctly received.
-In contrast to MPEG, there is no use of bidirectional prediction. No frame is predicted using frames temporally subsequent to it; there is no analog to an MPEG B-frame.
+In contrast to MPEG, there is no use of bidirectional prediction. No
+frame is predicted using frames temporally subsequent to it; there is
+no analog to an MPEG B-frame.
-Secondly, VP8 augments these notions with that of alternate prediction frames, called _golden frames_ and _altref frames_ (alternative reference frames). Blocks in an interframe may be predicted using blocks in the immediately previous frame as well as the most recent golden frame or altref frame. Every key frame is automatically golden and altref, and any interframe may optionally replace the most recent golden or altref frame.
+Secondly, VP8 augments these notions with that of alternate
+prediction frames, called _golden frames_ and _altref frames_
+(alternative reference frames). Blocks in an interframe may be
+predicted using blocks in the immediately previous frame as well as
+the most recent golden frame or altref frame. Every key frame is
+automatically golden and altref, and any interframe may optionally
+replace the most recent golden or altref frame.
-Golden frames and altref frames may also be used to partially overcome the intolerance to dropped frames discussed above: If a compressor is configured to code golden frames only with reference to the prior golden frame (and key frame) then the "substream" of key and golden frames may be decoded regardless of loss of other interframes. Roughly speaking, the implementation requires (on the compressor side) that golden frames subsume and recode any context updates effected by the intervening interframes. A typical application of this approach is video conferencing, in which retransmission of a prior golden frame and/or a delay in playback until receipt of the next golden frame is preferable to a larger retransmit and/or delay until the next key frame.
+Golden frames and altref frames may also be used to partially
+overcome the intolerance to dropped frames discussed above: If a
+compressor is configured to code golden frames only with reference to
+the prior golden frame (and key frame), then the "substream" of key
+and golden frames may be decoded regardless of loss of other
+interframes. Roughly speaking, the implementation requires (on the
+compressor side) that golden frames subsume and recode any context
+updates effected by the intervening interframes. A typical
+application of this approach is video conferencing, in which
+retransmission of a prior golden frame and/or a delay in playback
+until receipt of the next golden frame is preferable to a larger
+retransmit and/or delay until the next key frame.
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 e3331d6..129863b 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
@@ -1,29 +1,91 @@
-### Chapter 4: Overview of Compressed Data Format {#h-04-00}
+### Section 4: Overview of Compressed Data Format {#h-04-00}
-The input to a VP8 decoder is a sequence of compressed frames whose order matches their order in time. Issues such as the duration of frames, the corresponding audio, and synchronization are generally provided by the playback environment and are irrelevant to the decoding process itself, however, to aid in fast seeking a start code is included in the header of each key frame.
+The input to a VP8 decoder is a sequence of compressed frames whose
+order matches their order in time. Issues such as the duration of
+frames, the corresponding audio, and synchronization are generally
+provided by the playback environment and are irrelevant to the
+decoding process itself; however, to aid in fast seeking, a start
+code is included in the header of each key frame.
-The decoder is simply presented with a sequence of compressed frames and produces a sequence of decompressed (reconstructed) YUV frames corresponding to the input sequence. As stated in the introduction, the exact pixel values in the reconstructed frame are part of VP8's specification. This document specifies the layout of the compressed frames and gives unambiguous algorithms for the correct production of reconstructed frames.
+The decoder is simply presented with a sequence of compressed frames
+and produces a sequence of decompressed (reconstructed) YUV frames
+corresponding to the input sequence. As stated in the Introduction,
+the exact pixel values in the reconstructed frame are part of VP8's
+specification. This document specifies the layout of the compressed
+frames and gives unambiguous algorithms for the correct production of
+reconstructed frames.
-The first frame presented to the decompressor is of course a key frame. This may be followed by any number of interframes; the correct reconstruction of each frame depends on all prior frames up to the key frame. The next key frame restarts this process: The decompressor resets to its default initial condition upon reception of a key frame and the decoding of a key frame (and its ensuing interframes) is completely independent of any prior decoding.
+The first frame presented to the decompressor is of course a key
+frame. This may be followed by any number of interframes; the
+correct reconstruction of each frame depends on all prior frames up
+to the key frame. The next key frame restarts this process: The
+decompressor resets to its default initial condition upon reception
+of a key frame, and the decoding of a key frame (and its ensuing
+interframes) is completely independent of any prior decoding.
-At the highest level, every compressed frame has three or more pieces. It begins with an uncompressed data chunk comprising 10 bytes in the case of key frames and 3-bytes for inter frames. This is followed by two or more blocks of compressed data (called _partitions_). These compressed data partitions begin and end on byte boundaries.
+At the highest level, every compressed frame has three or more
+pieces. It begins with an uncompressed data chunk comprising
+10 bytes in the case of key frames and 3 bytes for interframes. This
+is followed by two or more blocks of compressed data (called
+_partitions_). These compressed data partitions begin and end on byte
+boundaries.
The first compressed partition has two subsections:
- 1. Header information that applies to the frame as a whole.
- 2. Per-macroblock information specifying how each macroblock is predicted from the already-reconstructed data that is available to the decompressor.
+ 1. Header information that applies to the frame as a whole.
-As stated above, the macroblock-level information occurs in raster-scan order.
+ 2. Per-macroblock information specifying how each macroblock is
+ predicted from the already-reconstructed data that is available
+ to the decompressor.
-The rest of the partitions contain, for each block, the DCT/WHT coefficients (quantized and logically compressed) of the residue signal to be added to the predicted block values. It typically accounts for roughly 70% of the overall datarate. VP8 supports packing the compressed DCT/WHT coefficients' data from macroblock rows into separate partitions. If there is more than one partition for these coefficients, the sizes of the partitions -- except the last partition -- in bytes are also present in the bitstream right after the above first partition. Each of the sizes is a 3-byte data item written in little endian format. These sizes provide the decoder direct access to all DCT/WHT coefficient partitions, which enables parallel processing of the coefficients in a decoder.
+As stated above, the macroblock-level information occurs in raster-
+scan order.
-The separate partitioning of the prediction data and coefficient data also allows flexibility in the implementation of a decompressor: An implementation may decode and store the prediction information for the whole frame and then decode, transform, and add the residue signal to the entire frame, or it may simultaneously decode both partitions, calculating prediction information and adding in the residue signal for each block in order. The length field in the frame tag, which allows decoding of the second partition to begin before the first partition has been completely decoded, is necessary for the second "block-at-a-time" decoder implementation.
+The rest of the partitions contain, for each block, the DCT/WHT
+coefficients (quantized and logically compressed) of the residue
+signal to be added to the predicted block values. It typically
+accounts for roughly 70% of the overall datarate. VP8 supports
+packing the compressed DCT/WHT coefficients' data from macroblock
+rows into separate partitions. If there is more than one partition
+for these coefficients, the sizes of the partitions -- except the
+last partition -- in bytes are also present in the bitstream right
+after the above first partition. Each of the sizes is a 3-byte data
+item written in little endian format. These sizes provide the
+decoder direct access to all DCT/WHT coefficient partitions, which
+enables parallel processing of the coefficients in a decoder.
-All partitions are decoded using separate instances of the boolean entropy decoder described in Chapter 7. Although some of the data represented within the partitions is conceptually "flat" (a bit is just a bit with no probabilistic expectation one way or the other), because of the way such coders work, there is never a direct correspondence between a "conceptual bit" and an actual physical bit in the compressed data partitions. Only in the 3 or 10 byte uncompressed chunk described above is there such a physical correspondence.
+The separate partitioning of the prediction data and coefficient data
+also allows flexibility in the implementation of a decompressor: An
+implementation may decode and store the prediction information for
+the whole frame and then decode, transform, and add the residue
+signal to the entire frame, or it may simultaneously decode both
+partitions, calculating prediction information and adding in the
+residue signal for each block in order. The length field in the
+frame tag, which allows decoding of the second partition to begin
+before the first partition has been completely decoded, is necessary
+for the second "block-at-a-time" decoder implementation.
-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.
+All partitions are decoded using separate instances of the boolean
+entropy decoder described in Section 7. Although some of the data
+represented within the partitions is conceptually "flat" (a bit is
+just a bit with no probabilistic expectation one way or the other),
+because of the way such coders work, there is never a direct
+correspondence between a "conceptual bit" and an actual physical bit
+in the compressed data partitions. Only in the 3- or 10-byte
+uncompressed chunk described above is there such a physical
+correspondence.
-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.
+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 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 ca998dd..df6b5df 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
@@ -1,63 +1,198 @@
-### Chapter 5: Overview of the Decoding Process {#h-05-00}
+### Section 5: Overview of the Decoding Process {#h-05-00}
-A VP8 decoder needs to maintain four YUV frame buffers whose resolutions are at least equal to that of the encoded image. These buffers hold the current frame being reconstructed, the immediately previous reconstructed frame, the most recent golden frame, and the most recent altref frame.
+A VP8 decoder needs to maintain four YUV frame buffers whose
+resolutions are at least equal to that of the encoded image. These
+buffers hold the current frame being reconstructed, the immediately
+previous reconstructed frame, the most recent golden frame, and the
+most recent altref frame.
-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.
+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 (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.
+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.
+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.
-Leaving most of the details for later elaboration, the following is an outline the decoding process.
+Leaving most of the details for later elaboration, the following is
+an outline of the decoding process.
-First, the frame header (beginning of the first data partition) is decoded. Altering or augmenting the maintained state of the decoder, this provides the context in which the per-macroblock data can be interpreted.
+First, the frame header (the beginning of the first data partition)
+is decoded. Altering or augmenting the maintained state of the
+decoder, this provides the context in which the per-macroblock data
+can be interpreted.
-The macroblock data occurs (and must be processed) in raster-scan order. This data comes in two or more parts. The first (_prediction_ or _mode_) part comes in the remainder of the first data partition. The other parts comprise the data partition(s) for the DCT/WHT coefficients of the residue signal. For each macroblock, the prediction data must be processed before the residue.
+The macroblock data occurs (and must be processed) in raster-scan
+order. This data comes in two or more parts. The first (_prediction_
+or _mode_) part comes in the remainder of the first data partition.
+The other parts comprise the data partition(s) for the DCT/WHT
+coefficients of the residue signal. For each macroblock, the
+prediction data must be processed before the residue.
-Each macroblock is predicted using one (and only one) of four possible frames. All macroblocks in a key frame, and all _intra-coded_ macroblocks in an interframe, are predicted using the already-decoded macroblocks in the current frame. Macroblocks in an interframe may also be predicted using the previous frame, the golden frame or the altref frame. Such macroblocks are said to be _inter-coded_.
+Each macroblock is predicted using one (and only one) of four
+possible frames. All macroblocks in a key frame, and all _intra-coded_
+macroblocks in an interframe, are predicted using the already-decoded
+macroblocks in the current frame. Macroblocks in an interframe may
+also be predicted using the previous frame, the golden frame, or the
+altref frame. Such macroblocks are said to be _inter-coded_.
-The purpose of prediction is to use already-constructed image data to approximate the portion of the original image being reconstructed. The effect of any of the prediction modes is then to write a macroblock-sized prediction buffer containing this approximation.
+The purpose of prediction is to use already-constructed image data to
+approximate the portion of the original image being reconstructed.
+The effect of any of the prediction modes is then to write a
+macroblock-sized prediction buffer containing this approximation.
-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.
+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 0th 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:
+_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:
- 1. Copying the row from above throughout the prediction buffer.
- 2. Copying the column from left throughout the prediction buffer.
- 3. Copying the average value of the row and column throughout the prediction buffer.
- 4. Extrapolation from the row and column using the (fixed) second difference (horizontal and vertical) from the upper left corner.
+ 1. Copying the row from above throughout the prediction buffer.
-Additionally, the sixteen Y subblocks may be predicted independently of each other using one of ten different _modes_, four of which are 4x4 analogs of those described above, augmented with six "diagonal" prediction methods. There are two types of predictions, one intra and one prediction (among all the modes), for which the residue signal does not use the Y2 block to encode the DC portion of the sixteen 4x4 Y subblock DCTs. This "independent Y subblock" mode has no effect on the 8x8 chroma prediction.
+ 2. Copying the column from the left throughout the prediction
+ buffer.
-_Inter-prediction_ exploits the temporal coherence between nearby frames. Except for the choice of the prediction frame itself, there is no difference between inter-prediction based on the previous frame and that based on the golden frame or altref frame.
+ 3. Copying the average value of the row and column throughout the
+ prediction buffer.
-Inter-prediction is conceptually very simple. While, for reasons of efficiency, there are several methods of encoding the relationship between the current macroblock and corresponding sections of the prediction frame, ultimately each of the sixteen Y subblocks is related to a 4x4 subblock of the prediction frame, whose position in that frame differs from the current subblock position by a (usually small) displacement. These two-dimensional displacements are called _motion vectors_.
+ 4. Extrapolation from the row and column using the (fixed) second
+ difference (horizontal and vertical) from the upper left corner.
-The motion vectors used by VP8 have quarter-pixel precision. Prediction of a subblock using a motion vector that happens to have integer (whole number) components is very easy: the 4x4 block of pixels from the displaced block in the previous, golden, or altref frame are simply copied into the correct position of the current macroblock's prediction buffer.
+Additionally, the sixteen Y subblocks may be predicted independently
+of each other using one of ten different _modes_, four of which are 4x4
+analogs of those described above, augmented with six "diagonal"
+prediction methods. There are two types of predictions, one intra
+and one prediction (among all the modes), for which the residue
+signal does not use the Y2 block to encode the DC portion of the
+sixteen 4x4 Y subblock DCTs. This "independent Y subblock" mode has
+no effect on the 8x8 chroma prediction.
-Fractional displacements are conceptually and implementationally more complex. They require the inference (or synthesis) of sample values that, strictly speaking, do not exist. This is one of the most basic problems in signal processing and readers conversant with that subject will see that the approach taken by VP8 provides a good balance of robustness, accuracy, and efficiency.
+_Inter-prediction_ exploits the temporal coherence between nearby
+frames. Except for the choice of the prediction frame itself, there
+is no difference between inter-prediction based on the previous frame
+and that based on the golden frame or altref frame.
-Leaving the details for the implementation discussion below, the pixel interpolation is calculated by applying a kernel filter (using reasonable-precision integer math) three pixels on either side, both horizontally and vertically, of the pixel to be synthesized. The resulting 4x4 block of synthetic pixels is then copied into position exactly as in the case of integer displacements.
+Inter-prediction is conceptually very simple. While, for reasons of
+efficiency, there are several methods of encoding the relationship
+between the current macroblock and corresponding sections of the
+prediction frame, ultimately each of the sixteen Y subblocks is
+related to a 4x4 subblock of the prediction frame, whose position in
+that frame differs from the current subblock position by a (usually
+small) displacement. These two-dimensional displacements are called
+_motion vectors_.
-Each of the eight chroma subblocks is handled similarly. Their motion vectors are never specified explicitly; instead, the motion vector for each chroma subblock is calculated by averaging the vectors of the four Y subblocks that occupy the same area of the frame. Since chroma pixels have twice the diameter (and four times the area) of luma pixels, the calculated chroma motion vectors have 1/8 pixel resolution, but the procedure for copying or generating pixels for each subblock is essentially identical to that done in the luma plane.
+The motion vectors used by VP8 have quarter-pixel precision.
+Prediction of a subblock using a motion vector that happens to have
+integer (whole number) components is very easy: The 4x4 block of
+pixels from the displaced block in the previous, golden, or altref
+frame is simply copied into the correct position of the current
+macroblock's prediction buffer.
-After all the macroblocks have been generated (predicted and corrected with the DCT/WHT residue), a filtering step (the _loop filter_) is applied to the entire frame. The purpose of the loop filter is to reduce blocking artifacts at the boundaries between macroblocks and between subblocks of the macroblocks. The term loop filter is used because this filter is part of the "coding loop," that is, it affects the reconstructed frame buffers that are used to predict ensuing frames. This is distinguished from the postprocessing filters discussed earlier which affect only the viewed video and do not "feed into" subsequent frames.
+Fractional displacements are conceptually and implementationally more
+complex. They require the inference (or synthesis) of sample values
+that, strictly speaking, do not exist. This is one of the most basic
+problems in signal processing, and readers conversant with that
+subject will see that the approach taken by VP8 provides a good
+balance of robustness, accuracy, and efficiency.
-Next, if signaled in the data, the current frame may replace the golden frame prediction buffer and/or the altref frame buffer.
+Leaving the details for the implementation discussion below, the
+pixel interpolation is calculated by applying a kernel filter (using
+reasonable-precision integer math) three pixels on either side, both
+horizontally and vertically, of the pixel to be synthesized. The
+resulting 4x4 block of synthetic pixels is then copied into position
+exactly as in the case of integer displacements.
-The halos of the frame buffers are next filled as specified above. Finally, at least as far as decoding is concerned, the (references to) the "current" and "last" frame buffers should be exchanged in preparation for the next frame.
+Each of the eight chroma subblocks is handled similarly. Their
+motion vectors are never specified explicitly; instead, the motion
+vector for each chroma subblock is calculated by averaging the
+vectors of the four Y subblocks that occupy the same area of the
+frame. Since chroma pixels have twice the diameter (and four times
+the area) of luma pixels, the calculated chroma motion vectors have
+1/8-pixel resolution, but the procedure for copying or generating
+pixels for each subblock is essentially identical to that done in the
+luma plane.
-Various processes may be required (or desired) before viewing the generated frame. As discussed in the frame dimension information below, truncation and/or upscaling of the frame may be required. Some playback systems may require a different frame format (RGB, YUY2, etc.). Finally, as mentioned in the introduction, further postprocessing or filtering of the image prior to viewing may be desired. Since the primary purpose of this document is a decoding specification, the postprocessing is not specified in this document.
+After all the macroblocks have been generated (predicted and
+corrected with the DCT/WHT residue), a filtering step (the _loop
+filter_) is applied to the entire frame. The purpose of the loop
+filter is to reduce blocking artifacts at the boundaries between
+macroblocks and between subblocks of the macroblocks. The term "loop
+filter" is used because this filter is part of the "coding loop";
+that is, it affects the reconstructed frame buffers that are used to
+predict ensuing frames. This is distinguished from the
+postprocessing filters discussed earlier, which affect only the
+viewed video and do not "feed into" subsequent frames.
-While the basic ideas of prediction and correction used by VP8 are straightforward, many of the details are quite complex. The management of probabilities is particularly elaborate. Not only do the various modes of intra-prediction and motion vector specification have associated probabilities but they, together with the coding of DCT coefficients and motion vectors, often base these probabilities on a variety of contextual information (calculated from what has been decoded so far), as well as on explicit modification via the frame header.
+Next, if signaled in the data, the current frame may replace the
+golden frame prediction buffer and/or the altref frame buffer.
-The "top-level" of decoding and frame reconstruction is implemented in the reference decoder files `dixie.c`.
+The halos of the frame buffers are next filled as specified above.
+Finally, at least as far as decoding is concerned, the (references
+to) the "current" and "last" frame buffers should be exchanged in
+preparation for the next frame.
-This concludes our summary of decoding and reconstruction; we continue by discussing the individual aspects in more depth.
+Various processes may be required (or desired) before viewing the
+generated frame. As discussed in the frame dimension information
+below, truncation and/or upscaling of the frame may be required.
+Some playback systems may require a different frame format (RGB,
+YUY2, etc.). Finally, as mentioned in the Introduction, further
+postprocessing or filtering of the image prior to viewing may be
+desired. Since the primary purpose of this document is a decoding
+specification, the postprocessing is not specified in this document.
-A reasonable "divide and conquer" approach to implementation of a decoder is to begin by decoding streams composed exclusively of key frames. After that works reliably, interframe handling can be added more easily than if complete functionality were attempted immediately. In accordance with this, we first discuss components needed to decode key frames (most of which are also used in the decoding of interframes) and conclude with topics exclusive to interframes.
+While the basic ideas of prediction and correction used by VP8 are
+straightforward, many of the details are quite complex. The
+management of probabilities is particularly elaborate. Not only do
+the various modes of intra-prediction and motion vector specification
+have associated probabilities, but they, together with the coding of
+DCT coefficients and motion vectors, often base these probabilities
+on a variety of contextual information (calculated from what has been
+decoded so far), as well as on explicit modification via the frame
+header.
+
+The "top-level" of decoding and frame reconstruction is implemented
+in the reference decoder file `dixie.c` (Section 20.4).
+
+This concludes our summary of decoding and reconstruction; we
+continue by discussing the individual aspects in more depth.
+
+A reasonable "divide and conquer" approach to implementation of a
+decoder is to begin by decoding streams composed exclusively of key
+frames. After that works reliably, interframe handling can be added
+more easily than if complete functionality were attempted
+immediately. In accordance with this, we first discuss components
+needed to decode key frames (most of which are also used in the
+decoding of interframes) and conclude with topics exclusive to
+interframes.
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 36bc114..b6ba599 100644
--- a/text_src/06.00__vp8-bitstream__description-of-algorithms.txt
+++ b/text_src/06.00__vp8-bitstream__description-of-algorithms.txt
@@ -1,22 +1,41 @@
-### Chapter 6: Description of Algorithms {#h-06-00}
+### Section 6: Description of Algorithms {#h-06-00}
-As the intent of this document, together with the reference decoder source code, is to specify a platform-independent procedure for the decoding and reconstruction of a VP8 video stream, many (small) algorithms must be described exactly.
+As the intent of this document, together with the reference decoder
+source code, is to specify a platform-independent procedure for the
+decoding and reconstruction of a VP8 video stream, many (small)
+algorithms must be described exactly.
-Due to its near-universality, terseness, ability to easily describe calculation at specific precisions, and the fact that On2's reference VP8 decoder is written in C, these algorithm fragments are written using the C programming language, augmented with a few simple definitions below.
+Due to its near-universality, terseness, ability to easily describe
+calculation at specific precisions, and the fact that On2's reference
+VP8 decoder is written in C, these algorithm fragments are written
+using the C programming language, augmented with a few simple
+definitions below.
-The standard (and best) reference for C is _The C Programming Language_, written by Brian W. Kernighan and Dennis M. Ritchie, and published by Prentice-Hall.
+The standard (and best) reference for C is [Kernighan].
-Many code fragments will be presented in this document. Some will be nearly identical to corresponding sections of the reference decoder; others will differ. Roughly speaking, there are three reasons for such differences:
+Many code fragments will be presented in this document. Some will be
+nearly identical to corresponding sections of the reference decoder;
+others will differ. Roughly speaking, there are three reasons for
+such differences:
- 1. For reasons of efficiency, the reference decoder version may be less obvious.
- 2. The reference decoder often uses large data structures to maintain context that need not be described or used here.
- 3. The authors of this document felt that a different expression of the same algorithm might facilitate exposition.
+ 1. For reasons of efficiency, the reference decoder version may be
+ less obvious.
-Regardless of the chosen presentation, the calculation effected by any of the algorithms described here is identical to that effected by the corresponding portion of the reference decoder.
+ 2. The reference decoder often uses large data structures to
+ maintain context that need not be described or used here.
-All VP8 decoding algorithms use integer math. To facilitate specification of arithmetic precision, we define the following types.
+ 3. The authors of this document felt that a different expression of
+ the same algorithm might facilitate exposition.
+
+Regardless of the chosen presentation, the calculation effected by
+any of the algorithms described here is identical to that effected by
+the corresponding portion of the reference decoder.
+
+All VP8 decoding algorithms use integer math. To facilitate
+specification of arithmetic precision, we define the following types.
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
typedef signed char int8; /* signed int exactly 8 bits wide */
@@ -39,14 +58,14 @@
/* While pixels themselves are 8-bit unsigned integers,
pixel arithmetic often occurs at 16- or 32-bit precision and
- the results need to be "saturated" or clamped to an 8-bit
+ the results need to be "saturated" or clamped to an 8-bit
range. */
typedef uint8 Pixel;
Pixel clamp255( int32 v) { return v < 0? 0 : (v < 255? v : 255);}
-/* As is elaborated in the discussion of the bool_decoder below,
+/* As is elaborated in the discussion of the bool_decoder below,
VP8 represents probabilities as unsigned 8-bit numbers. */
typedef uint8 Prob;
@@ -54,7 +73,22 @@
{: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.
+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 cc3192e..1dcbea2 100644
--- a/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
+++ b/text_src/07.00__vp8-bitstream__boolean-entropy-decoder.txt
@@ -1,26 +1,56 @@
-### Chapter 7: Boolean Entropy Decoder {#h-07-00}
+### Section 7: Boolean Entropy Decoder {#h-07-00}
-As discussed in the overview above, essentially the entire VP8 data stream is encoded using a boolean entropy coder.
+As discussed in the overview above, essentially the entire VP8 data
+stream is encoded using a boolean entropy coder.
-An understanding of the `bool_decoder` is critical to the implementation of a VP8 decompressor, so we discuss in detail. It is easier to comprehend the `bool_decoder` in conjunction with the `bool_encoder` used by the compressor to write the compressed data partitions.
+An understanding of the `bool_decoder` is critical to the
+implementation of a VP8 decompressor, so we discuss the `bool_decoder`
+in detail. It is easier to comprehend the `bool_decoder` in
+conjunction with the `bool_encoder` used by the compressor to write
+the compressed data partitions.
-The `bool_encoder` encodes (and the `bool_decoder` decodes) one bool (zero-or-one boolean value) at a time. Its purpose is to losslessly compress a sequence of bools for which the probability of their being zero or one can be well-estimated (via constant or previously-coded information) at the time they are written, using identical corresponding probabilities at the time they are read.
+The `bool_encoder` encodes (and the `bool_decoder` decodes) one bool
+(zero-or-one boolean value) at a time. Its purpose is to losslessly
+compress a sequence of bools for which the probability of their being
+zero or one can be well-estimated (via constant or previously coded
+information) at the time they are written, using identical
+corresponding probabilities at the time they are read.
-As the reader is probably aware, if a bool is much more likely to be zero than one (for instance), it can, on average, be faithfully encoded using much less than one bit per value. The `bool_encoder` exploits this.
+As the reader is probably aware, if a bool is much more likely to be
+zero than one (for instance), it can, on average, be faithfully
+encoded using much less than one bit per value. The `bool_encoder`
+exploits this.
-In the 1940s, Claude Shannon proved that there is a lower bound for the average datarate of a faithful encoding of a sequence of bools (whose probability distributions are known and are independent of each other) and also that there are encoding algorithms that approximate this lower bound as closely as one wishes.
+In the 1940s, [Shannon] proved that there is a lower bound for the
+average datarate of a faithful encoding of a sequence of bools (whose
+probability distributions are known and are independent of each
+other) and also that there are encoding algorithms that approximate
+this lower bound as closely as one wishes.
-If we encode a sequence of bools whose probability of being zero is [[ p ]] (and whose probability of being 1 is [[ 1-p ]]), the lowest possible datarate per value is
+If we encode a sequence of bools whose probability of being zero is p
+(and whose probability of being 1 is 1-p), the lowest possible
+datarate per value is
-[[ p*log(p) + (1-p)*log(1-p); ]]
+p*log(p) + (1-p)*log(1-p);
-taking the logarithms to the base [[ 1//2 ]] expresses the datarate in bits/value.
+taking the logarithms to the base 1/2 expresses the datarate in
+bits/value.
-We give two simple examples. At one extreme, if [[ p=1//2 ]], then [[ log(p) = log(1-p) = 1 ]] and the lowest possible datarate per bool is [[ 1//2 + 1//2 = 1 ]], that is, we cannot do any better than simply literally writing out bits. At another extreme, if [[ p ]] is very small, say [[ p=1//1024 ]], then [[ log(p)=10 ]], [[ log(1-p) ]] is roughly .0014, and the lowest possible datarate is approximately [[ 10//1024 + .0014 ]], roughly 1/100 of a bit per bool.
+We give two simple examples. At one extreme, if p = 1/2, then log(p)
+= log(1-p) = 1, and the lowest possible datarate per bool is 1/2 +
+1/2 = 1; that is, we cannot do any better than simply literally
+writing out bits. At another extreme, if p is very small, say p =
+1/1024, then log(p)=10, log(1-p) is roughly .0014, and the lowest
+possible datarate is approximately 10/1024 + .0014, roughly 1/100 of
+a bit per bool.
-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.
+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 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.
+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 [Bell].
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 66fff7d..04d4181 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
@@ -1,24 +1,67 @@
-#### 7.1 Underlying Theory of Coding {#h-07-01}
+#### 7.1 Underlying Theory of Coding {#h-07-01}
-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] ]].
+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.
+Before the first bool is coded, all values of x are possible.
-The coding of each bool restricts the possible values of [[ x ]] in proportion to the probability of what is coded. If [[ p1 ]] is the probability of the first bool being zero and a zero is coded, the range of possible [[ x ]] is restricted to [[ 0 <= x < p1 ]]. If a one is coded, the range becomes [[ p1 <= x < 1 ]].
+The coding of each bool restricts the possible values of x in
+proportion to the probability of what is coded. If p1 is the
+probability of the first bool being zero and a zero is coded, the
+range of possible values of x is restricted to 0 <= x < p1. If a one
+is coded, the range becomes p1 <= x < 1.
-The coding continues by repeating the same idea. At every stage, there is an interval [[ a <= x < b ]] of possible values of [[ x ]]. If [[ p ]] is the probability of a zero being coded at this stage and a zero is coded, the interval becomes [[ a <= x < a + (p*(b-a)) ]]. If a one is coded, the possible [[ x ]] are restricted to [[ a + (p*(b-a)) <= x < b ]].
+The coding continues by repeating the same idea. At every stage,
+there is an interval a <= x < b of possible values of x. If p is the
+probability of a zero being coded at this stage and a zero is coded,
+the interval becomes a <= x < a + (p*(b-a)). If a one is coded, the
+possible values of x are restricted to a + (p*(b-a)) <= x < b.
-Assuming only finitely many values are to be coded, after the encoder has received the last bool, it can write as its output any value [[ x ]] that lies in the final interval. VP8 simply writes the left endpoint of the final interval. Consequently, the output it would make if encoding were to stop at any time either increases or stays the same as each bool is encoded.
+Assuming that only finitely many values are to be coded, after the
+encoder has received the last bool, it can write as its output any
+value x that lies in the final interval. VP8 simply writes the left
+endpoint of the final interval. Consequently, the output it would
+make if encoding were to stop at any time either increases or stays
+the same as each bool is encoded.
-Decoding parallels encoding. The decoder is presented with the number [[ x ]], which has only the initial restriction [[ 0 <= x < 1 ]]. To decode the first bool, the decoder is given the first probability [[ p1 ]]. If [[ x < p1 ]], a zero is decoded; if [[ x >= p1 ]], a one is decoded. In either case, the new restriction on [[ x ]], that is, the interval of possible [[ x ]], is remembered.
+Decoding parallels encoding. The decoder is presented with the
+number x, which has only the initial restriction 0 <= x < 1. To
+decode the first bool, the decoder is given the first probability p1.
+If x < p1, a zero is decoded; if x >= p1, a one is decoded. In
+either case, the new restriction on x -- that is, the interval of
+possible values of x -- is remembered.
-Decoding continues in exactly the same way: If [[ a <= x < b ]] is the current interval and we are to decode a bool with zero-probability [[ p ]], we return a zero if [[ a <= x < a + (p*(b-a)) ]] and a one if [[ a + (p*(b-a)) <= x < b ]]. In either case, the new restriction is remembered in preparation for decoding the next bool.
+Decoding continues in exactly the same way: If a <= x < b is the
+current interval and we are to decode a bool with zero-probability p,
+we return a zero if a <= x < a + (p*(b-a)) and a one if a + (p*(b-a))
+<= x < b. In either case, the new restriction is remembered in
+preparation for decoding the next bool.
-The process outlined above uses real numbers of infinite precision to express the probabilities and ranges. It is true that, if one could actualize this process and coded a large number of bools whose supplied probabilities matched their value distributions, the datarate achieved would approach the theoretical minimum as the number of bools encoded increased.
+The process outlined above uses real numbers of infinite precision to
+express the probabilities and ranges. It is true that, if one could
+actualize this process and coded a large number of bools whose
+supplied probabilities matched their value distributions, the
+datarate achieved would approach the theoretical minimum as the
+number of bools encoded increased.
-Unfortunately, computers operate at finite precision and an approximation to the theoretically perfect process described above is necessary. Such approximation increases the datarate but, at quite moderate precision and for a wide variety of data sets, this increase is negligible.
+Unfortunately, computers operate at finite precision, and an
+approximation to the theoretically perfect process described above is
+necessary. Such approximation increases the datarate but, at quite
+moderate precision and for a wide variety of data sets, this increase
+is negligible.
-The only conceptual limitations are, first, that coder probabilities must be expressed at finite precision and, second, that the decoder be able to detect each individual modification to the value interval via examination of a fixed amount of input. As a practical matter, many of the implementation details stem from the fact that the coder can function using only a small "window" to incrementally read or write the arbitrarily precise number [[ x ]].
+The only conceptual limitations are, first, that coder probabilities
+must be expressed at finite precision and, second, that the decoder
+be able to detect each individual modification to the value interval
+via examination of a fixed amount of input. As a practical matter,
+many of the implementation details stem from the fact that the coder
+can function using only a small "window" to incrementally read or
+write the arbitrarily precise number x.
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 0122dfd..842702d 100644
--- a/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
+++ b/text_src/07.02__vp8-bitstream__practical-algorithm-description.txt
@@ -1,40 +1,94 @@
-#### 7.2 Practical Algorithm Description {#h-07-02}
+#### 7.2 Practical Algorithm Description {#h-07-02}
-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.
+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" ) ) ]]
+w + ( S * bottom ) <= v < w + ( S * ( bottom + range ) )
-Thus, appending [[ "bottom" ]] to the already-written bits [[ w ]] gives the left endpoint of the interval of possible values, appending [[ "bottom" + "range" ]] gives the right endpoint, [[ "range" ]] itself (scaled to the current output position) is the length of the interval.
+Thus, appending bottom to the already-written bits w gives the left
+endpoint of the interval of possible values, appending bottom + range
+gives the right endpoint, and range itself (scaled to the current
+output position) is the length of the interval.
-So that our probabilistic encodings are reasonably accurate, we do not let [[ "range" ]] vary by more than a factor of two: It stays within the bounds [[ 128 <= "range" <= 255 ]].
+So that our probabilistic encodings are reasonably accurate, we do
+not let range vary by more than a factor of two: It stays within the
+bounds 128 <= range <= 255.
-The process for encoding a boolean value [[ "val" ]] whose probability of being zero is [[ "prob" / 256 ]] -- and whose probability of being one is [[ ( 256 - "prob" ) / 256 ]] -- with [[ 1 <= "prob" <= 255 ]] is as follows.
+The process for encoding a boolean value val whose probability of
+being zero is prob / 256 -- and whose probability of being one is
+( 256 - prob ) / 256 -- with 1 <= prob <= 255 is as follows.
-Using an unsigned 16-bit multiply followed by an unsigned right shift, we calculate an unsigned 8-bit [[ "split" ]] value:
+Using an unsigned 16-bit multiply followed by an unsigned right
+shift, we calculate an unsigned 8-bit split value:
-[[ split = 1 + ((("range" - 1) * "probability")]] >> [[ 8) ]]
+split = 1 + (((range - 1) * probability)]] >> 8)
-[[ "split" ]] is approximately [[ ( "prob" / 256 ) * "range" ]] and lies within the bounds [[ 1 <= "split" <= "range" - 1 ]]. These bounds ensure the correctness of the decoding procedure described below.
+split is approximately ( prob / 256 ) * range and lies within the
+bounds 1 <= split <= range - 1. These bounds ensure the correctness
+of the decoding procedure described below.
-If the incoming boolean [[ "val" ]] to be encoded is false, we leave the left interval endpoint [[ "bottom" ]] alone and reduce [[ "range" ]], replacing it by [[ "split" ]]. If the incoming [[ "val" ]] is true, we move up the left endpoint to [[ "bottom" + "split" ]], propagating any carry to the already-written value [[ "w" ]] (this is where we need the ability to add 1 to [[ "w" ]]), and reduce [[ "range" ]] to [[ "range" - "split" ]].
+If the incoming boolean val to be encoded is false, we leave the left
+interval endpoint bottom alone and reduce range, replacing it by
+split. If the incoming val is true, we move up the left endpoint to
+bottom + split, propagating any carry to the already-written value w
+(this is where we need the ability to add 1 to w), and reduce range
+to range - split.
-Regardless of the value encoded, [[ "range" ]] has been reduced and now has the bounds [[ 1 <= "range" <= 254 ]]. If [[ "range" < 128 ]], the encoder doubles it and shifts the high-order bit out of [[ "bottom" ]] to the output as it also doubles [[ "bottom" ]], repeating this process one bit at a time until [[ 128 <= "range" <= 255 ]]. Once this is completed, the encoder is ready to accept another bool, maintaining the constraints described above.
+Regardless of the value encoded, range has been reduced and now has
+the bounds 1 <= range <= 254. If range < 128, the encoder doubles it
+and shifts the high-order bit out of bottom to the output as it also
+doubles bottom, repeating this process one bit at a time until 128 <=
+range <= 255. Once this is completed, the encoder is ready to
+accept another bool, maintaining the constraints described above.
-After encoding the last bool, the partition may be completed by appending [[ "bottom" ]] to the bitstream.
+After encoding the last bool, the partition may be completed by
+appending bottom to the bitstream.
-The decoder mimics the state of the encoder. It maintains, together with an input bit position, two unsigned 8-bit numbers, a [[ "range" ]] identical to that maintained by the encoder and a [[ "value" ]]. Decoding one bool at a time, the decoder (in effect) tracks the same left interval endpoint as does the encoder and subtracts it from the remaining input. Appending the unread portion of the bitstream to the 8-bit [[ "value" ]] gives the difference between the actual value encoded and the known left endpoint.
+The decoder mimics the state of the encoder. It maintains, together
+with an input bit position, two unsigned 8-bit numbers, a range
+identical to that maintained by the encoder and a value. Decoding
+one bool at a time, the decoder (in effect) tracks the same left
+interval endpoint as does the encoder and subtracts it from the
+remaining input. Appending the unread portion of the bitstream to
+the 8-bit value gives the difference between the actual value encoded
+and the known left endpoint.
-The decoder is initialized by setting [[ "range" = 255 ]] and reading the first 16 input bits into [[ "value" ]]. The decoder maintains [[ "range" ]] and calculates [[ "split" ]] in exactly the same way as does the encoder.
+The decoder is initialized by setting range = 255 and reading the
+first 16 input bits into value. The decoder maintains range and
+calculates split in exactly the same way as does the encoder.
-To decode a bool, it compares [[ "value" ]] to [[ "split" ]]; if [[ "value" < "split" ]], the bool is zero, and [[ "range" ]] is replaced with [[ "split" ]]. If [[ "value" >= "split" ]], the bool is one, [[ "range" ]] is replaced with [[ "range" - "split" ]], and [[ "value" ]] is replaced with [[ "value" - "split" ]].
+To decode a bool, it compares value to split; if value < split, the
+bool is zero, and range is replaced with split. If value >= split,
+the bool is one, range is replaced with range - split, and value is
+replaced with value - split.
-Again, [[ "range" ]] is doubled one bit at a time until it is at least 128. The [[ "value" ]] is doubled in parallel, shifting a new input bit into the [[ "bottom" ]] each time.
+Again, range is doubled one bit at a time until it is at least 128.
+The value is doubled in parallel, shifting a new input bit into the
+bottom each time.
-Writing [[ "Value" ]] for [[ "value" ]] together with the unread input bits and [[ "Range" ]] for [[ "range" ]] extended indefinitely on the right by zeros, the condition [[ "Value" < "Range" ]] is maintained at all times by the decoder. In particular, the bits shifted out of [[ "value" ]] as it is doubled are always zero.
+Writing Value for value together with the unread input bits and Range
+for range extended indefinitely on the right by zeros, the condition
+Value < Range is maintained at all times by the decoder. In
+particular, the bits shifted out of value as it is doubled are always
+zero.
diff --git a/text_src/07.03__vp8-bitstream__actual-implementation.txt b/text_src/07.03__vp8-bitstream__actual-implementation.txt
index f82fff8..05d524c 100644
--- a/text_src/07.03__vp8-bitstream__actual-implementation.txt
+++ b/text_src/07.03__vp8-bitstream__actual-implementation.txt
@@ -1,10 +1,17 @@
-#### 7.3 Actual Implementation {#h-07-03}
+#### 7.3 Actual Implementation {#h-07-03}
-The C code below gives complete implementations of the encoder and decoder described above. While they are logically identical to the "bit-at-a-time" versions, they internally buffer a couple of extra bytes of the bitstream. This allows I/O to be done (more practically) a byte at a time and drastically reduces the number of carries the encoder has to propagate into the already-written data.
+The C code below gives complete implementations of the encoder and
+decoder described above. While they are logically identical to the
+"bit-at-a-time" versions, they internally buffer a couple of extra
+bytes of the bitstream. This allows I/O to be done (more
+practically) a byte at a time and drastically reduces the number of
+carries the encoder has to propagate into the already-written data.
-Another (logically equivalent) implementation may be found in the reference decoder files `bool_decoder.h`.
+Another (logically equivalent) implementation may be found in the
+reference decoder file `bool_decoder.h` (Section 20.2).
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Encoder first */
@@ -23,15 +30,14 @@
{
e->output = start_partition;
e->range = 255;
-
e->bottom = 0;
e->bit_count = 24;
}
/* Encoding very rarely produces a carry that must be propagated
- to the already-written output. The arithmetic guarantees that
+ to the already-written output. The arithmetic guarantees that
the propagation will never go beyond the beginning of the
- output. Put another way, the encoded value x is always less
+ output. Put another way, the encoded value x is always less
than one. */
void add_one_to_output( uint8 *q)
@@ -46,7 +52,7 @@
void write_bool( bool_encoder *e, Prob prob, int bool_value)
{
- /* split is approximately (range * prob) / 256 and,
+ /* split is approximately (range * prob) / 256 and,
crucially, is strictly bigger than zero and strictly
smaller than range */
@@ -113,7 +119,7 @@
} bool_decoder;
/* Call this function before reading any bools from the
- partition.*/
+ partition. */
void init_bool_decoder( bool_decoder *d, uint8 *start_partition)
{
@@ -162,7 +168,7 @@
return retval;
}
-/* Convenience function reads a "literal", that is, a "num_bits"
+/* Convenience function reads a "literal", that is, a "num_bits"-
wide unsigned value whose bits come high- to low-order, with
each bit encoded at probability 128 (i.e., 1/2). */
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 69f6dfe..a6ddde3 100644
--- a/text_src/08.00__vp8-bitstream__compressed-data-components.txt
+++ b/text_src/08.00__vp8-bitstream__compressed-data-components.txt
@@ -1,33 +1,63 @@
-### Chapter 8: Compressed Data Components {#h-08-00}
+### Section 8: Compressed Data Components {#h-08-00}
-At the lowest level, VP8's compressed data is simply a sequence of probabilistically-encoded bools. Most of this data is composed of (slightly) larger semantic units fashioned from bools, which we describe here.
+At the lowest level, VP8's compressed data is simply a sequence of
+probabilistically encoded bools. Most of this data is composed of
+(slightly) larger semantic units fashioned from bools, which we
+describe here.
-We sometimes use these descriptions in C expressions within data format specifications. In this context, they refer to the return value of a call to an appropriate bool_decoder d, reading (as always) from its current reference point.
+We sometimes use these descriptions in C expressions within data
+format specifications. In this context, they refer to the return
+value of a call to an appropriate bool_decoder d, reading (as always)
+from its current reference point.
+
| Call | Alt. | Return
| --------------- | ------ | -------------------------------------
-| `Bool(p)` | `B(p)` | Bool with probability [[ p//256 ]] of being `0`. Return value of `read_bool(d, p)`.
+| `Bool(p)` | `B(p)` | Bool with probability p/256 of being `0`. Return value of `read_bool(d, p)`.
| `Flag` | `F` | A one-bit flag (same thing as a `B(128)` or an `L(1)`). Abbreviated `F`. Return value of `read_bool(d, 128)`.
| `Lit(n)` | `L(n)` | Unsigned n-bit number encoded as n flags (a "literal"). Abbreviated `L(n)`. The bits are read from high to low order. Return value of `read_literal(d, n)`.
| `SignedLit(n)` | | Signed n-bit number encoded similarly to an `L(n)`. Return value of `read_signed_literal(d, n)`. These are rare.
| `P(8)` | | An 8-bit probability. No different from an `L(8)`, but we sometimes use this notation to emphasize that a probability is being coded.
-| `P(7)` | | A 7-bit specification of an 8-bit probability. Coded as an `L(7)` number `x`; the resulting 8-bit probability is [[ x ? x ]] << [[ 1 : 1 ]].
-| `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`.
+| `P(7)` | | A 7-bit specification of an 8-bit probability. Coded as an `L(7)` number `x`; the resulting 8-bit probability is x ? x << 1 : 1.
+| `F? X` | | A flag that, if true, is followed by a piece of data `X`.
+| `F? X:Y` | | A flag that, 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`.
| `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).
-This is done by representing the alphabet as the leaves of a small binary tree. The (non-leaf) nodes of the tree have associated probabilities `p` and correspond to calls to `read_bool(d, p)`. We think of a zero as choosing the left branch below the node and a one as choosing the right branch.
+The last type requires elaboration. We often wish to encode
+something whose value is restricted to a small number of
+possibilities (the alphabet).
-Thus every value (leaf) whose tree depth is `x` is decoded after exactly `x` calls to `read_bool`.
+This is done by representing the alphabet as the leaves of a small
+binary tree. The (non-leaf) nodes of the tree have associated
+probabilities `p` and correspond to calls to `read_bool(d, p)`. We think
+of a zero as choosing the left branch below the node and a one as
+choosing the right branch.
-A tree representing an encoding of an alphabet of `n` possible values always contains `n-1` non-leaf nodes, regardless of its shape (this is easily seen by induction on `n`).
+Thus, every value (leaf) whose tree depth is `x` is decoded after
+exactly `x` calls to `read_bool`.
-There are many ways that a given alphabet can be so represented. The choice of tree has little impact on datarate but does affect decoder performance. The trees used by VP8 are chosen to (on average) minimize the number of calls to `read_bool`. This amounts to shaping the tree so that more probable values have smaller tree depth than do less probable values.
+A tree representing an encoding of an alphabet of `n` possible values
+always contains `n-1` non-leaf nodes, regardless of its shape (this is
+easily seen by induction on `n`).
-Readers familiar with Huffman coding will notice that, given an alphabet together with probabilities for each value, the associated Huffman tree minimizes the expected number of calls to `read_bool`. Such readers will also realize that the coding method described here never results in higher datarates than does the Huffman method and, indeed, often results in much lower datarates. Huffman coding is, in fact, nothing more than a special case of this method in which each node probability is fixed at 128 (i.e., 1/2).
+There are many ways that a given alphabet can be so represented. The
+choice of tree has little impact on datarate but does affect decoder
+performance. The trees used by VP8 are chosen to (on average)
+minimize the number of calls to `read_bool`. This amounts to shaping
+the tree so that values that are more probable have smaller tree
+depth than do values that are less probable.
+
+Readers familiar with Huffman coding will notice that, given an
+alphabet together with probabilities for each value, the associated
+Huffman tree minimizes the expected number of calls to `read_bool`.
+
+Such readers will also realize that the coding method described here
+never results in higher datarates than does the Huffman method and,
+indeed, often results in much lower datarates. Huffman coding is, in
+fact, nothing more than a special case of this method in which each
+node probability is fixed at 128 (i.e., 1/2).
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 fbfc63e..7d8d9a7 100644
--- a/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
+++ b/text_src/08.01__vp8-bitstream__tree-coding-implementation.txt
@@ -1,16 +1,37 @@
-#### 8.1 Tree Coding Implementation {#h-08-01}
+#### 8.1 Tree Coding Implementation {#h-08-01}
-We give a suggested implementation of a tree data structure followed by a couple of actual examples of its usage by VP8.
+We give a suggested implementation of a tree data structure followed
+by a couple of actual examples of its usage by VP8.
-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.
+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 Section 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 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 ]].
+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.
+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.
-Here is C code implementing the foregoing. The advantages of our data structure should be noted. Aside from the smallness of the structure itself, the tree-directed reading algorithm is essentially a single line of code.
+Here is C code implementing the foregoing. The advantages of our
+data structure should be noted. Aside from the smallness of the
+structure itself, the tree-directed reading algorithm is essentially
+a single line of code.
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* A tree specification is simply an array of 8-bit integers. */
@@ -37,5 +58,6 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-Tree-based decoding is implemented in the reference decoder file `bool_decoder.h`.
+Tree-based decoding is implemented in the reference decoder file
+`bool_decoder.h` (Section 20.2).
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 d7549dc..182d3c2 100644
--- a/text_src/08.02__vp8-bitstream__tree-coding-example.txt
+++ b/text_src/08.02__vp8-bitstream__tree-coding-example.txt
@@ -1,10 +1,18 @@
-#### 8.2 Tree Coding Example {#h-08-02}
+#### 8.2 Tree Coding Example {#h-08-02}
-As a multi-part example, without getting too far into the semantics of macroblock decoding (which is of course taken up below), we look at the "mode" coding for intra-predicted macroblocks.
+As a multi-part example, without getting too far into the semantics
+of macroblock decoding (which is of course taken up below), we look
+at the "mode" coding for intra-predicted macroblocks.
-It so happens that, because of a difference in statistics, the Y (or luma) mode encoding uses two different trees: one for key frames and another for interframes. This is the only instance in VP8 of the same dataset being coded by different trees under different circumstances. The UV (or chroma) modes are a proper subset of the Y modes and, as such, have their own decoding tree.
+It so happens that, because of a difference in statistics, the Y (or
+luma) mode encoding uses two different trees: one for key frames and
+another for interframes. This is the only instance in VP8 of the
+same dataset being coded by different trees under different
+circumstances. The UV (or chroma) modes are a proper subset of the Y
+modes and, as such, have their own decoding tree.
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
typedef enum
@@ -21,7 +29,7 @@
}
intra_mbmode;
-/* The aforementioned trees together with the implied codings as
+/* The aforementioned trees together with the implied codings as
comments.
Actual (i.e., positive) indices are always even.
Value (i.e., nonpositive) indices are arbitrary. */
@@ -30,9 +38,9 @@
{
-DC_PRED, 2, /* root: DC_PRED = "0", "1" subtree */
4, 6, /* "1" subtree has 2 descendant subtrees */
- -V_PRED, -H_PRED, /* "10" subtree: V_PRED = "100",
+ -V_PRED, -H_PRED, /* "10" subtree: V_PRED = "100",
H_PRED = "101" */
- -TM_PRED, -B_PRED /* "11" subtree: TM_PRED = "110",
+ -TM_PRED, -B_PRED /* "11" subtree: TM_PRED = "110",
B_PRED = "111" */
};
@@ -40,29 +48,34 @@
{
-B_PRED, 2, /* root: B_PRED = "0", "1" subtree */
4, 6, /* "1" subtree has 2 descendant subtrees */
- -DC_PRED, -V_PRED, /* "10" subtree: DC_PRED = "100",
+ -DC_PRED, -V_PRED, /* "10" subtree: DC_PRED = "100",
V_PRED = "101" */
- -H_PRED, -TM_PRED /* "11" subtree: H_PRED = "110",
+ -H_PRED, -TM_PRED /* "11" subtree: H_PRED = "110",
TM_PRED = "111" */
};
const tree_index uv_mode_tree [2 * (num_uv_modes - 1)] =
{
-DC_PRED, 2, /* root: DC_PRED = "0", "1" subtree */
- -V_PRED, 4, /* "1" subtree: V_PRED = "10",
+ -V_PRED, 4, /* "1" subtree: V_PRED = "10",
"11" subtree */
- -H_PRED, -TM_PRED /* "11" subtree: H_PRED = "110",
+ -H_PRED, -TM_PRED /* "11" subtree: H_PRED = "110",
TM_PRED = "111" */
};
-/* Given a bool_decoder d, a Y mode might be decoded as follows.*/
+/* Given a bool_decoder d, a Y mode might be decoded as follows. */
-const Prob pretend_its_huffman [num_ymodes - 1] =
+const Prob pretend_its_huffman [num_ymodes - 1] =
{ 128, 128, 128, 128};
Ymode = (intra_mbmode) treed_read( d, ymode_tree,
pretend_its_huffman);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{: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 those 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 990a22f..8894ed7 100644
--- a/text_src/09.00__vp8-bitstream__frame-header.txt
+++ b/text_src/09.00__vp8-bitstream__frame-header.txt
@@ -1,6 +1,10 @@
-### Chapter 9: Frame Header {#h-09-00}
+### Section 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. Most of the header decoding occurs in the reference decoder file `dixie.c`.
+The uncompressed data chunk at the start of each frame and at 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` (Section 20.4).
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 76f8bbb..f729ac5 100644
--- a/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
+++ b/text_src/09.01__vp8-bitstream__uncompressed-data-chunk.txt
@@ -1,17 +1,27 @@
-#### 9.1 Uncompressed Data Chunk {#h-09-01}
+#### 9.1 Uncompressed Data Chunk {#h-09-01}
-The uncompressed data chunk comprises a common (for key frames and interframes) 3-byte frame tag that contains four fields, as follows:
+The uncompressed data chunk comprises a common (for key frames and
+interframes) 3-byte frame tag that contains four fields, as follows:
1. A 1-bit frame type (`0` for key frames, `1` for interframes).
- 2. A 3-bit version number (`0` - `3` are defined as four different profiles with different decoding complexity; other values may be defined for future variants of the VP8 data format).
- 3. A 1-bit `show_frame` flag (`0` when current frame is not for display, `1` when current frame is for display).
- 4. A 19-bit field containing the size of the first data partition in bytes.
-Version number enables or disables certain features in the bitstream, as follows:
+ 2. A 3-bit version number (`0` - `3` are defined as four different
+ profiles with different decoding complexity; other values may be
+ defined for future variants of the VP8 data format).
-| Version | Reconstruction filter | Loop filter |
+ 3. A 1-bit `show_frame` flag (`0` when current frame is not for display,
+ `1` when current frame is for display).
+
+ 4. A 19-bit field containing the size of the first data partition in
+ bytes.
+
+The version number setting enables or disables certain features in
+the bitstream, as follows:
+
+
+| Version | Reconstruction Filter | Loop Filter |
| ------- | ----------------------- | ----------- |
| `0` | Bicubic | Normal |
| `1` | Bilinear | Simple |
@@ -19,9 +29,19 @@
| `3` | None | None |
| Other | Reserved for future use | |
-The reference software also adjusts the loop filter based on version number, as per the table above. Version number `1` implies a "simple" loop filter and version numbers `2` and `3` imply no loop filter. However, the "simple" filter setting in this context has no effect whatsoever on the decoding process, and the "no loop filter" setting only forces the reference encoder to set filter level equal to `0`. Neither affect the decoding process. In decoding, the only loop filter settings that matter are those in the frame header.
-For key frames the frame tag is followed by a further 7 bytes of uncompressed data, as follows:
+The reference software also adjusts the loop filter based on version
+number, as per the table above. Version number `1` implies a "simple"
+loop filter, and version numbers `2` and `3` imply no loop filter.
+However, the "simple" filter setting in this context has no effect
+whatsoever on the decoding process, and the "no loop filter" setting
+only forces the reference encoder to set filter level equal to `0`.
+Neither affect the decoding process. In decoding, the only loop
+filter settings that matter are those in the frame header.
+
+For key frames, the frame tag is followed by a further 7 bytes of
+uncompressed data, as follows:
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Start code byte 0 0x9d
@@ -34,7 +54,10 @@
{:lang="c"}
-The following source code segment illustrates validation of the start code and reading the width, height and scale factors for a key frame.
+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;
@@ -46,10 +69,11 @@
{:lang="c"}
-where `pbi->source` points to the beginning of the frame.
+Where `pbi->source` points to the beginning of the frame.
The following code reads the image dimension from the bitstream:
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pc->Width = swap2(*(unsigned short*)(c+3))&0x3fff;
pc->horiz_scale = swap2(*(unsigned short*)(c+3))>>14;
@@ -59,7 +83,9 @@
{:lang="c"}
-where `swap2` macro takes care of the endian on different platform:
+Where the `swap2` macro takes care of the endian on a different
+platform:
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#if defined(__ppc__) || defined(__ppc64__)
@@ -73,10 +99,18 @@
{:lang="c"}
-While each frame is encoded as a raster scan of 16x16 macroblocks, the frame dimensions are not necessarily evenly divisible by 16. In this case, write `ew = 16 - (width & 15)` and `eh = 16 - (height & 15)` for the excess width and height, respectively. Although they are encoded, the last `ew` columns and `eh` rows are not actually part of the image and should be discarded before final output. However, these "excess pixels" should be maintained in the internal reconstruction buffer used to predict ensuing frames.
+While each frame is encoded as a raster scan of 16x16 macroblocks,
+the frame dimensions are not necessarily evenly divisible by 16. In
+this case, write `ew = 16 - (width & 15)` and `eh = 16 - (height & 15)`
+for the excess width and height, respectively. Although they are
+encoded, the last `ew` columns and `eh` rows are not actually part of the
+image and should be discarded before final output. However, these
+"excess pixels" should be maintained in the internal reconstruction
+buffer used to predict ensuing frames.
The scaling specifications for each dimension are encoded as follows.
+
| Value | Scaling
| ------ | -------------------------------------
| `0` | No upscaling (the most common case).
@@ -84,7 +118,14 @@
| `2` | Upscale by 5/3.
| `3` | Upscale by 2.
-Upscaling does **not** affect the reconstruction buffer, which should be maintained at the encoded resolution. Any reasonable method of upsampling (including any that may be supported by video hardware in the playback environment) may be used. Since scaling has no effect on decoding, we do not discuss it any further.
-As discussed in Chapter 5, allocation (or re-allocation) of data structures (such as the reconstruction buffer) whose size depends on dimension will be triggered here.
+Upscaling does **not** affect the reconstruction buffer, which should be
+maintained at the encoded resolution. Any reasonable method of
+upsampling (including any that may be supported by video hardware in
+the playback environment) may be used. Since scaling has no effect
+on decoding, we do not discuss it any further.
+
+As discussed in Section 5, allocation (or re-allocation) of data
+structures (such as the reconstruction buffer) whose size depends on
+dimension will be triggered here.
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 c4e2efc..2b85f75 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
@@ -9,15 +9,20 @@
| `L(1)` | 1-bit pixel value clamping specification
-The color space type bit is encoded as the following:
+The color space type bit is encoded as follows:
- * `0` - YUV color space similar to the YCrCb color space defined in ITU-R BT.601
+ * `0` - YUV color space similar to the YCrCb color space defined in
+ [ITU-R_BT.601]
+
* `1` - Reserved for future use
-The pixel value clamping type bit is encoded as the following:
+The pixel value clamping type bit is encoded as follows:
- * `0` - Decoders are required to clamp the reconstructed pixel values to between `0` and `255` (inclusive).
- * `1` - Reconstructed pixel values are guaranteed to be between `0` and `255`, no clamping is necessary.
+ * `0` - Decoders are required to clamp the reconstructed pixel values
+ to between `0` and `255` (inclusive).
+
+ * `1` - Reconstructed pixel values are guaranteed to be between `0` and
+ `255`; no clamping is necessary.
Information in this subsection does not appear in interframes.
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 446851f..38c9012 100644
--- a/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
+++ b/text_src/09.03__vp8-bitstream__segment-based-adjustments.txt
@@ -1,25 +1,53 @@
-#### 9.3 Segment-based Adjustments {#h-09-03}
+#### 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 quantizer level or loop filter strength.
+This subsection contains probability and value information for
+implementing segment adaptive adjustments to default decoder
+behavior. The data in this subsection 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 the 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 the 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 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.
+ 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.
- 2. `L(1)` indicates if the segment map is updated for the current frame (`update_mb_segmentation_map`).
+ 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`).
+ 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:
+ 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`).
+ 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.
+ 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.
+ 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.
+The layout and semantics supporting this feature at the macroblock
+level are described in Section 10.
diff --git a/text_src/09.04__vp8-bitstream__loop-filter-type-and-levels.txt b/text_src/09.04__vp8-bitstream__loop-filter-type-and-levels.txt
index da324fe..c88dea0 100644
--- a/text_src/09.04__vp8-bitstream__loop-filter-type-and-levels.txt
+++ b/text_src/09.04__vp8-bitstream__loop-filter-type-and-levels.txt
@@ -1,10 +1,11 @@
-#### 9.4 Loop Filter Type and Levels {#h-09-04}
+#### 9.4 Loop Filter Type and Levels {#h-09-04}
-
-VP8 supports two types of loop filter, having different computational complexity. The following bits occur in the header to support the selection of the baseline type, strength and sharpness behavior of the loop filter used for the current frame.
-
+VP8 supports two types of loop filters having different computational
+complexity. The following bits occur in the header to support the
+selection of the baseline type, strength, and sharpness behavior of
+the loop filter used for the current frame.
| Index | Description
@@ -14,11 +15,33 @@
| `L(3)` | sharpness_level
-The meaning of these numbers will be further explained in Chapter 15.
+The meaning of these numbers will be further explained in Section 15.
-VP8 has a feature in the bitstream that enables adjustment of the loop filter level based on a macroblock's prediction mode and reference frame. The per-macroblock adjustment is done through delta values against default loop filter level for the current frame. This subsection contains flag and value information for implementing per-macroblock loop filter level adjustment to default decoder behaviors. The data in this section is used in the decoding of the ensuing per-macroblock information and applies to the entire frame.
+VP8 has a feature in the bitstream that enables adjustment of the
+loop filter level based on a macroblock's prediction mode and
+reference frame. The per-macroblock adjustment is done through delta
+values against the default loop filter level for the current frame.
+This subsection contains flag and value information for implementing
+per-macroblock loop filter level adjustment to default decoder
+behavior. The data in this section is used in the decoding of the
+ensuing per-macroblock information and applies to the entire frame.
-`L(1)` is a one-bit flag indicating if macroblock loop filter adjustment is on for the current frame. `0` means such feature is not supported in the current frame and `1` means this feature is enabled for the current frame.
+`L(1)` is a one-bit flag indicating if the macroblock loop filter
+adjustment is on for the current frame. `0` means that such a feature
+is not supported in the current frame, and `1` means this feature is
+enabled for the current frame.
-Whether the adjustment is based on reference frame or encoding mode, the adjustment of loop filter level is done via a delta value against a baseline loop filter value. The delta values are updated for the current frame if an `L(1)` bit, `mode_ref_lf_delta_update`, takes the value `1`. There are two groups of delta values, one group of delta values are for reference frame-based adjustments, the other group is for mode-based adjustments. The number of delta values in the two groups is `MAX_REF_LF_DELTAS` and `MAX_MODE_LF_DELTAS`, respectively. For every value within the two groups, there is one bit `L(1)` to indicate if the particular value is updated. When one is updated (1), it is transmitted as a six-bit magnitude `L(6)` followed by a one-bit sign flag `(L(1)`, `0` for positive and `1` for negative).
+Whether the adjustment is based on a reference frame or encoding
+mode, the adjustment of the loop filter level is done via a delta
+value against a baseline loop filter value. The delta values are
+updated for the current frame if an `L(1)` bit,
+`mode_ref_lf_delta_update`, takes the value `1`. There are two groups of
+delta values: One group of delta values is for reference frame-based
+adjustments, and the other group is for mode-based adjustments. The
+number of delta values in the two groups is `MAX_REF_LF_DELTAS` and
+`MAX_MODE_LF_DELTAS`, respectively. For every value within the two
+groups, there is a one-bit `L(1)` to indicate if the particular value
+is updated. When one is updated (1), it is transmitted as a six-bit-
+magnitude `L(6)` followed by a one-bit sign flag `(L(1)` -- `0` for
+positive and `1` for negative).
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 0c9406b..07631d9 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
@@ -1,9 +1,15 @@
-#### 9.5 Token Partition and Partition Data Offsets {#h-09-05}
+#### 9.5 Token Partition and Partition Data Offsets {#h-09-05}
-VP8 allows DCT coefficients to be packed into multiple partitions besides the first partition with header and per-macroblock prediction information, so the decoder can perform parallel decoding in an efficient manner. There are two bits `L(2)` used to indicate the number of coefficient data partitions within a compressed frame. The two bits are defined in the following table:
+VP8 allows DCT coefficients to be packed into multiple partitions,
+besides the first partition with header and per-macroblock prediction
+information, so the decoder can perform parallel decoding in an
+efficient manner. A two-bit `L(2)` is used to indicate the number of
+coefficient data partitions within a compressed frame. The two bits
+are defined in the following table:
+
| Bit 1 | Bit 0 | Number of Partitions
| :-----: | :-----: | :--------------------:
@@ -12,7 +18,17 @@
| 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 than 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.
+
+Offsets are embedded in the bitstream to provide the decoder direct
+access to token partitions. If the number of data partitions is
+greater than 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 b599a3a..d60234a 100644
--- a/text_src/09.06__vp8-bitstream__dequantization-indices.txt
+++ b/text_src/09.06__vp8-bitstream__dequantization-indices.txt
@@ -1,11 +1,22 @@
-#### 9.6 Dequantization Indices {#h-09-06}
+#### 9.6 Dequantization Indices {#h-09-06}
-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).
+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
+Section 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 Section 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 pseudocode 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. Pseudocode for
+reading the indices follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -26,7 +37,9 @@
{:lang="c"}
-Where `delta()` is the process to read 5 bits from the bitstream to determine a signed delta value:
+Where `delta()` is the process to read 5 bits from the bitstream to
+determine a signed delta value:
+
| Index | Description
| --------- | -------------------------------
diff --git a/text_src/09.07__vp8-bitstream__refresh-golden-frame-and-altref-frame.txt b/text_src/09.07__vp8-bitstream__refresh-golden-frame-and-altref-frame.txt
index 65a087a..b374d41 100644
--- a/text_src/09.07__vp8-bitstream__refresh-golden-frame-and-altref-frame.txt
+++ b/text_src/09.07__vp8-bitstream__refresh-golden-frame-and-altref-frame.txt
@@ -1,28 +1,42 @@
-#### 9.7 Refresh Golden Frame and AltRef Frame {#h-09-07}
+#### 9.7 Refresh Golden Frame and Altref Frame {#h-09-07}
-For key frames, both golden frame and altref frame are refreshed/replaced by the current reconstructed frame, by default. For non-key frames, VP8 uses two bits to indicate whether the two frame buffers are refreshed, using the reconstructed current frame:
+For key frames, both the golden frame and the altref frame are
+refreshed/ replaced by the current reconstructed frame, by default.
+For non-key frames, VP8 uses two bits to indicate whether the two
+frame buffers are refreshed, using the reconstructed current frame:
+
| Index | Description
| --------- | -------------------------------
| `L(1)` | Whether golden frame is refreshed (`0` for no, `1` for yes).
| `L(1)` | Whether altref frame is refreshed (`0` for no, `1` for yes).
-When the flag for golden frame is `0`, VP8 uses 2 more bits in the bitstream to indicate whether the buffer (and which buffer) is copied to the golden frame, or if no buffer is copied:
+
+When the flag for the golden frame is `0`, VP8 uses 2 more bits in the
+bitstream to indicate whether the buffer (and which buffer) is copied
+to the golden frame, or if no buffer is copied:
+
| Index | Description
| --------- | -------------------------------
| `L(2)` | Buffer copy flag for golden frame buffer
-Where:
-* `0` means no buffer is copied to golden frame
-* `1` means last_frame is copied to golden frame
-* `2` means alt_ref_frame is copied to golden frame
+Where:
-Similarly, when the flag for altref is `0`, VP8 uses 2 bits in the bitstream to indicate which buffer is copied to `alt_ref_frame`.
+* `0` means no buffer is copied to the golden frame
+
+* `1` means `last_frame` is copied to the golden frame
+
+* `2` means `alt_ref_frame` is copied to the golden frame
+
+
+Similarly, when the flag for altref is `0`, VP8 uses 2 bits in the
+bitstream to indicate which buffer is copied to `alt_ref_frame`.
+
| Index | Description
| --------- | -------------------------------
@@ -30,11 +44,16 @@
Where:
-* `0` means no buffer is copied to altref frame
-* `1` means `last_frame` is copied to altref frame
-* `2` means `golden_frame` is copied to altref frame
+* `0` means no buffer is copied to the altref frame
-Two bits are transmitted for `ref_frame_sign_bias` for `golden_frame` and `alt_ref_frame` respectively.
+* `1` means `last_frame` is copied to the altref frame
+
+* `2` means `golden_frame` is copied to the altref frame
+
+
+Two bits are transmitted for `ref_frame_sign_bias` for `golden_frame` and
+`alt_ref_frame`, respectively.
+
| Index | Description
| --------- | -------------------------------
@@ -42,5 +61,7 @@
| `L(1)` | Sign bias flag for altref frame
-These values are used to control the sign of the motion vectors when a golden frame or an altref frame is used as the reference frame for a macroblock.
+These values are used to control the sign of the motion vectors when
+a golden frame or an altref frame is used as the reference frame for
+a macroblock.
diff --git a/text_src/09.08__vp8-bitstream__refresh-last-frame-buffer.txt b/text_src/09.08__vp8-bitstream__refresh-last-frame-buffer.txt
index 8440053..8ef64ff 100644
--- a/text_src/09.08__vp8-bitstream__refresh-last-frame-buffer.txt
+++ b/text_src/09.08__vp8-bitstream__refresh-last-frame-buffer.txt
@@ -1,7 +1,10 @@
-#### 9.8 Refresh Last Frame Buffer {#h-09-08}
+#### 9.8 Refresh Last Frame Buffer {#h-09-08}
-VP8 uses one bit, `L(1)`, to indicate if the last frame reference buffer is refreshed using the constructed current frame. On key frame this bit is overridden, and the last frame buffer is always refreshed.
+VP8 uses one bit, `L(1)`, to indicate if the last frame reference
+buffer is refreshed using the constructed current frame. On a key
+frame, this bit is overridden, and the last frame buffer is always
+refreshed.
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 8297cea..cd1cfae 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
@@ -1,9 +1,16 @@
-#### 9.9 DCT Coefficient Probability Update {#h-09-09}
+#### 9.9 DCT Coefficient Probability Update {#h-09-09}
-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.
+This field 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)` flag is set to `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.
+The layout and semantics of this field will be taken up in
+Section 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 47282d1..b3482e8 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
@@ -1,19 +1,20 @@
-#### 9.10 Remaining Frame Header Data (non-Key Frame) {#h-09-10}
+#### 9.10 Remaining Frame Header Data (Non-Key Frame) {#h-09-10}
| Index | Description
| --------- | -----------------------------------------------------
-| `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. Details are given in 17.2, Probability Updates.
+| `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. Details are given in Section 17.2, "Probability Updates".
-Decoding of this portion of the frame header is handled in the reference decoder file `dixie.c`.
+Decoding of this portion of the frame header is handled in the
+reference decoder file `dixie.c` (Section 20.4).
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 6aa8d5d..f9e79a7 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
@@ -1,16 +1,20 @@
-#### 9.11 Remaining Frame Header Data (Key Frame) {#h-09-11}
+#### 9.11 Remaining Frame Header Data (Key Frame) {#h-09-11}
| Index | Description
| ------------ | -------------
-| `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(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`.
-This completes the layout of the frame header. The remainder of the first data partition consists of macroblock-level prediction data.
+Decoding of this portion of the frame header is handled in the reference decoder file `modemv.c` (Section 20.11).
-After the frame header is processed, all probabilities needed to decode the prediction and residue data are known and will not change until the next frame.
+This completes the layout of the frame header. The remainder of the
+first data partition consists of macroblock-level prediction data.
+
+After the frame header is processed, all probabilities needed to
+decode the prediction and residue data are known and will not change
+until the next frame.
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 1243286..2345d0f 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
@@ -1,11 +1,23 @@
-### Chapter 10: Segment-based Feature Adjustments {#h-10-00}
+### Section 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 ...
+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 ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -19,7 +31,12 @@
{:lang="c"}
-... combined with a 3-entry probability table `mb_segment_tree_probs[3]`. The macroblock's `segment_id` is used later in the decoding process to look into the `segment_feature_data` table and determine how the quantizer and loop filter levels are adjusted.
+... combined with a 3-entry probability table,
+`mb_segment_tree_probs[3]`. The macroblock's `segment_id` is used later
+in the decoding process to look into the `segment_feature_data` table
+and determine how the quantizer and loop filter levels are adjusted.
-The decoding of `segment_id`, together with the parsing of intra-prediction modes (which is taken up next), is implemented in the reference decoder file `modemv.c`.
+The decoding of `segment_id`, together with the parsing of intra-
+prediction modes (which is taken up next), is implemented in the
+reference decoder file `modemv.c`.
diff --git a/text_src/11.00__vp8-bitstream__key-frame-macroblock-prediction-records.txt b/text_src/11.00__vp8-bitstream__key-frame-macroblock-prediction-records.txt
index 5cd433e..0bbeba3 100644
--- a/text_src/11.00__vp8-bitstream__key-frame-macroblock-prediction-records.txt
+++ b/text_src/11.00__vp8-bitstream__key-frame-macroblock-prediction-records.txt
@@ -1,7 +1,9 @@
-### Chapter 11: Key Frame Macroblock Prediction Records {#h-11-00}
+### Section 11: Key Frame Macroblock Prediction Records {#h-11-00}
-After the features described above, the macroblock prediction record next specifies the prediction mode used for the macroblock.
+After specifying the features described above, the macroblock
+prediction record next specifies the prediction mode used for the
+macroblock.
diff --git a/text_src/11.01__vp8-bitstream__mbskipcoeff.txt b/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
index c7d4d25..6a6d1f7 100644
--- a/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
+++ b/text_src/11.01__vp8-bitstream__mbskipcoeff.txt
@@ -1,7 +1,9 @@
-#### 11.1 mb_skip_coeff {#h-11-01}
+#### 11.1 mb_skip_coeff {#h-11-01}
-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`.
+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 6bff4c3..681fadc 100644
--- a/text_src/11.02__vp8-bitstream__luma-modes.txt
+++ b/text_src/11.02__vp8-bitstream__luma-modes.txt
@@ -1,9 +1,11 @@
-#### 11.2 Luma Modes {#h-11-02}
+#### 11.2 Luma Modes {#h-11-02}
-First comes the luma specification of type `intra_mbmode`, coded using the `kf_ymode_tree`, as described in Chapter 8 and repeated here for convenience:
+First comes the luma specification of type `intra_mbmode`, coded using
+the `kf_ymode_tree`, as described in Section 8 and repeated here for
+convenience:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -34,7 +36,8 @@
{:lang="c"}
-For key frames, the Y mode is decoded using a fixed probability array as follows:
+For key frames, the Y mode is decoded using a fixed probability array
+as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -44,9 +47,12 @@
{:lang="c"}
-`d` is of course the `bool_decoder` being used to read the first data partition.
+`d` is of course the `bool_decoder` being used to read the first data
+partition.
-If the Ymode is `B_PRED`, it is followed by a (tree-coded) mode for each of the 16 Y subblocks. The 10 subblock modes and their coding tree as follows:
+If the Ymode is `B_PRED`, it is followed by a (tree-coded) mode for
+each of the 16 Y subblocks. The 10 subblock modes and their coding
+tree are as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -92,6 +98,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-The first four modes are smaller versions of the similarly-named 16x16 modes above, albeit with slightly different numbering. The last six "diagonal" modes are unique to luma subblocks.
+The first four modes are smaller versions of the similarly named
+16x16 modes above, albeit with slightly different numbering. The
+last six "diagonal" modes are unique to luma subblocks.
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 3ca817f..3f6bdce 100644
--- a/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
+++ b/text_src/11.03__vp8-bitstream__subblock-mode-contexts.txt
@@ -1,21 +1,54 @@
-#### 11.3 Subblock Mode Contexts {#h-11-03}
+#### 11.3 Subblock Mode Contexts {#h-11-03}
-The coding of subblock modes in key frames uses the modes already coded for the subblocks to the left of and above the subblock to select a probability array for decoding the current subblock mode. This is our first instance of contextual prediction, and there are several caveats associated with it:
+The coding of subblock modes in key frames uses the modes already
+coded for the subblocks to the left of and above the subblock to
+select a probability array for decoding the current subblock mode.
+This is our first instance of contextual prediction, and there are
+several caveats associated with it:
- 1. The adjacency relationships between subblocks are based on the normal default raster placement of the subblocks.
+ 1. The adjacency relationships between subblocks are based on the
+ normal default raster placement of the subblocks.
- 2. The adjacent subblocks need not lie in the current macroblock. The subblocks to the left of the left-edge subblocks 0, 4, 8, and 12 are the right-edge subblocks 3, 7, 11, and 15, respectively, of the (already coded) macroblock immediately to the left. Similarly, the subblocks above the top-edge subblocks 0, 1, 2, and 3 are the bottom-edge subblocks 12, 13, 14, and 15 of the already-coded macroblock immediately above us.
+ 2. The adjacent subblocks need not lie in the current macroblock.
+ The subblocks to the left of the left-edge subblocks 0, 4, 8, and
+ 12 are the right-edge subblocks 3, 7, 11, and 15, respectively,
+ of the (already coded) macroblock immediately to the left.
+ Similarly, the subblocks above the top-edge subblocks 0, 1, 2,
+ and 3 are the bottom-edge subblocks 12, 13, 14, and 15 of the
+ already-coded macroblock immediately above us.
- 3. For macroblocks on the top row or left edge of the image, some of the predictors will be non-existent. Such predictors are taken to have had the value `B_DC_PRED` which, perhaps conveniently, takes the value `0` in the enumeration above. A simple management scheme for these contexts might maintain a row of above predictors and four left predictors. Before decoding the frame, the entire row is initialized to `B_DC_PRED`; before decoding each row of macroblocks, the four left predictors are also set to `B_DC_PRED`. After decoding a macroblock, the bottom four subblock modes are copied into the row predictor (at the current position, which then advances to be above the next macroblock) and the right four subblock modes are copied into the left predictor.
+ 3. For macroblocks on the top row or left edge of the image, some of
+ the predictors will be non-existent. Such predictors are taken
+ to have had the value `B_DC_PRED`, which, perhaps conveniently,
+ takes the value `0` in the enumeration above. A simple management
+ scheme for these contexts might maintain a row of above
+ predictors and four left predictors. Before decoding the frame,
+ the entire row is initialized to `B_DC_PRED`; before decoding each
+ row of macroblocks, the four left predictors are also set to
+ `B_DC_PRED`. After decoding a macroblock, the bottom four subblock
+ modes are copied into the row predictor (at the current position,
+ which then advances to be above the next macroblock), and the
+ right four subblock modes are copied into the left predictor.
- 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`.
+ 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 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.
+ 5. Although we discuss interframe modes 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:
+The dependence of subblock mode probability on the nearby subblock
+mode context is most easily handled using a three-dimensional
+constant array:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -25,7 +58,11 @@
{:lang="c"}
-The outer two dimensions of this array are indexed by the already-coded subblock modes above and to the left of the current block, respectively. The inner dimension is a typical tree probability list whose indices correspond to the even indices of the `bmode_tree` above. The mode for the [[ j^(th) ]] luma subblock is then
+The outer two dimensions of this array are indexed by the already-
+coded subblock modes above and to the left of the current block,
+respectively. The inner dimension is a typical tree probability list
+whose indices correspond to the even indices of the `bmode_tree` above.
+The mode for the j^(th) luma subblock is then
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -35,7 +72,10 @@
{:lang="c"}
-where the 4x4 Y subblock index [[ j ]] varies from `0` to `15` in raster order and `A` and `L` are the modes used above and to-the-left of the [[ j^(th) ]] subblock.
+Where the 4x4 Y subblock index j varies from `0` to `15` in raster order,
+and `A` and `L` are the modes used above and to the left of the j^(th)
+subblock.
-The contents of the `kf_bmode_prob` array are given at the end of this chapter.
+The contents of the `kf_bmode_prob` array are given at the end of this
+section.
diff --git a/text_src/11.04__vp8-bitstream__chroma-modes.txt b/text_src/11.04__vp8-bitstream__chroma-modes.txt
index df826e2..04bcc14 100644
--- a/text_src/11.04__vp8-bitstream__chroma-modes.txt
+++ b/text_src/11.04__vp8-bitstream__chroma-modes.txt
@@ -1,9 +1,12 @@
-#### 11.4 Chroma Modes {#h-11-04}
+#### 11.4 Chroma Modes {#h-11-04}
-After the Y mode (and optional subblock mode) specification comes the chroma mode. The chroma modes are a subset of the Y modes and are coded using the `uv_mode_tree` described in Chapter 8, again repeated here for convenience:
+After the Y mode (and optional subblock mode) specification comes the
+chroma mode. The chroma modes are a subset of the Y modes and are
+coded using the `uv_mode_tree`, as described in Section 8 and repeated
+here for convenience:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -19,16 +22,21 @@
{:lang="c"}
-As for the Y modes (in a key frame), the chroma modes are coded using a fixed, contextless probability table:
+As for the Y modes (in a key frame), the chroma modes are coded using
+a fixed, contextless probability table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
const Prob kf_uv_mode_prob [num_uv_modes - 1] = { 142, 114, 183};
-uv_mode = (intra_mbmode) treed_read( d, uv_mode_tree,
+uv_mode = (intra_mbmode) treed_read( d, uv_mode_tree,
kf_uv_mode_prob);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-This completes the description of macroblock prediction coding for key frames. As will be discussed in Chapter 16, the coding of intra modes within interframes is similar, but not identical, to that described here (and in the reference code) for prediction modes and, indeed, for all tree-coded data in VP8.
+This completes the description of macroblock prediction coding for
+key frames. As will be discussed in Section 16, the coding of intra
+modes within interframes is similar, but not identical, to that
+described here (and in the reference code) for prediction modes and,
+indeed, for all tree-coded data in VP8.
diff --git a/text_src/11.05__vp8-bitstream__subblock-mode-probability-table.txt b/text_src/11.05__vp8-bitstream__subblock-mode-probability-table.txt
index 2e16424..f67772e 100644
--- a/text_src/11.05__vp8-bitstream__subblock-mode-probability-table.txt
+++ b/text_src/11.05__vp8-bitstream__subblock-mode-probability-table.txt
@@ -1,13 +1,13 @@
-#### 11.5 Subblock Mode Probability Table {#h-11-05}
+#### 11.5 Subblock Mode Probability Table {#h-11-05}
-Finally, here is the fixed probability table used to decode subblock modes in key frames.
-
+Finally, here is the fixed probability table used to decode subblock
+modes in key frames.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-const Prob kf_bmode_prob [num_intra_bmodes] [num_intra_bmodes]
+const Prob kf_bmode_prob [num_intra_bmodes] [num_intra_bmodes]
[num_intra_bmodes-1] =
{
{
diff --git a/text_src/12.00__vp8-bitstream__intraframe-prediction.txt b/text_src/12.00__vp8-bitstream__intraframe-prediction.txt
index 407ff4a..5df466e 100644
--- a/text_src/12.00__vp8-bitstream__intraframe-prediction.txt
+++ b/text_src/12.00__vp8-bitstream__intraframe-prediction.txt
@@ -1,17 +1,42 @@
-### Chapter 12: Intraframe Prediction {#h-12-00}
+### Section 12: Intraframe Prediction {#h-12-00}
-Intraframe prediction uses already-coded macroblocks within the current frame to approximate the contents of the current macroblock. It applies to intra-coded macroblocks in an interframe and to all macroblocks in a key frame.
+Intraframe prediction uses already-coded macroblocks within the
+current frame to approximate the contents of the current macroblock.
+It applies to intra-coded macroblocks in an interframe and to all
+macroblocks in a key frame.
-Relative to the current macroblock "M", the already-coded macroblocks include all macroblocks above M together with the macroblocks on the same row as, and to the left of, M, though at most four of these macroblocks are actually used: the block "A" directly above M, the blocks immediately to the left and right of A, and the block immediately to the left of M.
+Relative to the current macroblock "M", the already-coded macroblocks
+include all macroblocks above M together with the macroblocks on the
+same row as, and to the left of, M, though at most four of these
+macroblocks are actually used: the block "A" directly above M, the
+blocks immediately to the left and right of A, and the block
+immediately to the left of M.
-Each of the prediction modes (i.e., means of extrapolation from already-calculated values) uses fairly simple arithmetic on pixel values whose positions, relative to the current position, are defined by the mode.
+Each of the prediction modes (i.e., means of extrapolation from
+already-calculated values) uses fairly simple arithmetic on pixel
+values whose positions, relative to the current position, are defined
+by the mode.
-The chroma (U and V) and luma (Y) predictions are independent of each other.
+The chroma (U and V) and luma (Y) predictions are independent of each
+other.
-The relative addressing of pixels applied to macroblocks on the upper row or left column of the frame will sometimes cause pixels outside the visible frame to be referenced. Usually such out-of-bounds pixels have an assumed value of `129` for pixels to the left of the leftmost column of the visible frame and `127` for pixels above the top row of the visible frame (including the special case of the pixel above and to the left of the top-left pixel in the visible frame). Exceptions to this (associated to certain modes) will be noted below.
+The relative addressing of pixels applied to macroblocks on the upper
+row or left column of the frame will sometimes cause pixels outside
+the visible frame to be referenced. Usually such out-of-bounds
+pixels have an assumed value of `129` for pixels to the left of the
+leftmost column of the visible frame and `127` for pixels above the
+top row of the visible frame (including the special case of the pixel
+above and to the left of the top-left pixel in the visible frame).
+Exceptions to this (associated to certain modes) will be noted below.
-The already-coded macroblocks referenced by intra-prediction have been "reconstructed", that is, have been predicted and residue-adjusted (as described in Chapter 14), but have not been loop-filtered. While it does process the edges between individual macroblocks and individual subblocks, loop filtering (described in Chapter 15) is applied to the frame as a whole, after all of the macroblocks have been reconstructed.
+The already-coded macroblocks referenced by intra-prediction have
+been "reconstructed", that is, have been predicted and residue-
+adjusted (as described in Section 14), but have not been loop-
+filtered. While it does process the edges between individual
+macroblocks and individual subblocks, loop filtering (described in
+Section 15) is applied to the frame as a whole, after all of the
+macroblocks have been reconstructed.
diff --git a/text_src/12.01__vp8-bitstream__mbskipcoeff.txt b/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
index 066459b..4d9d42e 100644
--- a/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
+++ b/text_src/12.01__vp8-bitstream__mbskipcoeff.txt
@@ -1,7 +1,9 @@
-#### 12.1 mb_skip_coeff {#h-12-01}
+#### 12.1 mb_skip_coeff {#h-12-01}
-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`.
+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 237fd9c..7b49355 100644
--- a/text_src/12.02__vp8-bitstream__chroma-prediction.txt
+++ b/text_src/12.02__vp8-bitstream__chroma-prediction.txt
@@ -1,21 +1,51 @@
-#### 12.2 Chroma Prediction {#h-12-02}
+#### 12.2 Chroma Prediction {#h-12-02}
-The chroma prediction is a little simpler than the luma prediction, so we treat it first. Each of the chroma modes treats U and V identically, that is, the U and V prediction values are calculated in parallel, using the same relative addressing and arithmetic in each of the two planes.
+The chroma prediction is a little simpler than the luma prediction,
+so we treat it first. Each of the chroma modes treats U and V
+identically; that is, the U and V prediction values are calculated in
+parallel, using the same relative addressing and arithmetic in each
+of the two planes.
-The modes extrapolate prediction values using the 8-pixel row "A" lying immediately above the block (that is, the bottom chroma row of the macroblock immediately above the current macroblock) and the 8-pixel column "L" immediately to the left of the block (that is, the rightmost chroma column of the macroblock immediately to the left of the current macroblock).
+The modes extrapolate prediction values using the 8-pixel row "A"
+lying immediately above the block (that is, the bottom chroma row of
+the macroblock immediately above the current macroblock) and the
+8-pixel column "L" immediately to the left of the block (that is, the
+rightmost chroma column of the macroblock immediately to the left of
+the current macroblock).
-Vertical prediction (chroma mode `V_PRED`) simply fills each 8-pixel row of the 8x8 chroma block with a copy of the "above" row (A). If the current macroblock lies on the top row of the frame, all 8 of the pixel values in A are assigned the value `127`.
+Vertical prediction (chroma mode `V_PRED`) simply fills each 8-pixel
+row of the 8x8 chroma block with a copy of the "above" row (A). If
+the current macroblock lies on the top row of the frame, all 8 of the
+pixel values in A are assigned the value `127`.
-Similarly, horizontal prediction (`H_PRED`) fills each 8-pixel column of the 8x8 chroma block with a copy of the "left" column (L). If the current macroblock is in the left column of the frame, all 8 pixel values in L are assigned the value `129`.
+Similarly, horizontal prediction (`H_PRED`) fills each 8-pixel column
+of the 8x8 chroma block with a copy of the "left" column (L). If the
+current macroblock is in the left column of the frame, all 8 pixel
+values in `L` are assigned the value `129`.
-DC prediction (`DC_PRED`) fills the 8x8 chroma block with a single value. In the generic case of a macroblock lying below the top row and right of the leftmost column of the frame, this value is the average of the 16 (genuinely visible) pixels in the (union of the) above row A and left column L.
+DC prediction (`DC_PRED`) fills the 8x8 chroma block with a single
+value. In the generic case of a macroblock lying below the top row
+and right of the leftmost column of the frame, this value is the
+average of the 16 (genuinely visible) pixels in the (union of the)
+above row `A` and left column `L`.
-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`.
+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.
-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:
+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:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -27,9 +57,14 @@
{:lang="c"}
-Because the summands are all valid pixels, no "clamp" is necessary in the calculation of `DCvalue`.
+Because the summands are all valid pixels, no "clamp" is necessary in
+ the calculation of `DCvalue`.
-The remaining "True Motion" (`TM_PRED`) chroma mode gets its name from an older technique of video compression used by On2 Technologies, to which it bears some relation. In addition to the row "A" and column "L", `TM_PRED` uses the pixel "P" above and to the left of the chroma block.
+The remaining "True Motion" (`TM_PRED`) chroma mode gets its name from
+an older technique of video compression used by On2 Technologies, to
+which it bears some relation. In addition to the row "A" and column
+"L", `TM_PRED` uses the pixel "P" above and to the left of the chroma
+block.
The following figure gives an example of how `TM_PRED` works:
@@ -56,9 +91,12 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Where P, As and Ls represent reconstructed pixel values from previously coded blocks, and X00 through X77 represent predicted values for the current block. `TM_PRED` uses the following equation to calculate [[ X_ij ]]:
+Where P, As, and Ls represent reconstructed pixel values from
+previously coded blocks, and X00 through X77 represent predicted
+values for the current block. `TM_PRED` uses the following equation
+to calculate X_ij:
- [[ X_ij = L_i + A_j - P (i, j=0, 1, 2, 3) ]]
+ X_ij = L_i + A_j - P (i, j=0, 1, 2, 3)
The exact algorithm is as follows:
@@ -85,9 +123,14 @@
{:lang="c"}
-Note that the process could equivalently be described as propagating the vertical differences between pixels in L (starting from P), using the pixels from A to start each column.
+Note that the process could equivalently be described as propagating
+the vertical differences between pixels in L (starting from P), using
+the pixels from A to start each column.
-An implementation of chroma intra-prediction may be found in the reference decoder file `predict.c`.
+An implementation of chroma intra-prediction may be found in the
+reference decoder file `predict.c` (Section 20.14).
-Unlike `DC_PRED`, for macroblocks on the top row or left edge `TM_PRED` does use the out-of-bounds values of `127` and `129` (respectively) defined for `V_PRED` and `H_PRED`.
+Unlike `DC_PRED`, for macroblocks on the top row or left edge, `TM_PRED`
+does use the out-of-bounds values of `127` and `129` (respectively)
+defined for `V_PRED` and `H_PRED`.
diff --git a/text_src/12.03__vp8-bitstream__luma-prediction.txt b/text_src/12.03__vp8-bitstream__luma-prediction.txt
index fd82a1f..fde01f7 100644
--- a/text_src/12.03__vp8-bitstream__luma-prediction.txt
+++ b/text_src/12.03__vp8-bitstream__luma-prediction.txt
@@ -1,35 +1,72 @@
-#### 12.3 Luma Prediction {#h-12-03}
+#### 12.3 Luma Prediction {#h-12-03}
-The prediction processes for the first four 16x16 luma modes (`DC_PRED`, `V_PRED`, `H_PRED`, and `TM_PRED`) are essentially identical to the corresponding chroma prediction processes described above, the only difference being that we are predicting a single 16x16 luma block instead of two 8x8 chroma blocks.
+The prediction processes for the first four 16x16 luma modes
+(`DC_PRED`, `V_PRED`, `H_PRED`, and `TM_PRED`) are essentially identical to
+the corresponding chroma prediction processes described above, the
+only difference being that we are predicting a single 16x16 luma
+block instead of two 8x8 chroma blocks.
-Thus, the row "A" and column "L" here contain 16 pixels, the DC prediction is calculated using 16 or 32 pixels (and shf is 4 or 5), and we of course fill the entire prediction buffer, that is, 16 rows (or columns) containing 16 pixels each. The reference implementation of 16x16 luma prediction is also in `predict.c`.
+Thus, the row "A" and column "L" here contain 16 pixels, the DC
+prediction is calculated using 16 or 32 pixels (and shf is 4 or 5),
+and we of course fill the entire prediction buffer, that is, 16 rows
+(or columns) containing 16 pixels each. The reference implementation
+of 16x16 luma prediction is also in `predict.c`.
-In the remaining luma mode (`B_PRED`), each 4x4 Y subblock is independently predicted using one of ten modes (listed, along with their encodings, in Chapter 11).
+In the remaining luma mode (`B_PRED`), each 4x4 Y subblock is
+independently predicted using one of ten modes (listed, along with
+their encodings, in Section 11).
-Also, unlike the full-macroblock modes already described, some of the subblock modes use prediction pixels above and to the right of the current subblock. In detail, each 4x4 subblock "B" is predicted using (at most) the 4-pixel column "L" immediately to the left of B and the 8-pixel row "A" immediately above B, consisting of the 4 pixels above B followed by the 4 adjacent pixels above and to the right of B, together with the single pixel "P" immediately to the left of A (and immediately above L).
+Also, unlike the full-macroblock modes already described, some of the
+subblock modes use prediction pixels above and to the right of the
+current subblock. In detail, each 4x4 subblock "B" is predicted
+using (at most) the 4-pixel column "L" immediately to the left of B
+and the 8-pixel row "A" immediately above B, consisting of the 4
+pixels above B followed by the 4 adjacent pixels above and to the
+right of B, together with the single pixel "P" immediately to the
+left of A (and immediately above L).
-For the purpose of subblock intra-prediction, the pixels immediately to the left and right of a pixel in a subblock are the same as the pixels immediately to the left and right of the corresponding pixel in the frame buffer "F". Vertical offsets behave similarly: The above row A lies immediately above B in F, and the adjacent pixels in the left column L are separated by a single row in F.
+For the purpose of subblock intra-prediction, the pixels immediately
+to the left and right of a pixel in a subblock are the same as the
+pixels immediately to the left and right of the corresponding pixel
+in the frame buffer "F". Vertical offsets behave similarly: The
+above row A lies immediately above B in F, and the adjacent pixels in
+the left column L are separated by a single row in F.
-Because entire macroblocks (as opposed to their constituent subblocks) are reconstructed in raster-scan order, for subblocks lying along the right edge (and not along the top row) of the current macroblock, the four "extra" prediction pixels in A above and to the right of B have not yet actually been constructed.
+Because entire macroblocks (as opposed to their constituent
+subblocks) are reconstructed in raster-scan order, for subblocks
+lying along the right edge (and not along the top row) of the current
+macroblock, the four "extra" prediction pixels in A above and to the
+right of B have not yet actually been constructed.
-Subblocks 7, 11, and 15 are affected. All three of these subblocks use the same extra pixels as does subblock 3 (at the upper right corner of the macroblock), namely the 4 pixels immediately above and to the right of subblock 3. Writing `(R,C)` for a frame buffer position offset from the upper left corner of the current macroblock by R rows and C columns, the extra pixels for all the right-edge subblocks (3, 7, 11, and 15) are at positions (-1,16), (-1,17), (-1,18), and (-1,19). For the right-most macroblock in each macroblock row except the top row, the extra pixels shall use the same value as the pixel at position (-1, 15), which is the right-most visible pixel on the line immediately above the macroblock row. For the top macroblock row, all the extra pixels assume a value of 127.
+Subblocks 7, 11, and 15 are affected. All three of these subblocks
+use the same extra pixels as does subblock 3 (at the upper right
+corner of the macroblock), namely the 4 pixels immediately above and
+to the right of subblock 3. Writing (R,C) for a frame buffer
+position offset from the upper left corner of the current macroblock
+by R rows and C columns, the extra pixels for all the right-edge
+subblocks (3, 7, 11, and 15) are at positions (-1,16), (-1,17),
+(-1,18), and (-1,19). For the rightmost macroblock in each
+macroblock row except the top row, the extra pixels shall use the
+same value as the pixel at position (-1,15), which is the rightmost
+visible pixel on the line immediately above the macroblock row. For
+the top macroblock row, all the extra pixels assume a value of 127.
-The details of the prediction modes are most easily described in code.
-
+The details of the prediction modes are most easily described in
+code.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/* Result pixels are often averages of two or three predictor
- pixels. The following subroutines are used to calculate
- these averages. Because the arguments are valid pixels, no
- clamping is necessary. An actual implementation would
+/* Result pixels are often averages of two or three predictor
+ pixels. The following subroutines are used to calculate
+ these averages. Because the arguments are valid pixels, no
+ clamping is necessary. An actual implementation would
probably use inline functions or macros. */
/* Compute weighted average centered at y w/adjacent x, z */
-Pixel avg3( Pixel x, Pixel y, Pixel z) {
+Pixel avg3( Pixel x, Pixel y, Pixel z) {
return (x + y + y + z + 2) >> 2;}
/* Weighted average of 3 adjacent pixels centered at p */
@@ -40,7 +77,7 @@
Pixel avg2( Pixel x, Pixel y) { return (x + y + 1) >> 1;}
-/* Average of p[0] and p[1] may be considered to be a synthetic
+/* Average of p[0] and p[1] may be considered to be a synthetic
pixel lying between the two, that is, one half-step past p. */
Pixel avg2p( const Pixel *p) { return avg2( p[0], p[1]);}
@@ -49,7 +86,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.2 above */
+ intra_bmode mode /* enum is in Section 11.2 */
) {
Pixel E[9]; /* 9 already-constructed edge pixels */
E[0] = L[3]; E[1] = L[2]; E[2] = L[1]; E[3] = L[0];
@@ -57,7 +94,7 @@
E[5] = A[0]; E[6] = A[1]; E[7] = A[2]; E[8] = A[3];
switch( mode) {
- /* First four modes are similar to corresponding
+ /* First four modes are similar to corresponding
full-block modes. */
case B_DC_PRED:
@@ -65,7 +102,7 @@
int v = 4; /* DC sum/avg, 4 is rounding adjustment */
int i = 0; do { v += A[i] + L[i];} while( ++i < 4);
v >>= 3; /* averaging 8 pixels */
- i = 0; do { /* fill prediction buffer with constant DC
+ i = 0; do { /* fill prediction buffer with constant DC
value */
int j = 0; do { B[i][j] = v;} while( ++j < 4);
} while( ++i < 4);
@@ -94,29 +131,29 @@
{
/* Bottom row is exceptional because L[4] does not exist */
int v = avg3( L[2], L[3], L[3]);
- int r = 3; while( 1) { /* all 4 columns = smoothed left
+ int r = 3; while( 1) { /* all 4 columns = smoothed left
column */
B[r][0] = B[r][1] = B[r][2] = B[r][3] = v;
if( --r < 0)
break;
- v = avg3p( L + r); /* upper 3 rows use average of
+ v = avg3p( L + r); /* upper 3 rows use average of
3 pixels */
}
break;
}
- /* The remaining six "diagonal" modes subdivide the
- prediction buffer into diagonal lines. All the pixels
- on each line are assigned the same value; this value is
- (a smoothed or synthetic version of) an
- already-constructed predictor value lying on the same
- line. For clarity, in the comments, we express the
- positions of these predictor pixels relative to the
+ /* The remaining six "diagonal" modes subdivide the
+ prediction buffer into diagonal lines. All the pixels
+ on each line are assigned the same value; this value is
+ (a smoothed or synthetic version of) an
+ already-constructed predictor value lying on the same
+ line. For clarity, in the comments, we express the
+ positions of these predictor pixels relative to the
upper left corner of the destination array B.
- These modes are unique to subblock prediction and have
- no full-block analogues. The first two use lines at
- +|- 45 degrees from horizontal (or, equivalently,
+ These modes are unique to subblock prediction and have
+ no full-block analogs. The first two use lines at
+ +|- 45 degrees from horizontal (or, equivalently,
vertical), that is, lines whose slopes are +|- 1. */
case B_LD_PRED: /* southwest (left and down) step =
@@ -143,16 +180,16 @@
B[0][3] = avg3p( E + 7); /* (-1, 2) */
break;
- /* The remaining 4 diagonal modes use lines whose slopes are
- +|- 2 and +|- 1/2. The angles of these lines are roughly
+ /* The remaining 4 diagonal modes use lines whose slopes are
+ +|- 2 and +|- 1/2. The angles of these lines are roughly
+|- 27 degrees from horizontal or vertical.
- Unlike the 45 degree diagonals, here we often need to
- "synthesize" predictor pixels midway between two actual
- predictors using avg2p(p), which we think of as returning
+ Unlike the 45 degree diagonals, here we often need to
+ "synthesize" predictor pixels midway between two actual
+ predictors using avg2p(p), which we think of as returning
the pixel "at" p[1/2]. */
- case B_VR_PRED: /* SSE (vertical right) step =
+ case B_VR_PRED: /* SSE (vertical right) step =
(2,1) or (-2,-1) */
B[3][0] = avg3p( E + 2); /* predictor is from (1, -1) */
B[2][0] = avg3p( E + 3); /* (0, -1) */
@@ -166,7 +203,7 @@
B[0][3] = avg2p( E + 7); /* (-1, 5/2) */
break;
- case B_VL_PRED: /* SSW (vertical left) step =
+ case B_VL_PRED: /* SSW (vertical left) step =
(2,-1) or (-2,1) */
B[0][0] = avg2p( A); /* predictor is from (-1, 1/2) */
B[1][0] = avg3p( A + 1); /* (-1, 1) */
@@ -177,13 +214,13 @@
B[2][2] = B[0][3] = avg2p( A + 3); /* (-1, 7/2) */
B[3][2] = B[1][3] = avg3p( A + 4); /* (-1, 4) */
/* Last two values do not strictly follow the pattern. */
- B[2][3] = avg3p( A + 5); /* (-1, 5) [avg2p( A + 4) =
+ B[2][3] = avg3p( A + 5); /* (-1, 5) [avg2p( A + 4) =
(-1,9/2)] */
- B[3][3] = avg3p( A + 6); /* (-1, 6) [avg3p( A + 5) =
+ B[3][3] = avg3p( A + 6); /* (-1, 6) [avg3p( A + 5) =
(-1,5)] */
break;
- case B_HD_PRED: /* ESE (horizontal down) step =
+ case B_HD_PRED: /* ESE (horizontal down) step =
(1,2) or (-1,-2) */
B[3][0] = avg2p( E); /* predictor is from (5/2, -1) */
B[3][1] = avg3p( E + 1); /* (2, -1) */
@@ -197,7 +234,7 @@
B[0][3] = avg3p( E + 6); /* (-1, 1) */
break;
- case B_HU_PRED: /* ENE (horizontal up) step = (1,-2)
+ case B_HU_PRED: /* ENE (horizontal up) step = (1,-2)
or (-1,2) */
B[0][0] = avg2p( L); /* predictor is from ( 1/2, -1) */
B[0][1] = avg3p( L + 1); /* ( 1, -1) */
@@ -205,17 +242,16 @@
B[0][3] = B[1][1] = avg3p( L + 2); /* ( 2, -1) */
B[1][2] = B[2][0] = avg2p( L + 2); /* (5/2, -1) */
B[1][3] = B[2][1] = avg3( L[2], L[3], L[3]); /* ( 3, -1) */
- /* Not possible to follow pattern for much of the bottom
- row because no (nearby) already-constructed pixels lie
+ /* Not possible to follow pattern for much of the bottom
+ row because no (nearby) already-constructed pixels lie
on the diagonals in question. */
- B[2][2] = B[2][3] = B[3][0] = B[3][1] = B[3][2] = B[3][3]
+ B[2][2] = B[2][3] = B[3][0] = B[3][1] = B[3][2] = B[3][3]
= L[3];
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-The reference decoder implementation of subblock intra-prediction may be found
-in `predict.c`.
+The reference decoder implementation of subblock intra-prediction may
+be found in `predict.c` (Section 20.14).
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 bb85d3a..4bb6cdc 100644
--- a/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
+++ b/text_src/13.00__vp8-bitstream__dct-coefficient-decoding.txt
@@ -1,17 +1,42 @@
-### Chapter 13: DCT Coefficient Decoding {#h-13-00}
+### Section 13: DCT Coefficient Decoding {#h-13-00}
-The second data partition consists of an encoding of the quantized DCT (and WHT) coefficients of the residue signal. As discussed in the format overview (Chapter 2), for each macroblock, the residue is added to the (intra- or inter-generated) prediction buffer to produce the final (except for loop-filtering) reconstructed macroblock.
+The second data partition consists of an encoding of the quantized
+DCT (and WHT) coefficients of the residue signal. As discussed in
+the format overview (Section 2), for each macroblock, the residue is
+added to the (intra- or inter-generated) prediction buffer to produce
+the final (except for loop filtering) reconstructed macroblock.
-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.
+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 `SPLITMV` (inter) each macroblock's residue record begins with the Y2 component of the residue, coded using a WHT. `B_PRED` and `SPLITMV` coded macroblocks omit this WHT and specify the 0th DCT coefficient in each of the 16 Y subblocks.
+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 `SPLITMV` 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.
+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.
-The DCTs and WHT are tree-coded using a 12-element alphabet whose members we call tokens. Except for the end of block token (which sets the remaining subblock coefficients to zero and is followed by the next block), each token (sometimes augmented with data immediately following the token) specifies the value of the single coefficient at the current (implicit) position and is followed by a token applying to the next (implicit) position.
+The DCTs and WHT are tree-coded using a 12-element alphabet whose
+members we call "tokens". Except for the end-of-block token (which
+sets the remaining subblock coefficients to zero and is followed by
+the next block), each token (sometimes augmented with data
+immediately following the token) specifies the value of the single
+coefficient at the current (implicit) position and is followed by a
+token applying to the next (implicit) position.
-For all the Y and chroma subblocks, the ordering of the coefficients follows a so-called zig-zag order. DCTs begin at coefficient 1 if Y2 is present, and begin at coefficient 0 if Y2 is absent. The WHT for a Y2 subblock always begins at coefficient 0.
+For all the Y and chroma subblocks, the ordering of the coefficients
+follows a so-called zig-zag order. DCTs begin at coefficient 1 if Y2
+is present, and begin at coefficient 0 if Y2 is absent. The WHT for
+a Y2 subblock always begins at coefficient 0.
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 d8b4e47..83f4f88 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
@@ -1,7 +1,9 @@
-#### 13.1 MB Without non-Zero Coefficient Values {#h-13-01}
+#### 13.1 Macroblock 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 (MB) 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 2bbfd90..f2d8500 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
@@ -1,15 +1,22 @@
-#### 13.2 Coding of Individual Coefficient Values {#h-13-02}
+#### 13.2 Coding of Individual Coefficient Values {#h-13-02}
-The coding of coefficient tokens is the same for the DCT and WHT and for the remainder of this chapter DCT should be taken to mean either DCT or WHT.
+The coding of coefficient tokens is the same for the DCT and WHT, and
+for the remainder of this section "DCT" should be taken to mean
+either DCT or WHT.
-All tokens (except end-of-block) specify either a single unsigned value or a range of unsigned values (immediately) followed by a simple probabilistic encoding of the offset of the value from the base of that range.
+All tokens (except end-of-block) specify either a single unsigned
+value or a range of unsigned values (immediately) followed by a
+simple probabilistic encoding of the offset of the value from the
+base of that range.
-Non-zero values (of either type) are then followed by a flag indicating the sign of the coded value (negative if `1`, positive if `0`).
+Non-zero values (of either type) are then followed by a flag
+indicating the sign of the coded value (negative if `1`, positive
+if `0`).
-Here are the tokens and decoding tree.
+Below are the tokens and decoding tree.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -53,9 +60,16 @@
{:lang="c"}
-In general, all DCT coefficients are decoded using the same tree. However, if the preceding coefficient is a `DCT_0`, decoding will skip the first branch since it is not possible for `dct_eob` to follow a `DCT_0`.
+In general, all DCT coefficients are decoded using the same tree.
+However, if the preceding coefficient is a `DCT_0`, decoding will skip
+the first branch, since it is not possible for `dct_eob` to follow a
+`DCT_0`.
-The tokens `dct_cat1` ... `dct_cat6` specify ranges of unsigned values, the value within the range being formed by adding an unsigned offset (whose width is 1, 2, 3, 4, 5, or 11 bits, respectively) to the base of the range, using the following algorithm and fixed probability tables.
+The tokens `dct_cat1` ... `dct_cat6` specify ranges of unsigned values,
+the value within the range being formed by adding an unsigned offset
+(whose width is 1, 2, 3, 4, 5, or 11 bits, respectively) to the base
+of the range, using the following algorithm and fixed probability
+tables.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -76,9 +90,9 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-If `v`, the unsigned value decoded using the coefficient tree, possibly augmented by the process above, is non-zero, its sign is set by simply reading a flag:
-
+If `v` -- the unsigned value decoded using the coefficient tree,
+possibly augmented by the process above -- is non-zero, its sign is
+set by simply reading a flag:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if( read_bool( d, 128))
diff --git a/text_src/13.03__vp8-bitstream__token-probabilities.txt b/text_src/13.03__vp8-bitstream__token-probabilities.txt
index 3c340a0..5ccb512 100644
--- a/text_src/13.03__vp8-bitstream__token-probabilities.txt
+++ b/text_src/13.03__vp8-bitstream__token-probabilities.txt
@@ -1,9 +1,13 @@
-#### 13.3 Token Probabilities {#h-13-03}
+#### 13.3 Token Probabilities {#h-13-03}
-The probability specification for the token tree (unlike that for the "extra bits" described above) is rather involved. It uses three pieces of context to index a large probability table, the contents of which may be incrementally modified in the frame header. The full (non-constant) probability table is laid out as follows.
+The probability specification for the token tree (unlike that for the
+"extra bits" described above) is rather involved. It uses three
+pieces of context to index a large probability table, the contents of
+which may be incrementally modified in the frame header. The full
+(non-constant) probability table is laid out as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -12,14 +16,21 @@
{:lang="c"}
-Working from the outside in, the outermost dimension is indexed by the type of plane being decoded:
+Working from the outside in, the outermost dimension is indexed by
+the type of plane being decoded:
* `0` - Y beginning at coefficient 1 (i.e., Y after Y2)
+
* `1` - Y2
+
* `2` - U or V
+
* `3` - Y beginning at coefficient 0 (i.e., Y in the absence of Y2).
-The next dimension is selected by the position of the coefficient being decoded. That position c steps by ones up to 15, starting from zero for block types 1, 2, or 3 and starting from one for block type 0. The second array index is then
+The next dimension is selected by the position of the coefficient
+being decoded. That position, c, steps by ones up to 15, starting
+from zero for block types 1, 2, or 3 and starting from one for block
+type 0. The second array index is then
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -28,7 +39,7 @@
{:lang="c"}
-where
+Where:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -41,23 +52,65 @@
is a fixed mapping of position to "band".
-The third dimension is the trickiest. Roughly speaking, it measures the "local complexity" or extent to which nearby coefficients are non-zero.
+The third dimension is the trickiest. Roughly speaking, it measures
+the "local complexity" or extent to which nearby coefficients are
+non-zero.
-For the first coefficient (DC, unless the block type is 0), we consider the (already encoded) blocks within the same plane (Y2, Y, U, or V) above and to the left of the current block. The context index is then the number (0, 1 or 2) of these blocks that had at least one non-zero coefficient in their residue record. Specifically for Y2, because macroblocks above and to the left may or may not have a Y2 block, the block above is determined by the most recent macroblock in the same column that has a Y2 block, and the block to the left is determined by the most recent macroblock in the same row that has a Y2 block.
+For the first coefficient (DC, unless the block type is 0), we
+consider the (already encoded) blocks within the same plane (Y2, Y,
+U, or V) above and to the left of the current block. The context
+index is then the number (0, 1, or 2) of these blocks that had at
+least one non-zero coefficient in their residue record. Specifically
+for Y2, because macroblocks above and to the left may or may not have
+a Y2 block, the block above is determined by the most recent
+macroblock in the same column that has a Y2 block, and the block to
+the left is determined by the most recent macroblock in the same row
+that has a Y2 block.
-Beyond the first coefficient, the context index is determined by the absolute value of the most recently decoded coefficient (necessarily within the current block) and is `0` if the last coefficient was a zero, `1` if it was plus or minus one, and `2` if its absolute value exceeded one.
+Beyond the first coefficient, the context index is determined by the
+absolute value of the most recently decoded coefficient (necessarily
+within the current block) and is `0` if the last coefficient was a
+zero, `1` if it was plus or minus one, and `2` if its absolute value
+exceeded one.
-Note that the intuitive meaning of this measure changes as coefficients are decoded. For example, prior to the first token, a zero means that the neighbors are empty, suggesting that the current block may also be empty. After the first token, because an end-of-block token must have at least one non-zero value before it, a zero means that we just decoded a zero and hence guarantees that a non-zero coefficient will appear later in this block. However, this shift in meaning is perfectly okay because the complete context depends also on the coefficient band (and since band 0 is occupied exclusively by position 0).
+Note that the intuitive meaning of this measure changes as
+coefficients are decoded. For example, prior to the first token, a
+zero means that the neighbors are empty, suggesting that the current
+block may also be empty. After the first token, because an end-of-
+block token must have at least one non-zero value before it, a zero
+means that we just decoded a zero and hence guarantees that a non-
+zero coefficient will appear later in this block. However, this
+shift in meaning is perfectly okay because the complete context
+depends also on the coefficient band (and since band 0 is occupied
+exclusively by position 0).
-As with other contexts used by VP8, the "neighboring block" context described here needs a special definition for subblocks lying along the top row or left edge of the frame. These "non-existent" predictors above and to the left of the image are simply taken to be empty -- that is, taken to contain no non-zero coefficients.
+As with other contexts used by VP8, the "neighboring block" context
+described here needs a special definition for subblocks lying along
+the top row or left edge of the frame. These "non-existent"
+predictors above and to the left of the image are simply taken to be
+empty -- that is, taken to contain no non-zero coefficients.
-The residue decoding of each macroblock then requires, in each of two directions (above and to the left), an aggregate coefficient predictor consisting of a single Y2 predictor, two predictors for each of U and V, and four predictors for Y. In accordance with the scan-ordering of macroblocks, a decoder needs to maintain a single "left" aggregate predictor and a row of "above" aggregate predictors.
+The residue decoding of each macroblock then requires, in each of two
+directions (above and to the left), an aggregate coefficient
+predictor consisting of a single Y2 predictor, two predictors for
+each of U and V, and four predictors for Y. In accordance with the
+scan-ordering of macroblocks, a decoder needs to maintain a single
+"left" aggregate predictor and a row of "above" aggregate predictors.
-Before decoding any residue, these maintained predictors may simply be cleared, in compliance with the definition of "non-existent" prediction. After each block is decoded, the two predictors referenced by the block are replaced with the (empty or non-empty) state of the block, in preparation for the later decoding of the blocks below and to the right of the block just decoded.
+Before decoding any residue, these maintained predictors may simply
+be cleared, in compliance with the definition of "non-existent"
+prediction. After each block is decoded, the two predictors
+referenced by the block are replaced with the (empty or non-empty)
+state of the block, in preparation for the later decoding of the
+blocks below and to the right of the block just decoded.
-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 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 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.
+The pseudocode below 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -73,8 +126,8 @@
int extraBits;
bool prevCoeffWasZero = false;
bool currentBlockHasCoeffs = false;
-/* base coeff abs values per each category, elem #0 is
- DCT_VAL_CATEGORY1, * #1 is DCT_VAL_CATEGORY2 etc */
+/* base coeff abs values per each category, elem #0 is
+ DCT_VAL_CATEGORY1, * #1 is DCT_VAL_CATEGORY2, etc. */
int categoryBase[6] = { 5, 7, 11, 19, 35, 67 };
/* Determine plane to use */
@@ -83,14 +136,14 @@
else if ( **current_macroblock_has_Y2** ) plane = 1;
else plane = 3;
-/* For luma blocks of an "Y2 macroblock" we skip coeff index #0 */
+/* For luma blocks of a "Y2 macroblock" we skip coeff index #0 */
if( plane == 1 )
firstCoeff++;
-/* Determine whether neighbour 4x4 blocks have coeffiecients.
- This is dependant of the plane we are currently decoding;
- i.e. we check only coefficients from same plane as current
- block. */
+/* Determine whether neighbor 4x4 blocks have coefficients.
+ This is dependent on the plane we are currently decoding;
+ i.e., we check only coefficients from the same plane as the
+ current block. */
if( **left_neighbor_block_has_coefficients(plane)** )
ctx3++;
if( **above_neighbor_block_has_coefficients(plane)** )
@@ -118,7 +171,7 @@
{
extraBits = DCTextra( token );
absValue =
- categoryBase[**token_to_cat_index(token)**] +
+ categoryBase[**token_to_cat_index(token)**] +
extraBits;
}
else
@@ -138,15 +191,17 @@
if( absValue == 0 ) ctx3 = 0;
else if ( absValue == 1 ) ctx3 = 1;
else ctx3 = 2;
- prevCoeffWasZero = true;
+ prevCoeffWasZero = true;
}
/* Store current block status to decoder internals */
-**block_has_coefficients[currentMb][currentBlock]** =
+**block_has_coefficients[currentMb][currentBlock]** =
currentBlockHasCoeffs;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{: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 `tokens.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`
+(Section 20.16).
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 38edbd8..9d96623 100644
--- a/text_src/13.04__vp8-bitstream__token-probability-updates.txt
+++ b/text_src/13.04__vp8-bitstream__token-probability-updates.txt
@@ -1,11 +1,23 @@
-#### 13.4 Token Probability Updates {#h-13-04}
+#### 13.4 Token Probability Updates {#h-13-04}
-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.
+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 as 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 `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 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:
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 58cbbf0..5c6573c 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
@@ -1,6 +1,6 @@
-#### 13.5 Default Token Probability Table {#h-13-05}
+#### 13.5 Default Token Probability Table {#h-13-05}
The default token probabilities are as follows.
diff --git a/text_src/14.00__vp8-bitstream__dct-and-wht-inversion-and-macroblock-reconstruction.txt b/text_src/14.00__vp8-bitstream__dct-and-wht-inversion-and-macroblock-reconstruction.txt
index 0ce8fd2..10bc356 100644
--- a/text_src/14.00__vp8-bitstream__dct-and-wht-inversion-and-macroblock-reconstruction.txt
+++ b/text_src/14.00__vp8-bitstream__dct-and-wht-inversion-and-macroblock-reconstruction.txt
@@ -1,4 +1,4 @@
-### Chapter 14: DCT and WHT Inversion and Macroblock Reconstruction {#h-14-00}
+### Section 14: DCT and WHT Inversion and Macroblock Reconstruction {#h-14-00}
diff --git a/text_src/14.01__vp8-bitstream__dequantization.txt b/text_src/14.01__vp8-bitstream__dequantization.txt
index 7952d1b..b6c2138 100644
--- a/text_src/14.01__vp8-bitstream__dequantization.txt
+++ b/text_src/14.01__vp8-bitstream__dequantization.txt
@@ -1,15 +1,25 @@
-#### 14.1 Dequantization {#h-14-01}
+#### 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 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.
+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 Section 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.
-
+The two dequantization tables, which may also be found in the
+reference decoder file `dequant_data.h` (Section 20.3), are as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-static const int dc_qlookup[QINDEX_RANGE] =
+static const int dc_qlookup[QINDEX_RANGE] =
{
4, 5, 6, 7, 8, 9, 10, 10, 11, 12, 13, 14, 15,
16, 17, 17, 18, 19, 20, 20, 21, 21, 22, 22, 23, 23,
@@ -19,11 +29,11 @@
60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72,
73, 74, 75, 76, 76, 77, 78, 79, 80, 81, 82, 83, 84,
85, 86, 87, 88, 89, 91, 93, 95, 96, 98, 100, 101, 102,
- 104, 106, 108, 110, 112, 114, 116, 118, 122, 124, 126, 128, 130,
+ 104, 106, 108, 110, 112, 114, 116, 118, 122, 124, 126, 128, 130,
132, 134, 136, 138, 140, 143, 145, 148, 151, 154, 157,
};
-static const int ac_qlookup[QINDEX_RANGE] =
+static const int ac_qlookup[QINDEX_RANGE] =
{
4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
@@ -40,5 +50,9 @@
{:lang="c"}
-Lookup values from the above two tables are directly used the DC and AC coefficients in Y1 respectively. For Y2 and chroma, values from above tables undergo either a scaling process or clamping processing before the multiplies. Details to these scaling and clamping can be found related lookup functions in `dixie.c`.
+Lookup values from the above two tables are directly used in the DC
+and AC coefficients in Y1, respectively. For Y2 and chroma, values
+from the above tables undergo either scaling or clamping before the
+multiplies. Details regarding these scaling and clamping processes
+can be found in related lookup functions in `dixie.c`(Section 20.4).
diff --git a/text_src/14.02__vp8-bitstream__inverse-transforms.txt b/text_src/14.02__vp8-bitstream__inverse-transforms.txt
index 928b0c3..2b70b73 100644
--- a/text_src/14.02__vp8-bitstream__inverse-transforms.txt
+++ b/text_src/14.02__vp8-bitstream__inverse-transforms.txt
@@ -1,11 +1,25 @@
-#### 14.2 Inverse Transforms {#h-14-02}
+#### 14.2 Inverse Transforms {#h-14-02}
-If the Y2 residue block exists (i.e., the macroblock luma mode is not `SPLITMV` or `B_PRED`), it is inverted first (using the inverse WHT) and the element of the result at row i, column j is used as the 0<sup>th</sup> coefficient of the Y subblock at position (i, j), that is, the Y subblock whose index is (i * 4) + j. As discussed in Chapter 13, if the luma mode is `B_PRED` or `SPLITMV`, the 0<sup>th</sup> Y coefficients are part of the residue signal for the subblocks themselves.
+If the Y2 residue block exists (i.e., the macroblock luma mode is not
+`SPLITMV` or `B_PRED`), it is inverted first (using the inverse WHT) and
+the element of the result at row i, column j is used as the 0th
+coefficient of the Y subblock at position (i, j), that is, the Y
+subblock whose index is (i * 4) + j. As discussed in Section 13, if
+the luma mode is `B_PRED` or `SPLITMV`, the 0th Y coefficients are part
+of the residue signal for the subblocks themselves.
-In either case, the inverse transforms for the sixteen Y subblocks and eight chroma subblocks are computed next. All 24 of these inversions are independent of each other; their results may (at least conceptually) be stored in 24 separate 4x4 arrays.
+In either case, the inverse transforms for the sixteen Y subblocks
+and eight chroma subblocks are computed next. All 24 of these
+inversions are independent of each other; their results may (at least
+conceptually) be stored in 24 separate 4x4 arrays.
-As is done by the reference decoder, an implementation may wish to represent the prediction and residue buffers as macroblock-sized arrays (that is, a 16x16 Y buffer and two 8x8 chroma buffers). Regarding the inverse DCT implementation given below, this requires a simple adjustment to the address calculation for the resulting residue pixels.
+As is done by the reference decoder, an implementation may wish to
+represent the prediction and residue buffers as macroblock-sized
+arrays (that is, a 16x16 Y buffer and two 8x8 chroma buffers).
+Regarding the inverse DCT implementation given below, this requires a
+simple adjustment to the address calculation for the resulting
+residue pixels.
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 f127926..054b81d 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
@@ -1,14 +1,23 @@
-#### 14.3 Implementation of the WHT Inversion {#h-14-03}
+#### 14.3 Implementation of the WHT Inversion {#h-14-03}
-As previously discussed (see Chapters 2 and 13), for macroblocks encoded using prediction modes other than `B_PRED` and `SPLITMV`, the DC values derived from the DCT transform on the 16 Y blocks are collected to construct a 25th block of a macroblock (16 Y, 4 U, 4 V constitute the 24 blocks). This 25th block is transformed using a Walsh-Hadamard transform (WHT).
+As previously discussed (see Sections 2 and 13), for macroblocks
+encoded using prediction modes other than `B_PRED` and `SPLITMV`, the DC
+values derived from the DCT transform on the 16 Y blocks are
+collected to construct a 25th block of a macroblock (16 Y, 4 U, 4 V
+constitute the 24 blocks). This 25th block is transformed using a
+Walsh-Hadamard transform (WHT).
-The inputs to the inverse WHT (that is, the dequantized coefficients), the intermediate "horizontally detransformed" signal, and the completely detransformed residue signal are all stored as arrays of 16-bit signed integers.
+The inputs to the inverse WHT (that is, the dequantized
+coefficients), the intermediate "horizontally detransformed" signal,
+and the completely detransformed residue signal are all stored as
+arrays of 16-bit signed integers.
-Following the tradition of specifying bitstream format using the decoding process, we specify the inverse WHT in the decoding process using the following C style source code:
-
+Following the tradition of specifying bitstream format using the
+decoding process, we specify the inverse WHT in the decoding process
+using the following C-style source code:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void vp8_short_inv_walsh4x4_c(short *input, short *output)
@@ -60,9 +69,8 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-In the case that there is only one non-zero DC value in input, the inverse transform can be simplified to the following:
-
+In the case that there is only one non-zero DC value in input, the
+inverse transform can be simplified to the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void vp8_short_inv_walsh4x4_1_c(short *input, short *output)
@@ -71,8 +79,6 @@
int a1;
short *op=output;
-
-
a1 = ((input[0] + 3)>>3);
for(i=0;i<4;i++)
@@ -87,8 +93,11 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
+It should be noted that 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.
-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 file `idct_add.c`.
+The reference decoder WHT inversion may be found in the file
+`idct_add.c` (Section 20.8).
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 dfeaada..648be68 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
@@ -1,27 +1,48 @@
-#### 14.4 Implementation of the DCT Inversion {#h-14-04}
+#### 14.4 Implementation of the DCT Inversion {#h-14-04}
-All of the DCT inversions are computed in exactly the same way. In principle, VP8 uses a classical 2D inverse discrete cosine transform, implemented as two passes of 1-D inverse DCT. The 1-D inverse DCT was calculated using a similar algorithm to what was described in the paper "Practical Fast 1-D DCT Algorithms with 11 Multiplications" by Loeffler, Lightenberg and Moschytz. However, the paper only provided the 8-point and 16-point version of the algorithms, which was adapted by On2 to perform the 4-point 1-D DCT.
+All of the DCT inversions are computed in exactly the same way. In
+principle, VP8 uses a classical 2-D inverse discrete cosine
+transform, implemented as two passes of 1-D inverse DCT. The 1-D
+inverse DCT was calculated using a similar algorithm to what was
+described in [Loeffler]. However, the paper only provided the
+8-point and 16-point version of the algorithms, which was adapted by
+On2 to perform the 4-point 1-D DCT.
-Accurate calculation of 1-D DCT of the above algorithm requires infinite precision. VP8 of course can use only a finite-precision approximation. Also, the inverse DCT used by VP8 takes care of normalization of the standard unitary transform, that is, every dequantized coefficient has roughly double the size of the corresponding unitary coefficient. However, at all but the highest datarates, the discrepancy between transmitted and ideal coefficients is due almost entirely to (lossy) compression and not to errors induced by finite-precision arithmetic.
+Accurate calculation of 1-D DCT of the above algorithm requires
+infinite precision. VP8 of course can use only a finite-precision
+approximation. Also, the inverse DCT used by VP8 takes care of
+normalization of the standard unitary transform; that is, every
+dequantized coefficient has roughly double the size of the
+corresponding unitary coefficient. However, at all but the highest
+datarates, the discrepancy between transmitted and ideal coefficients
+is due almost entirely to (lossy) compression and not to errors
+induced by finite-precision arithmetic.
-The inputs to the inverse DCT (that is, the dequantized coefficients), the intermediate "horizontally detransformed" signal, and the completely detransformed residue signal are all stored as arrays of 16-bit signed integers. The details of the computation are as follows.
+The inputs to the inverse DCT (that is, the dequantized
+coefficients), the intermediate "horizontally detransformed" signal,
+and the completely detransformed residue signal are all stored as
+arrays of 16-bit signed integers. The details of the computation are
+as follows.
-It should also be noted that this implementation makes use of 16-bit fixed point version of two multiplication constants:
+It should also be noted that this implementation makes use of the
+16-bit fixed-point version of two multiplication constants:
-[[ sqrt(2) * cos (pi/8) ]]
+sqrt(2) * cos (pi/8)
-[[ sqrt(2) * sin (pi/8) ]]
+sqrt(2) * sin (pi/8)
-Because the first constant is bigger than 1, to maintain the same 16-bit fixed point precision as the second one, we make use of the fact that
+Because the first constant is bigger than 1, to maintain the same
+16-bit fixed-point precision as the second one, we make use of the
+fact that
-[[ x * a = x + x*(a-1) ]]
+x * a = x + x*(a-1)
therefore
-[[ x * sqrt(2) * cos (pi/8) = x + x * ( sqrt(2) * cos(pi/8)-1) ]]
+x * sqrt(2) * cos (pi/8) = x + x * ( sqrt(2) * cos(pi/8)-1)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -40,7 +61,7 @@
for(i=0;i<4;i++)
{
- a1 = ip[0]+ip[8];
+ a1 = ip[0]+ip[8];
b1 = ip[0]-ip[8];
temp1 = (ip[4] * sinpi8sqrt2)>>16;
@@ -87,5 +108,6 @@
{:lang="c"}
-The reference decoder DCT inversion may be found in the file `idct_add.c`.
+The reference decoder DCT inversion may be found in the file
+`idct_add.c` (Section 20.8).
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 8fe75b1..ab7d172 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
@@ -1,13 +1,28 @@
-#### 14.5 Summation of Predictor and Residue {#h-14-05}
+#### 14.5 Summation of Predictor and Residue {#h-14-05}
-Finally, the prediction and residue signals are summed to form the reconstructed macroblock, which, except for loop filtering (taken up next), completes the decoding process.
+Finally, the prediction and residue signals are summed to form the
+reconstructed macroblock, which, except for loop filtering (taken up
+next), completes the decoding process.
-The summing procedure is fairly straightforward, having only a couple of details. The prediction and residue buffers are both arrays of 16-bit signed integers. Each individual (Y, U, and V pixel) result is calculated first as a 32-bit sum of the prediction and residue, and is then saturated to 8-bit unsigned range (using, say, the `clamp255` function defined above) before being stored as an 8-bit unsigned pixel value.
+The summing procedure is fairly straightforward, having only a couple
+of details. The prediction and residue buffers are both arrays of
+16-bit signed integers. Each individual (Y, U, and V pixel) result
+is calculated first as a 32-bit sum of the prediction and residue,
+and is then saturated to 8-bit unsigned range (using, say, the
+`clamp255` function defined above) before being stored as an 8-bit
+unsigned pixel value.
-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.
+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 a case, the `clamp255` function 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 `idct_add.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.00__vp8-bitstream__loop-filter.txt b/text_src/15.00__vp8-bitstream__loop-filter.txt
index 5a720b4..ef47005 100644
--- a/text_src/15.00__vp8-bitstream__loop-filter.txt
+++ b/text_src/15.00__vp8-bitstream__loop-filter.txt
@@ -1,19 +1,46 @@
-### Chapter 15: Loop Filter {#h-15-00}
+### Section 15: Loop Filter {#h-15-00}
-Loop filtering is the last stage of frame reconstruction and the next-to-last stage of the decoding process. The loop filter is applied to the entire frame after the summation of predictor and residue described in Chapter 14.
+Loop filtering is the last stage of frame reconstruction and the
+next-to-last stage of the decoding process. The loop filter is
+applied to the entire frame after the summation of predictor and
+residue signals, as described in Section 14.
-The purpose of the loop filter is to eliminate (or at least reduce) visually objectionable artifacts associated with the semi-independence of the coding of macroblocks and their constituent subblocks.
+The purpose of the loop filter is to eliminate (or at least reduce)
+visually objectionable artifacts associated with the semi-
+independence of the coding of macroblocks and their constituent
+subblocks.
-As was discussed in Chapter 5, the loop filter is "integral" to decoding, in that the results of loop filtering are used in the prediction of subsequent frames. Consequently, a functional decoder implementation must perform loop filtering exactly as described here. This is in distinction to any postprocessing that may be applied only to the image immediately before display; such postprocessing is entirely at the option of the implementor (and/or user) and has no effect on decoding per se.
+As was discussed in Section 5, the loop filter is "integral" to
+decoding, in that the results of loop filtering are used in the
+prediction of subsequent frames. Consequently, a functional decoder
+implementation must perform loop filtering exactly as described here.
+This is distinct from any postprocessing that may be applied only to
+the image immediately before display; such postprocessing is entirely
+at the option of the implementor (and/or user) and has no effect on
+decoding per se.
-The baseline frame level parameters controlling the loop filter are defined in the frame header (Chapter 9.4) along with a mechanism for adjustment based on a macroblock's prediction mode and/or reference frame. The first is a flag selecting the type of filter (normal or simple), the other two are numbers (`loop_filter_level` and `sharpness_level`) that adjust the strength or sensitivity of the filter. As described in Chapters 9.3 and 10, `loop_filter_level` may also be overridden on a per-macroblock basis using segmentation.
+The baseline frame-level parameters controlling the loop filter are
+defined in the frame header (Section 9.4) along with a mechanism for
+adjustment based on a macroblock's prediction mode and/or reference
+frame. The first is a flag (`filter_type`) selecting the type of
+filter (normal or simple); the other two are numbers
+(`loop_filter_level` and `sharpness_level`) that adjust the strength or
+sensitivity of the filter. As described in Sections 9.3 and 10,
+`loop_filter_level` may also be overridden on a per-macroblock basis
+using segmentation.
-Loop filtering is one of the more computationally-intensive aspects of VP8 decoding. This is the reason for the existence of the optional, less-demanding simple filter type.
+Loop filtering is one of the more computationally intensive aspects
+of VP8 decoding. This is the reason for the existence of the
+optional, less-demanding simple filter type.
-Note carefully that loop filtering must be skipped entirely if `loop_filter_level` at either the frame header level or macroblock override level is `0`. In no case should the loop filter be run with a value of `0`; it should instead be skipped.
+Note carefully that loop filtering must be skipped entirely if
+`loop_filter_level` at either the frame header level or macroblock
+override level is `0`. In no case should the loop filter be run with a
+value of `0`; it should instead be skipped.
-We begin by discussing the aspects of loop filtering that are independent of the controlling parameters and type of filter chosen.
+We begin by discussing the aspects of loop filtering that are
+independent of the controlling parameters and type of filter chosen.
diff --git a/text_src/15.01__vp8-bitstream__filter-geometry-and-overall-procedure.txt b/text_src/15.01__vp8-bitstream__filter-geometry-and-overall-procedure.txt
index a8ec9ed..059d277 100644
--- a/text_src/15.01__vp8-bitstream__filter-geometry-and-overall-procedure.txt
+++ b/text_src/15.01__vp8-bitstream__filter-geometry-and-overall-procedure.txt
@@ -1,43 +1,106 @@
-#### 15.1 Filter Geometry and Overall Procedure {#h-15-01}
+#### 15.1 Filter Geometry and Overall Procedure {#h-15-01}
The Y, U, and V planes are processed independently and identically.
-The loop filter acts on the edges between adjacent macroblocks and on the edges between adjacent subblocks of a macroblock. All such edges are horizontal or vertical. For each pixel position on an edge, a small number (two or three) of pixels adjacent to either side of the position are examined and possibly modified. The displacements of these pixels are at a right angle to the edge orientation, that is, for a horizontal edge, we treat the pixels immediately above and below the edge position, for a vertical edge, we treat the pixels immediately to the left and right of the edge.
+The loop filter acts on the edges between adjacent macroblocks and on
+the edges between adjacent subblocks of a macroblock. All such edges
+are horizontal or vertical. For each pixel position on an edge, a
+small number (two or three) of pixels adjacent to either side of the
+position are examined and possibly modified. The displacements of
+these pixels are at a right angle to the edge orientation; that is,
+for a horizontal edge, we treat the pixels immediately above and
+below the edge position, and for a vertical edge, we treat the pixels
+immediately to the left and right of the edge.
-We call this collection of pixels associated to an edge position a segment; the length of a segment is 2, 4, 6, or 8. Excepting that the normal filter uses slightly different algorithms for, and that either filter may apply different control parameters to, the edges between macroblocks and those between subblocks, the treatment of edges is quite uniform: All segments straddling an edge are treated identically, there is no distinction between the treatment of horizontal and vertical edges, whether between macroblocks or between subblocks.
+We call this collection of pixels associated to an edge position a
+segment; the length of a segment is 2, 4, 6, or 8. Excepting that
+the normal filter uses slightly different algorithms for, and either
+filter may apply different control parameters to, the edges between
+macroblocks and those between subblocks, the treatment of edges is
+quite uniform: All segments straddling an edge are treated
+identically; there is no distinction between the treatment of
+horizontal and vertical edges, whether between macroblocks or between
+subblocks.
-As a consequence, adjacent subblock edges within a macroblock may be concatenated and processed in their entirety. There is a single 8-pixel long vertical edge horizontally centered in each of the U and V blocks (the concatenation of upper and lower 4-pixel edges between chroma subblocks), and three 16-pixel long vertical edges at horizontal positions 1/4, 1/2, and 3/4 the width of the luma macroblock, each representing the concatenation of four 4-pixel sub-edges between pairs of Y subblocks.
+As a consequence, adjacent subblock edges within a macroblock may be
+concatenated and processed in their entirety. There is a single
+8-pixel-long vertical edge horizontally centered in each of the U and
+V blocks (the concatenation of upper and lower 4-pixel edges between
+chroma subblocks), and three 16-pixel-long vertical edges at
+horizontal positions 1/4, 1/2, and 3/4 the width of the luma
+macroblock, each representing the concatenation of four 4-pixel
+sub-edges between pairs of Y subblocks.
-The macroblocks comprising the frame are processed in the usual raster-scan order. Each macroblock is "responsible for" the inter-macroblock edges immediately above and left of it (but not the edges below and right of it), as well as the edges between its subblocks.
+The macroblocks comprising the frame are processed in the usual
+raster-scan order. Each macroblock is "responsible for" the inter-
+macroblock edges immediately above and to the left of it (but not the
+edges below and to the right of it), as well as the edges between its
+subblocks.
-For each macroblock M, there are four filtering steps, which are, (almost) in order:
+For each macroblock M, there are four filtering steps, which are,
+(almost) in order:
- 1. If M is not on the leftmost column of macroblocks, filter
- across the left (vertical) inter-macroblock edge of M.
- 2. Filter across the vertical subblock edges within M.
- 3. If M is not on the topmost row of macroblocks, filter across
- the top (horizontal) inter-macroblock edge of M.
- 4. Filter across the horizontal subblock edges within M.
+ 1. If M is not on the leftmost column of macroblocks, filter across
+ the left (vertical) inter-macroblock edge of M.
-We write MY, MU, and MV for the planar constituents of M, that is, the 16x16 luma block, 8x8 U block, and 8x8 V block comprising M.
+ 2. Filter across the vertical subblock edges within M.
-In step 1, for each of the three blocks MY, MU, and MV, we filter each of the (16 luma or 8 chroma) segments straddling the column separating the block from the block immediately to the left of it, using the inter-macroblock filter and controls associated to the `loop_filter_level` and `sharpness_level`.
+ 3. If M is not on the topmost row of macroblocks, filter across the
+ top (horizontal) inter-macroblock edge of M.
-In step 4, we filter across the (three luma and one each for U and V) vertical subblock edges described above, this time using the inter-subblock filter and controls.
+ 4. Filter across the horizontal subblock edges within M.
-Step 2 and 4 are skipped for macroblocks that satisfy both of the following two conditions:
+We write MY, MU, and MV for the planar constituents of M, that is,
+the 16x16 luma block, 8x8 U block, and 8x8 V block comprising M.
- 1. Macroblock coding mode is neither `B_PRED` nor `SPLTMV`; and
- 2. There is no DCT coefficient coded for the whole macroblock.
+In step 1, for each of the three blocks MY, MU, and MV, we filter
+each of the (16 luma or 8 chroma) segments straddling the column
+separating the block from the block immediately to the left of it,
+using the inter-macroblock filter and controls associated to the
+`loop_filter_level` and `sharpness_level`.
-For these macroblocks, loop filtering for edges between subblocks internal to a macroblock is effectively skipped. This skip strategy significantly reduces VP8 loop-filtering complexity.
+In step 4, we filter across the (three luma and one each for U and V)
+vertical subblock edges described above, this time using the
+inter-subblock filter and controls.
-Edges between macroblocks and those between subblocks are treated with different control parameters (and, in the case of the normal filter, with different algorithms). Except for pixel addressing, there is no distinction between the treatment of vertical and horizontal edges. Luma edges are always 16 pixels long, chroma edges are always 8 pixels long, and the segments straddling an edge are treated identically; this of course facilitates vector processing.
+Steps 2 and 4 are skipped for macroblocks that satisfy both of the
+following two conditions:
-Because many pixels belong to segments straddling two or more edges, and so will be filtered more than once, the order in which edges are processed given above must be respected by any implementation. Within a single edge, however, the segments straddling that edge are disjoint and the order in which these segments are processed is immaterial.
+ 1. Macroblock coding mode is neither `B_PRED` nor `SPLITMV`; and
-Before taking up the filtering algorithms themselves, we should emphasize a point already made: Even though the pixel segments associated to a macroblock are antecedent to the macroblock (that is, lie within the macroblock or in already-constructed macroblocks), a macroblock must not be filtered immediately after its "reconstruction" (described in Chapter 14). Rather, the loop filter applies after all the macroblocks have been "reconstructed" (i.e., had their predictor summed with their residue); correct decoding is predicated on the fact that already-constructed portions of the current frame referenced via intra-prediction (described in Chapter 12) are not yet filtered.
+ 2. There is no DCT coefficient coded for the whole macroblock.
+
+For these macroblocks, loop filtering for edges between subblocks
+internal to a macroblock is effectively skipped. This skip strategy
+significantly reduces VP8 loop-filtering complexity.
+
+Edges between macroblocks and those between subblocks are treated
+with different control parameters (and, in the case of the normal
+filter, with different algorithms). Except for pixel addressing,
+there is no distinction between the treatment of vertical and
+horizontal edges. Luma edges are always 16 pixels long, chroma edges
+are always 8 pixels long, and the segments straddling an edge are
+treated identically; this of course facilitates vector processing.
+
+Because many pixels belong to segments straddling two or more edges,
+and so will be filtered more than once, the order in which edges are
+processed given above must be respected by any implementation.
+Within a single edge, however, the segments straddling that edge are
+disjoint, and the order in which these segments are processed is
+immaterial.
+
+Before taking up the filtering algorithms themselves, we should
+emphasize a point already made: Even though the pixel segments
+associated to a macroblock are antecedent to the macroblock (that is,
+lie within the macroblock or in already-constructed macroblocks), a
+macroblock must not be filtered immediately after its
+"reconstruction" (described in Section 14). Rather, the loop filter
+applies after all the macroblocks have been "reconstructed" (i.e.,
+had their predictor summed with their residue); correct decoding is
+predicated on the fact that already-constructed portions of the
+current frame referenced via intra-prediction (described in Section
+12) are not yet filtered.
diff --git a/text_src/15.02__vp8-bitstream__simple-filter.txt b/text_src/15.02__vp8-bitstream__simple-filter.txt
index 069ea78..a6466cc 100644
--- a/text_src/15.02__vp8-bitstream__simple-filter.txt
+++ b/text_src/15.02__vp8-bitstream__simple-filter.txt
@@ -1,17 +1,33 @@
-#### 15.2 Simple Filter {#h-15-02}
+#### 15.2 Simple Filter {#h-15-02}
-Having described the overall procedure of, and pixels affected by, the loop filter, we turn our attention to the treatment of individual segments straddling edges. We begin by describing the simple filter, which, as the reader might guess, is somewhat simpler than the normal filter.
+Having described the overall procedure of, and pixels affected by,
+the loop filter, we turn our attention to the treatment of individual
+segments straddling edges. We begin by describing the simple filter,
+which, as the reader might guess, is somewhat simpler than the normal
+filter.
-Note that the simple filter only applies to luma edges. Chroma edges are left unfiltered.
+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 quantizer 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.
+Most of the filtering arithmetic is done using 8-bit signed operands
+(having a range of -128 to +127, inclusive), supplemented by 16-bit
+temporaries holding results of multiplies.
-Sums and other temporaries need to be "clamped" to a valid signed 8-bit range:
+Sums and other temporaries need to be "clamped" to a valid signed
+8-bit range:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -23,7 +39,8 @@
{:lang="c"}
-Since pixel values themselves are unsigned 8-bit numbers, we need to convert between signed and unsigned values:
+Since pixel values themselves are unsigned 8-bit numbers, we need to
+convert between signed and unsigned values:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -37,7 +54,11 @@
{:lang="c"}
-Filtering is often predicated on absolute-value thresholds. The following function is the equivalent of the standard library function `abs`, whose prototype is found in the standard header file `stdlib.h`. For us, the argument `v` is always the difference between two pixels and lies in the range [[ -255 <= v <= +255 ]].
+Filtering is often predicated on absolute-value thresholds. The
+following function is the equivalent of the standard library function
+abs, whose prototype is found in the standard header file `stdlib.h`.
+For us, the argument v is always the difference between two pixels
+and lies in the range -255 <= v <= +255.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -46,14 +67,33 @@
{: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 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.
+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".
+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".
-Given an edge, a segment, and a limit value, the simple loop filter computes a value based on the four pixels that straddle the edge (two either side). If that value is below a supplied limit, then, very roughly speaking, the two pixel values are brought closer to each other, "shaving off" something like a quarter of the difference. The same procedure is used for all segments straddling any type of edge, regardless of the nature (inter-macroblock, inter-subblock, luma, or chroma) of the edge; only the limit value depends on the edge-type.
+Given an edge, a segment, and a limit value, the simple loop filter
+computes a value based on the four pixels that straddle the edge (two
+either side). If that value is below a supplied limit, then, very
+roughly speaking, the two pixel values are brought closer to each
+other, "shaving off" something like a quarter of the difference. The
+same procedure is used for all segments straddling any type of edge,
+regardless of the nature (inter-macroblock, inter-subblock, luma, or
+chroma) of the edge; only the limit value depends on the edge type.
-The exact procedure (for a single segment) is as follows; the subroutine common_adjust is used by both the simple filter presented here and the normal filters discussed in [Section 15.3](#h-15-03).
-
+The exact procedure (for a single segment) is as follows; the
+subroutine common_adjust is used by both the simple filter presented
+here and the normal filters discussed in Section 15.3.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int8 common_adjust(
@@ -69,13 +109,13 @@
cint8 q1 = u2s( *Q1);
/* Disregarding clamping, when "use_outer_taps" is false,
- "a" is 3*(q0-p0). Since we are about to divide "a" by
+ "a" is 3*(q0-p0). Since we are about to divide "a" by
8, in this case we end up multiplying the edge
difference by 5/8.
When "use_outer_taps" is true (as for the simple filter),
"a" is p1 - 3*p0 + 3*q0 - q1, which can be thought of as
- a refinement of 2*(q0 - p0) and the adjustment is
+ a refinement of 2*(q0 - p0), and the adjustment is
something like (q0 - p0)/4. */
int8 a = c( ( use_outer_taps? c(p1 - q1) : 0 ) + 3*(q0 - p0) );
@@ -86,8 +126,8 @@
cint8 b = (c(a + 3)) >> 3;
/* Divide a by 8, rounding up when f >= 1/2.
- Although not strictly part of the "C" language,
- the right-shift is assumed to propagate the sign bit. */
+ Although not strictly part of the C language,
+ the right shift is assumed to propagate the sign bit. */
a = c( a + 4) >> 3;
@@ -118,16 +158,31 @@
Pixel *Q0, /* pixel after edge */
const Pixel *Q1 /* pixel after Q0 */
) {
- if( (abs(*P0 - *Q0)*2 + abs(*P1-*Q1)/2) <= edge_limit))
+ if( (abs(*P0 - *Q0)*2 + abs(*P1 - *Q1)/2) <= edge_limit))
common_adjust( 1, P1, P0, Q0, Q1); /* use outer taps */
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-We make a couple of remarks about the rounding procedure above. When `b` is zero (that is, when the "fractional part" of `a` is not 1/2 ), we are (except for clamping) adding the same number to `p0` as we are subtracting from `q0`. This preserves the average value of `p0` and `q0` but the resulting difference between `p0` and `q0` is always even; in particular, the smallest non-zero gradation [[ +-1 ]] is not possible here.
+We make a couple of remarks about the rounding procedure above. When
+`b` is zero (that is, when the "fractional part" of `a` is not 1/2), we
+are (except for clamping) adding the same number to `p0` as we are
+subtracting from `q0`. This preserves the average value of `p0` and `q0`,
+but the resulting difference between `p0` and `q0` is always even; in
+particular, the smallest non-zero gradation +-1 is not possible here.
-When `b` is one, the value we add to `p0` (again except for clamping) is one less than the value we are subtracting from `q0`. In this case, the resulting difference is always odd (and the small gradation [[ +-1 ]] is possible) but the average value is reduced by 1/2, yielding, for instance, a very slight darkening in the luma plane. (In the very unlikely event of appreciable darkening after a large number of interframes, a compressor would of course eventually compensate for this in the selection of predictor and/or residue.)
+When `b` is one, the value we add to `p0` (again except for clamping) is
+one less than the value we are subtracting from `q0`. In this case,
+the resulting difference is always odd (and the small gradation +-1
+is possible), but the average value is reduced by 1/2, yielding, for
+instance, a very slight darkening in the luma plane. (In the very
+unlikely event of appreciable darkening after a large number of
+interframes, a compressor would of course eventually compensate for
+this in the selection of predictor and/or residue.)
-The derivation of the `edge_limit` value used above, which depends on the `loop_filter_level` and `sharpness_level`, as well as the type of edge being processed, will be taken up after we describe the normal loop filtering algorithm below.
+The derivation of the `edge_limit` value used above, which depends on
+the `loop_filter_level` and `sharpness_level`, as well as the type of
+edge being processed, will be taken up after we describe the normal
+loop filtering algorithm below.
diff --git a/text_src/15.03__vp8-bitstream__normal-filter.txt b/text_src/15.03__vp8-bitstream__normal-filter.txt
index 92856f5..92ac811 100644
--- a/text_src/15.03__vp8-bitstream__normal-filter.txt
+++ b/text_src/15.03__vp8-bitstream__normal-filter.txt
@@ -1,45 +1,53 @@
-#### 15.3 Normal Filter {#h-15-03}
+#### 15.3 Normal Filter {#h-15-03}
-The normal loop filter is a refinement of the simple loop filter; all of the general discussion above applies here as well. In particular, the functions `c`, `u2s`, `s2u`, `abs`, and `common_adjust` are used by both the normal and simple filters.
+The normal loop filter is a refinement of the simple loop filter; all
+of the general discussion above applies here as well. In particular,
+the functions `c`, `u2s`, `s2u`, `abs`, and `common_adjust` are used by both
+the normal and simple filters.
-As mentioned above, the normal algorithms for inter-macroblock and inter-subblock edges differ. Nonetheless, they have a great deal in common: They use similar threshold algorithms to disable the filter and to detect high internal edge variance (which influences the filtering algorithm). Both algorithms also use, at least conditionally, the simple filter adjustment procedure described above.
+As mentioned above, the normal algorithms for inter-macroblock and
+inter-subblock edges differ. Nonetheless, they have a great deal in
+common: They use similar threshold algorithms to disable the filter
+and to detect high internal edge variance (which influences the
+filtering algorithm). Both algorithms also use, at least
+conditionally, the simple filter adjustment procedure described
+above.
The common thresholding algorithms are as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/* All functions take (among other things) a segment (of length
+/* All functions take (among other things) a segment (of length
at most 4 + 4 = 8) symmetrically straddling an edge.
- The pixel values (or pointers) are always given in order,
- from the "beforemost" to the "aftermost". So, for a
- horizontal edge (written "|"), an 8-pixel segment would be
+ The pixel values (or pointers) are always given in order,
+ from the "beforemost" to the "aftermost". So, for a
+ horizontal edge (written "|"), an 8-pixel segment would be
ordered p3 p2 p1 p0 | q0 q1 q2 q3. */
-
-/* Filtering is disabled if the difference between any two
- adjacent "interior" pixels in the 8-pixel segment exceeds
- the relevant threshold (I). A more complex thresholding
- calculation is done for the group of four pixels that
- straddle the edge, in line with the calculation in
+/* Filtering is disabled if the difference between any two
+ adjacent "interior" pixels in the 8-pixel segment exceeds
+ the relevant threshold (I). A more complex thresholding
+ calculation is done for the group of four pixels that
+ straddle the edge, in line with the calculation in
simple_segment() above. */
int filter_yes(
uint8 I, /* limit on interior differences */
uint8 E, /* limit at the edge */
- cint8 p3, cint8 p2, cint8 p1, cint8 p0, /* pixels before
+ cint8 p3, cint8 p2, cint8 p1, cint8 p0, /* pixels before
edge */
- cint8 q0, cint8 q1, cint8 q2, cint8 q3 /* pixels after
+ cint8 q0, cint8 q1, cint8 q2, cint8 q3 /* pixels after
edge */
) {
- return (abs(p0 - q0)*2 + abs(p1-q1)/2) <= E
- && abs(p3 - p2) <= I && abs(p2 - p1) <= I &&
+ return (abs(p0 - q0)*2 + abs(p1 - q1)/2) <= E
+ && abs(p3 - p2) <= I && abs(p2 - p1) <= I &&
abs(p1 - p0) <= I
- && abs(q3 - q2) <= I && abs(q2 - q1) <= I &&
+ && abs(q3 - q2) <= I && abs(q2 - q1) <= I &&
abs(q1 - q0) <= I;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -47,8 +55,8 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/* Filtering is altered if (at least) one of the differences
- on either side of the edge exceeds a threshold (we have
+/* Filtering is altered if (at least) one of the differences
+ on either side of the edge exceeds a threshold (we have
"high edge variance"). */
int hev(
@@ -61,25 +69,31 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-The subblock filter is a variant of the simple filter. In fact, if we have high edge variance, the adjustment is exactly as for the simple filter. Otherwise, the simple adjustment (without outer taps) is applied and the two pixels one step in from the edge pixels are adjusted by roughly half the amount by which the two edge pixels are adjusted; since the edge adjustment here is essentially 3/8 the edge difference, the inner adjustment is approximately 3/16 the edge difference.
+The subblock filter is a variant of the simple filter. In fact, if
+we have high edge variance, the adjustment is exactly as for the
+simple filter. Otherwise, the simple adjustment (without outer taps)
+is applied, and the two pixels one step in from the edge pixels are
+adjusted by roughly half the amount by which the two edge pixels are
+adjusted; since the edge adjustment here is essentially 3/8 the edge
+difference, the inner adjustment is approximately 3/16 the edge
+difference.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void subblock_filter(
uint8 hev_threshold, /* detect high edge variance */
uint8 interior_limit, /* possibly disable filter */
uint8 edge_limit,
- cint8 *P3, cint8 *P2, int8 *P1, int8 *P0, /* pixels before
+ cint8 *P3, cint8 *P2, int8 *P1, int8 *P0, /* pixels before
edge */
- int8 *Q0, int8 *Q1, cint8 *Q2, cint8 *Q3 /* pixels after
+ int8 *Q0, int8 *Q1, cint8 *Q2, cint8 *Q3 /* pixels after
edge */
) {
- cint8 p3 = u2s(*P3), p2 = u2s(*P2), p1 = u2s(*P1),
+ cint8 p3 = u2s(*P3), p2 = u2s(*P2), p1 = u2s(*P1),
p0 = u2s(*P0);
- cint8 q0 = u2s(*Q0), q1 = u2s(*Q1), q2 = u2s(*Q2),
+ cint8 q0 = u2s(*Q0), q1 = u2s(*Q1), q2 = u2s(*Q2),
q3 = u2s(*Q3);
- if( filter_yes( interior_limit, edge_limit, q3, q2, q1, q0,
+ if( filter_yes( interior_limit, edge_limit, q3, q2, q1, q0,
p0, p1, p2, p3))
{
const int hv = hev( hev_threshold, p1, p0, q0, q1);
@@ -95,26 +109,31 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-The inter-macroblock filter has potentially wider scope. If the edge variance is high, it performs the simple adjustment (using the outer taps, just like the simple filter and the corresponding case of the normal subblock filter). If the edge variance is low, we begin with the same basic filter calculation and apply multiples of it to pixel pairs symmetric about the edge; the magnitude of adjustment decays as we move away from the edge and six of the pixels in the segment are affected.
-
+The inter-macroblock filter has potentially wider scope. If the edge
+variance is high, it performs the simple adjustment (using the outer
+taps, just like the simple filter and the corresponding case of the
+normal subblock filter). If the edge variance is low, we begin with
+the same basic filter calculation and apply multiples of it to pixel
+pairs symmetric about the edge; the magnitude of adjustment decays as
+we move away from the edge and six of the pixels in the segment are
+affected.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void MBfilter(
uint8 hev_threshold, /* detect high edge variance */
uint8 interior_limit, /* possibly disable filter */
uint8 edge_limit,
- cint8 *P3, int8 *P2, int8 *P1, int8 *P0, /* pixels before
+ cint8 *P3, int8 *P2, int8 *P1, int8 *P0, /* pixels before
edge */
- int8 *Q0, int8 *Q1, int8 *Q2, cint8 *Q3 /* pixels after
+ int8 *Q0, int8 *Q1, int8 *Q2, cint8 *Q3 /* pixels after
edge */
) {
- cint8 p3 = u2s(*P3), p2 = u2s(*P2), p1 = u2s(*P1),
+ cint8 p3 = u2s(*P3), p2 = u2s(*P2), p1 = u2s(*P1),
p0 = u2s(*P0);
- cint8 q0 = u2s(*Q0), q1 = u2s(*Q1), q2 = u2s(*Q2),
+ cint8 q0 = u2s(*Q0), q1 = u2s(*Q1), q2 = u2s(*Q2),
q3 = u2s(*Q3);
- if( filter_yes( interior_limit, edge_limit, q3, q2, q1, q0,
+ if( filter_yes( interior_limit, edge_limit, q3, q2, q1, q0,
p0, p1, p2, p3))
{
if( !hev( hev_threshold, p1, p0, q0, q1))
@@ -124,9 +143,9 @@
const int8 w = c( c(p1 - q1) + 3*(q0 - p0) );
- /* 9/64 is approximately 9/63 = 1/7 and 1<<7 = 128 =
- 2*64. So this a, used to adjust the pixels adjacent
- to the edge, is something like 3/7 the edge
+ /* 9/64 is approximately 9/63 = 1/7, and 1<<7 = 128 =
+ 2*64. So this a, used to adjust the pixels adjacent
+ to the edge, is something like 3/7 the edge
difference. */
int8 a = c( (27*w + 63) >> 7);
@@ -146,10 +165,9 @@
*Q2 = s2u( q2 - a); *P2 = s2u( p2 + a);
} else /* if hev, do simple filter */
- common_adjust( 1, P1, P0, Q0, Q1); /* using outer
+ common_adjust( 1, P1, P0, Q0, Q1); /* using outer
taps */
}
-
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
diff --git a/text_src/15.04__vp8-bitstream__calculation-of-control-parameters.txt b/text_src/15.04__vp8-bitstream__calculation-of-control-parameters.txt
index 1a1e31f..da8ed36 100644
--- a/text_src/15.04__vp8-bitstream__calculation-of-control-parameters.txt
+++ b/text_src/15.04__vp8-bitstream__calculation-of-control-parameters.txt
@@ -1,18 +1,27 @@
-#### 15.4 Calculation of Control Parameters {#h-15-04}
+#### 15.4 Calculation of Control Parameters {#h-15-04}
-We conclude the discussion of loop filtering by showing how the thresholds supplied to the procedures above are derived from the two control parameters `sharpness_level` (an unsigned 3-bit number having maximum value 7) and `loop_filter_level` (an unsigned 6-bit number having maximum value 63).
+We conclude the discussion of loop filtering by showing how the
+thresholds supplied to the procedures above are derived from the two
+control parameters `sharpness_level` (an unsigned 3-bit number having
+maximum value 7) and `loop_filter_level` (an unsigned 6-bit number
+having maximum value 63).
-While the `sharpness_level` is constant over the frame, individual macroblocks may override the `loop_filter_level` with one of four possibilities supplied in the frame header (as described in Chapter 10).
+While the `sharpness_level` is constant over the frame, individual
+macroblocks may override the `loop_filter_level` with one of four
+possibilities supplied in the frame header (as described in
+Section 10).
-Both the simple and normal filters disable filtering if a value derived from the four pixels that straddle the edge (2 either side) exceeds a threshold / limit value.
+Both the simple and normal filters disable filtering if a value
+derived from the four pixels that straddle the edge (2 either side)
+exceeds a threshold / limit value.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Luma and Chroma use the same inter-macroblock edge limit */
-uint8 mbedge_limit = ((loop_filter_level + 2) * 2) +
+uint8 mbedge_limit = ((loop_filter_level + 2) * 2) +
interior_limit;
/* Luma and Chroma use the same inter-subblock edge limit */
@@ -21,13 +30,16 @@
{:lang="c"}
-The remaining thresholds are used only by the normal filters. The filter-disabling interior difference limit is the same for all edges (luma, chroma, inter-subblock, inter-macroblock) and is given by the following.
+The remaining thresholds are used only by the normal filters. The
+filter-disabling interior difference limit is the same for all edges
+(luma, chroma, inter-subblock, inter-macroblock) and is given by the
+following.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uint8 interior_limit = loop_filter_level;
-if( sharpness_level)
+if( sharpness_level)
{
interior_limit >>= sharpness_level > 4 ? 2 : 1;
if( interior_limit > 9 - sharpness_level)
@@ -39,7 +51,8 @@
{:lang="c"}
-Finally, we give the derivation of the high edge-variance threshold, which is also the same for all edge types.
+Finally, we give the derivation of the high edge-variance threshold,
+which is also the same for all edge types.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/text_src/16.00__vp8-bitstream__interframe-macroblock-prediction-records.txt b/text_src/16.00__vp8-bitstream__interframe-macroblock-prediction-records.txt
index 9484a88..62a1343 100644
--- a/text_src/16.00__vp8-bitstream__interframe-macroblock-prediction-records.txt
+++ b/text_src/16.00__vp8-bitstream__interframe-macroblock-prediction-records.txt
@@ -1,9 +1,14 @@
-### Chapter 16: Interframe Macroblock Prediction Records {#h-16-00}
+### Section 16: Interframe Macroblock Prediction Records {#h-16-00}
We describe the layout and semantics of the prediction records for macroblocks in an interframe.
-After the feature specification (which is described in Chapter 10 and is identical for intraframes and interframes), there comes a Bool( prob_intra), which indicates inter-prediction (i.e., prediction from prior frames) when true and intra-prediction (i.e., prediction from already-coded portions of the current frame) when false. The zero-probability `prob_intra` is set by field J of the frame header.
+After the feature specification (which is described in Section 10 and
+is identical for intraframes and interframes), there comes a
+Bool(prob_intra), which indicates inter-prediction (i.e., prediction
+from prior frames) when true and intra-prediction (i.e., prediction
+from already-coded portions of the current frame) when false. The
+zero-probability `prob_intra` is set by field J of the frame header.
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 2149a84..bb17954 100644
--- a/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
+++ b/text_src/16.01__vp8-bitstream__intra-predicted-macroblocks.txt
@@ -1,28 +1,34 @@
-#### 16.1 Intra-Predicted Macroblocks {#h-16-01}
+#### 16.1 Intra-Predicted Macroblocks {#h-16-01}
-For intra-prediction, the layout of the prediction data is essentially the same as the layout for key frames, although the contexts used by the decoding process are slightly different.
+For intra-prediction, the layout of the prediction data is
+essentially the same as the layout for key frames, although the
+contexts used by the decoding process are slightly different.
-As discussed in Chapter 8, the "outer" Y mode here uses a different tree from that used in key frames, repeated here for convenience.
-
+As discussed in Section 8, the "outer" Y mode here uses a different
+tree from that used in key frames, repeated here for convenience.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
const tree_index ymode_tree [2 * (num_ymodes - 1)] =
{
-DC_PRED, 2, /* root: DC_PRED = "0", "1" subtree */
4, 6, /* "1" subtree has 2 descendant subtrees */
- -V_PRED, -H_PRED, /* "10" subtree: V_PRED = "100",
+ -V_PRED, -H_PRED, /* "10" subtree: V_PRED = "100",
H_PRED = "101" */
- -TM_PRED, -B_PRED /* "11" subtree: TM_PRED = "110",
+ -TM_PRED, -B_PRED /* "11" subtree: TM_PRED = "110",
B_PRED = "111" */
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
-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
+The probability table used to decode this tree is variable. As
+described in Section 11, 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:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -34,7 +40,11 @@
These defaults must be restored after detection of a key frame.
-Just as for key frames, if the Y mode is `B_PRED`, there next comes an encoding of the `intra_bpred` mode used by each of the sixteen Y subblocks. These encodings use the same tree as does that for key frames but, in place of the contexts used in key frames, use the single fixed probability table
+Just as for key frames, if the Y mode is `B_PRED`, there next comes an
+encoding of the `intra_bpred` mode used by each of the sixteen Y
+subblocks. These encodings use the same tree as does that for key
+frames but, in place of the contexts used in key frames, these
+encodings use the single fixed probability table.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -45,7 +55,10 @@
{:lang="c"}
-Last comes the chroma mode, again coded using the same tree as that for key frames, this time using the dynamic `uv_mode_prob` table described above.
+Last comes the chroma mode, again coded using the same tree as that
+used for key frames, this time using the dynamic `uv_mode_prob` table
+described above.
-The calculation of the intra-prediction buffer is identical to that described for key frames in Chapter 12.
+The calculation of the intra-prediction buffer is identical to that
+described for key frames in Section 12.
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 13c8316..936c110 100644
--- a/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
+++ b/text_src/16.02__vp8-bitstream__inter-predicted-macroblocks.txt
@@ -1,25 +1,43 @@
-#### 16.2 Inter-Predicted Macroblocks {#h-16-02}
+#### 16.2 Inter-Predicted Macroblocks {#h-16-02}
-Otherwise (when the above bool is true), we are using inter-prediction (which of course only happens for interframes), to which we now restrict our attention.
+Otherwise (when the above bool is true), we are using inter-
+prediction (which of course only happens for interframes), to which
+we now restrict our attention.
-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.
+The next datum is then another bool, `B( prob_last)`, selecting the
+reference frame. If 0, the reference frame is the previous frame
+(the last frame); if 1, another bool (`prob_gf`) selects the reference
+frame between the golden frame (0) and the 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. 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.
+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 Section 18).
-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.
+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 intra-prediction mode.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
typedef enum
{
- mv_nearest = num_ymodes, /* use "nearest" motion vector
+ mv_nearest = num_ymodes, /* use "nearest" motion vector
for entire MB */
mv_near, /* use "next nearest" "" */
mv_zero, /* use zero "" */
- mv_new, /* use explicit offset from
+ mv_new, /* use explicit offset from
implicit "" */
mv_split, /* use multiple motion vectors */
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 49362ae..6b4b7b4 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
@@ -1,33 +1,56 @@
-#### 16.3 Mode and Motion Vector Contexts {#h-16-03}
+#### 16.3 Mode and Motion Vector Contexts {#h-16-03}
-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 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 `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 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.
+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, it enters a new
+vector in the list. The above and left vectors have twice the weight
+of the above-left vector.
-As is the case with many contexts used by VP8, it is possible for macroblocks near the top or left edges of the image to reference blocks that are outside the visible image. VP8 provides a border of 1 macroblock filled with 0x0 motion vectors left of the left edge, and a border filled with 0,0 motion vectors of 1 macroblocks above the top edge.
+As is the case with many contexts used by VP8, it is possible for
+macroblocks near the top or left edges of the image to reference
+blocks that are outside the visible image. VP8 provides a border of
+1 macroblock filled with 0x0 motion vectors left of the left edge,
+and a border filled with 0,0 motion vectors of 1 macroblocks above
+the top edge.
-Much of the process is more easily described in C than in English. The reference code for this can be found in `findnearmv.c`. The calculation of reference vectors, probability table, and, finally, the inter-prediction mode itself is implemented as follows.
+Much of the process is more easily described in C than in English.
+The reference code for this can be found in `modemv.c` (Section 20.11).
+The calculation of reference vectors, probability table, and,
+finally, the inter-prediction mode itself is implemented as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-typedef union
+typedef union
{
unsigned int as_int;
MV as_mv;
} int_mv; /* facilitates rapid equality tests */
-static void mv_bias(MODE_INFO *x,int refframe, int_mv *mvp,
+static void mv_bias(MODE_INFO *x,int refframe, int_mv *mvp,
int * ref_frame_sign_bias )
{
MV xmv;
xmv = x->mbmi.mv.as_mv;
- if ( ref_frame_sign_bias[x->mbmi.ref_frame] !=
+ if ( ref_frame_sign_bias[x->mbmi.ref_frame] !=
ref_frame_sign_bias[refframe] )
{
xmv.row*=-1;
@@ -40,7 +63,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-void vp8_clamp_mv(MV *mv, const MACROBLOCKD *xd)
+void vp8_clamp_mv(MV *mv, const MACROBLOCKD *xd)
{
if ( mv->col < (xd->mb_to_left_edge - LEFT_TOP_MARGIN) )
mv->col = xd->mb_to_left_edge - LEFT_TOP_MARGIN;
@@ -55,12 +78,17 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
+In the function `vp8_find_near_mvs()`, the vectors "nearest" and "near"
+are used by the corresponding modes.
-In the function `vp8_find_near_mvs()`, the vectors "nearest" and "near" are used by the corresponding modes.
+The vector `best_mv` is used as a base for explicitly coded motion
+vectors.
-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 `SPLITMV` 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -121,7 +149,7 @@
int_mv this_mv;
this_mv.as_int = aboveleft->mbmi.mv.as_int;
- mv_bias(aboveleft, refframe, &this_mv,
+ mv_bias(aboveleft, refframe, &this_mv,
ref_frame_sign_bias);
if(this_mv.as_int != mv->as_int) {
@@ -133,7 +161,7 @@
cnt[CNT_ZERO] += 1;
}
- /* If we have three distinct MV's ... */
+ /* If we have three distinct MVs ... */
if(cnt[CNT_SPLITMV]) {
/* See if above-left MV can be merged with NEAREST */
if(mv->as_int == near_mvs[CNT_NEAREST].as_int)
@@ -166,14 +194,15 @@
vp8_clamp_mv(nearest, xd);
vp8_clamp_mv(near, xd);
- vp8_clamp_mv(best_mv, xd); //TODO: move this up before
+ vp8_clamp_mv(best_mv, xd); //TODO: Move this up before
the copy
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-The `mv_ref` probability table (`mv_ref_p`) is then derived from the census as follows.
+The `mv_ref` probability table (`mv_ref_p`) is then derived from the
+census as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -189,9 +218,8 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-vp8_prob *vp8_mv_ref_probs(vp8_prob mv_ref_p[VP8_MVREFS-1],
+vp8_prob *vp8_mv_ref_probs(vp8_prob mv_ref_p[VP8_MVREFS-1],
int cnt[4])
{
mv_ref_p[0] = vp8_mode_contexts [cnt[0]] [0];
@@ -208,17 +236,19 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- mvr = (mv_ref) treed_read( d, mv_ref_tree, mv_ref_p);
+ mvr = (mv_ref) treed_read( d, mv_ref_tree, mv_ref_p);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-For the first four inter-coding modes, the same motion vector is used for all the Y subblocks. The first three modes use an implicit motion vector.
+For the first four inter-coding modes, the same motion vector is used
+for all the Y subblocks. The first three modes use an implicit
+motion vector.
| Mode | Instruction
| -------------- | ------------------------------------------
| `mv_nearest` | Use the nearest vector returned by `vp8_find_near_mvs`.
| `mv_near` | Use the near vector returned by `vp8_find_near_mvs`.
-| `mv_zero` | Use a zero vector, that is, predict the current macroblock from the corresponding macroblock in the prediction frame.
-| `NEWMV` | This mode is followed by an explicitly-coded motion vector (the format of which is described in the next chapter) that is added (component-wise) to the `best_mv` reference vector returned by `find_near_mvs` and applied to all 16 subblocks.
+| `mv_zero` | Use a zero vector; that is, predict the current macroblock from the corresponding macroblock in the prediction frame.
+| `NEWMV` | This mode is followed by an explicitly coded motion vector (the format of which is described in the next section) that is added (component-wise) to the `best_mv` reference vector returned by `find_near_mvs` and applied to all 16 subblocks.
diff --git a/text_src/16.04__vp8-bitstream__split-prediction.txt b/text_src/16.04__vp8-bitstream__split-prediction.txt
index a6673cc..872837b 100644
--- a/text_src/16.04__vp8-bitstream__split-prediction.txt
+++ b/text_src/16.04__vp8-bitstream__split-prediction.txt
@@ -1,19 +1,23 @@
-#### 16.4 Split Prediction {#h-16-04}
+#### 16.4 Split Prediction {#h-16-04}
-The remaining mode (`SPLITMV`) causes multiple vectors to be applied to the Y subblocks. It is immediately followed by a partition specification that determines how many vectors will be specified and how they will be assigned to the subblocks. The possible partitions, with indicated subdivisions and coding tree, are as follows.
+The remaining mode (`SPLITMV`) causes multiple vectors to be applied to
+the Y subblocks. It is immediately followed by a partition
+specification that determines how many vectors will be specified and
+how they will be assigned to the subblocks. The possible partitions,
+with indicated subdivisions and coding tree, are as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
typedef enum
{
mv_top_bottom, /* two pieces {0...7} and {8...15} */
- mv_left_right, /* {0,1,4,5,8,9,12,13} and
+ mv_left_right, /* {0,1,4,5,8,9,12,13} and
{2,3,6,7,10,11,14,15} */
- mv_quarters, /* {0,1,4,5}, {2,3,6,7}, {8,9,12,13},
+ mv_quarters, /* {0,1,4,5}, {2,3,6,7}, {8,9,12,13},
{10,11,14,15} */
- MV_16, /* every subblock gets its own vector
+ MV_16, /* every subblock gets its own vector
{0} ... {15} */
mv_num_partitions
@@ -24,7 +28,7 @@
{
-MV_16, 2, /* MV_16 = "0" */
-mv_quarters, 4, /* mv_quarters = "10" */
- -mv_top_bottom, -mv_left_right /* top_bottom = "110",
+ -mv_top_bottom, -mv_left_right /* top_bottom = "110",
left_right = "111" */
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -35,23 +39,32 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-const Prob mvpartition_probs [mvnum_partition - 1] =
+const Prob mvpartition_probs [mvnum_partition - 1] =
{ 110, 111, 150};
-part = (MVpartition) treed_read( d, mvpartition_tree,
+part = (MVpartition) treed_read( d, mvpartition_tree,
mvpartition_probs);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-After the partition come two (for `mv_top_bottom` or `mv_left_right`), four (for `mv_quarters`), or sixteen (for `MV_16`) subblock inter-prediction modes. These modes occur in the order indicated by the partition layouts (given as comments to the `MVpartition` enum) and are coded as follows. (As was done for the macroblock-level modes, we offset the mode enumeration so that a single variable may unambiguously hold either an intra- or inter-subblock mode.)
+After the partition come two (for `mv_top_bottom` or `mv_left_right`),
+four (for `mv_quarters`), or sixteen (for `MV_16`) subblock inter-
+prediction modes. These modes occur in the order indicated by the
+partition layouts (given as comments to the `MVpartition` enum) and are
+coded as follows. (As was done for the macroblock-level modes, we
+offset the mode enumeration so that a single variable may
+unambiguously hold either an intra- or inter-subblock mode.)
-Prior to decoding each subblock, a decoding tree context is chosen as illustrated in the code snippet below. The context is based on the immediate left and above subblock neighbors, and whether they are equal, are zero, or a combination of those.
+Prior to decoding each subblock, a decoding tree context is chosen as
+illustrated in the code snippet below. The context is based on the
+immediate left and above subblock neighbors, and whether they are
+equal, are zero, or a combination of those.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
typedef enum
{
- LEFT4x4 = num_intra_bmodes, /* use already-coded MV to
+ LEFT4x4 = num_intra_bmodes, /* use already-coded MV to
my left */
ABOVE4x4, /* use already-coded MV above me */
ZERO4x4, /* use zero MV */
@@ -68,17 +81,17 @@
-ZERO4X4, -NEW4X4 /* ZERO = "110", NEW = "111" */
};
-/* Choose correct decoding tree context
- * Function parameters are left subblock neighbor MV and above
+/* Choose correct decoding tree context
+ * Function parameters are left subblock neighbor MV and above
* subblock neighbor MV */
-int vp8_mvCont(MV *l, MV*a)
+int vp8_mvCont(MV *l, MV*a)
{
- int lez = (l->row == 0 && l->col == 0); /* left neighbour
+ int lez = (l->row == 0 && l->col == 0); /* left neighbor
is zero */
- int aez = (a->row == 0 && a->col == 0); /* above neighbour
+ int aez = (a->row == 0 && a->col == 0); /* above neighbor
is zero */
- int lea = (l->row == a->row && l->col == a->col); /* left
- neighbour equals above neighbour */
+ int lea = (l->row == a->row && l->col == a->col); /* left
+ neighbor equals above neighbor */
if(lea && lez)
return SUBMVREF_LEFT_ABOVE_ZED; /* =4 */
@@ -102,19 +115,37 @@
{ 106,145,1 },
{ 179,121,1 },
{ 223,1 ,34 },
- { 208,1 ,1 } };
+ { 208,1 ,1 }
+ };
- sub_ref = (sub_mv_ref) treed_read( d, sub_mv_ref_tree,
+ sub_ref = (sub_mv_ref) treed_read( d, sub_mv_ref_tree,
sub_mv_ref_prob[context]);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
-The first two sub-prediction modes simply copy the already-coded motion vectors used by the blocks above and to-the-left of the subblock at the upper left corner of the current subset (i.e., collection of subblocks being predicted). These prediction blocks need not lie in the current macroblock and, if the current subset lies at the top or left edges of the frame, need not lie in the frame. In this latter case, their motion vectors are taken to be zero, as are subblock motion vectors within an intra-predicted macroblock. Also, to ensure the correctness of prediction within this macroblock, all subblocks lying in an already-decoded subset of the current macroblock must have their motion vectors set.
+The first two sub-prediction modes simply copy the already-coded
+motion vectors used by the blocks above and to the left of the
+subblock at the upper left corner of the current subset (i.e.,
+collection of subblocks being predicted). These prediction blocks
+need not lie in the current macroblock and, if the current subset
+lies at the top or left edges of the frame, need not lie in the
+frame. In this latter case, their motion vectors are taken to be
+zero, as are subblock motion vectors within an intra-predicted
+macroblock. Also, to ensure the correctness of prediction within
+this macroblock, all subblocks lying in an already-decoded subset of
+the current macroblock must have their motion vectors set.
-`ZERO4x4` uses a zero motion vector and predicts the current subset using the corresponding subset from the prediction frame.
+`ZERO4x4` uses a zero motion vector and predicts the current subset
+using the corresponding subset from the prediction frame.
-NEW4x4 is exactly like NEWMV except applied only to the current subset. It is followed by a 2-dimensional motion vector offset (described in the next chapter) that is added to the best vector returned by the earlier call to find_near_mvs to form the motion vector in effect for the subset.
+`NEW4x4` is exactly like `NEWMV` except that `NEW4x4` is applied only to
+the current subset. It is followed by a two-dimensional motion
+vector offset (described in the next section) that is added to the
+best vector returned by the earlier call to `find_near_mvs` to form the
+motion vector in effect for the subset.
-Parsing of both inter-prediction modes and motion vectors (described next) can be found in the reference decoder file `modemv.c`.
+Parsing of both inter-prediction modes and motion vectors (described
+next) can be found in the reference decoder file `modemv.c`
+(Section 20.11).
diff --git a/text_src/17.00__vp8-bitstream__motion-vector-decoding.txt b/text_src/17.00__vp8-bitstream__motion-vector-decoding.txt
index 4f05d3f..822bd80 100644
--- a/text_src/17.00__vp8-bitstream__motion-vector-decoding.txt
+++ b/text_src/17.00__vp8-bitstream__motion-vector-decoding.txt
@@ -1,9 +1,14 @@
-### Chapter 17: Motion Vector Decoding {#h-17-00}
+### Section 17: Motion Vector Decoding {#h-17-00}
-As discussed above, motion vectors appear in two places in the VP8 datastream: applied to whole macroblocks in `NEWMV` mode and applied to subsets of macroblocks in `NEW4x4` mode. The format of the vectors is identical in both cases.
+As discussed above, motion vectors appear in two places in the VP8
+datastream: applied to whole macroblocks in `NEWMV` mode and applied to
+subsets of macroblocks in `NEW4x4` mode. The format of the vectors
+is identical in both cases.
-Each vector has two pieces: A vertical component (row) followed by a horizontal component (column). The row and column use separate coding probabilities but are otherwise represented identically.
+Each vector has two pieces: a vertical component (row) followed by a
+horizontal component (column). The row and column use separate
+coding probabilities but are otherwise represented identically.
diff --git a/text_src/17.01__vp8-bitstream__coding-of-each-component.txt b/text_src/17.01__vp8-bitstream__coding-of-each-component.txt
index dee2a29..39a1c0c 100644
--- a/text_src/17.01__vp8-bitstream__coding-of-each-component.txt
+++ b/text_src/17.01__vp8-bitstream__coding-of-each-component.txt
@@ -1,13 +1,23 @@
-#### 17.1 Coding of Each Component {#h-17-01}
+#### 17.1 Coding of Each Component {#h-17-01}
-Each component is a signed integer [[ "V" ]] representing a vertical or horizontal luma displacement of [[ "V" ]] quarter-pixels (and a chroma displacement of [[ "V" ]] eighth-pixels). The absolute value of [[ "V" ]], if non-zero, is followed by a boolean sign. [[ "V" ]] may take any value between -1023 and +1023, inclusive.
+Each component is a signed integer V representing a vertical or
+horizontal luma displacement of V quarter-pixels (and a chroma
+displacement of V eighth-pixels). The absolute value of V, if non-
+zero, is followed by a boolean sign. V may take any value between
+-1023 and +1023, inclusive.
-The absolute value [[ "A" ]] is coded in one of two different ways according to its size. For [[ 0 <= "A" <= 7 ]], [[ "A" ]] is tree-coded, and for [[ 8 <= "A" <= 1023 ]], the bits in the binary expansion of [[ "A" ]] are coded using independent boolean probabilities. The coding of [[ "A" ]] begins with a bool specifying which range is in effect.
+The absolute value A is coded in one of two different ways according
+to its size. For 0 <= A <= 7, A is tree-coded, and for 8 <= A <=
+1023, the bits in the binary expansion of A are coded using
+independent boolean probabilities. The coding of A begins with a
+bool specifying which range is in effect.
-Decoding a motion vector component then requires a 19-position probability table, whose offsets, along with the procedure used to decode components, are as follows:
+Decoding a motion vector component then requires a 19-position
+probability table, whose offsets, along with the procedure used to
+decode components, are as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -27,14 +37,13 @@
typedef Prob MV_CONTEXT [MVPcount]; /* Decoding spec for
a single component */
-
/* Tree used for small absolute values (has expected
correspondence). */
const tree_index small_mvtree [2 * (8 - 1)] =
{
2, 8, /* "0" subtree, "1" subtree */
- 4, 6, /* "00" subtree", "01" subtree */
+ 4, 6, /* "00" subtree, "01" subtree */
-0, -1, /* 0 = "000", 1 = "001" */
-2, -3, /* 2 = "010", 3 = "011" */
10, 12, /* "10" subtree, "11" subtree */
diff --git a/text_src/17.02__vp8-bitstream__probability-updates.txt b/text_src/17.02__vp8-bitstream__probability-updates.txt
index 01460ff..62db01b 100644
--- a/text_src/17.02__vp8-bitstream__probability-updates.txt
+++ b/text_src/17.02__vp8-bitstream__probability-updates.txt
@@ -1,40 +1,48 @@
-#### 17.2 Probability Updates {#h-17-02}
+#### 17.2 Probability Updates {#h-17-02}
-The decoder should maintain an array of two `MV_CONTEXT`s for decoding row and column components, respectively. These `MV_CONTEXT`s should be set to their defaults every key frame. Each individual probability may be updated every interframe (by field [[ "J" ]] of the frame header) using a constant table of update probabilities. Each optional update is of the form [[ B? P(7) ]], that is, a bool followed by a 7-bit probability specification if true.
+The decoder should maintain an array of two `MV_CONTEXT`s for decoding
+row and column components, respectively. These `MV_CONTEXT`s should be
+set to their defaults every key frame. Each individual probability
+may be updated every interframe (by field J of the frame header)
+using a constant table of update probabilities. Each optional update
+is of the form B? P(7), that is, a bool followed by a 7-bit
+probability specification if true.
-As with other dynamic probabilities used by VP8, the updates remain in effect until the next key frame or until replaced via another update.
+As with other dynamic probabilities used by VP8, the updates remain
+in effect until the next key frame or until replaced via another
+update.
In detail, the probabilities should then be managed as follows.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/* Never-changing table of update probabilities for each
+/* Never-changing table of update probabilities for each
individual probability used in decoding motion vectors. */
const MV_CONTEXT vp8_mv_update_probs[2] =
-{
+{
{
237,
246,
253, 253, 254, 254, 254, 254, 254,
254, 254, 254, 254, 254, 250, 250, 252, 254, 254
- },
+ },
{
231,
243,
245, 253, 254, 254, 254, 254, 254,
254, 254, 254, 254, 254, 251, 251, 254, 254, 254
}
-};
+};
/* Default MV decoding probabilities. */
const MV_CONTEXT default_mv_context[2] =
{
- { // row
+ { // row
162, // is short
128, // sign
225, 146, 172, 147, 214, 39, 156, // short tree
@@ -45,19 +53,18 @@
164, // is short
128,
204, 170, 119, 235, 140, 230, 228,
- 128, 130, 130, 74, 148, 180, 203, 236, 254, 254 // long bits
-
+ 128, 130, 130, 74, 148, 180, 203, 236, 254, 254 // long bits
}
};
-/* Current MV decoding probabilities, set to above defaults
+/* Current MV decoding probabilities, set to above defaults
every key frame. */
MV_CONTEXT mvc [2]; /* always row, then column */
/* Procedure for decoding a complete motion vector. */
-typedef struct { int16 row, col;} MV; /* as in previous chapter */
+typedef struct { int16 row, col;} MV; /* as in previous section */
MV read_mv( bool_decoder *d)
{
@@ -67,15 +74,15 @@
return v;
}
-/* Procedure for updating MV decoding probabilities, called
- every interframe with "d" at the appropriate position in
+/* Procedure for updating MV decoding probabilities, called
+ every interframe with "d" at the appropriate position in
the frame header. */
void update_mvcontexts( bool_decoder *d)
{
int i = 0;
do { /* component = row, then column */
- const Prob *up = mv_update_probs[i]; /* update probs
+ const Prob *up = mv_update_probs[i]; /* update probs
for component */
Prob *p = mvc[i]; /* start decode tbl "" */
Prob * const pstop = p + MVPcount; /* end decode tbl "" */
@@ -93,5 +100,7 @@
{:lang="c"}
-This completes the description of the motion-vector decoding procedure and, with it, the procedure for decoding interframe macroblock prediction records.
+This completes the description of the motion-vector decoding
+procedure and, with it, the procedure for decoding interframe
+macroblock prediction records.
diff --git a/text_src/18.00__vp8-bitstream__interframe-prediction.txt b/text_src/18.00__vp8-bitstream__interframe-prediction.txt
index 4bc3cbb..b9af58a 100644
--- a/text_src/18.00__vp8-bitstream__interframe-prediction.txt
+++ b/text_src/18.00__vp8-bitstream__interframe-prediction.txt
@@ -1,9 +1,16 @@
-### Chapter 18: Interframe Prediction {#h-18-00}
+### Section 18: Interframe Prediction {#h-18-00}
-Given an inter-prediction specification for the current macroblock, that is, a reference frame together with a motion vector for each of the sixteen Y subblocks, we describe the calculation of the prediction buffer for the macroblock. Frame reconstruction is then completed via the previously-described processes of residue summation ([Chapter 14](#h-14-00)) and loop filtering ([Chapter 15](#h-15-00)).
+Given an inter-prediction specification for the current macroblock,
+that is, a reference frame together with a motion vector for each of
+the sixteen Y subblocks, we describe the calculation of the
+prediction buffer for the macroblock. Frame reconstruction is then
+completed via the previously described processes of residue summation
+(Section 14) and loop filtering (Section 15).
-The management of inter-predicted subblocks and sub-pixel interpolation may be found in the reference decoder file `predict.c`.
+The management of inter-predicted subblocks and sub-pixel
+interpolation may be found in the reference decoder file `predict.c`
+(Section 20.14).
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 b68f24c..c7cb56d 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
@@ -1,15 +1,38 @@
-#### 18.1 Bounds on and Adjustment of Motion Vectors {#h-18-01}
+#### 18.1 Bounds on, and Adjustment of, Motion Vectors {#h-18-01}
-Since each motion vector is differentially encoded from a neighboring block or macroblock and the only clamp is to ensure that the referenced motion vector represents a valid location inside a reference frame buffer, it is technically possible within the VP8 format for a block or macroblock to have arbitrarily large motion vectors, up to the size of the input image plus the extended border areas. For practical reasons, VP8 imposes a motion vector size range limit of -4096 to 4095 full pixels, regardless of image size (VP8 defines 14 raw bits for width and height; 16383x16383 is the maximum possible image size). Bitstream-compliant encoders and decoders shall enforce this limit.
+Since each motion vector is differentially encoded from a neighboring
+block or macroblock and the only clamp is to ensure that the
+referenced motion vector represents a valid location inside a
+reference frame buffer, it is technically possible within the VP8
+format for a block or macroblock to have arbitrarily large motion
+vectors, up to the size of the input image plus the extended border
+areas. For practical reasons, VP8 imposes a motion vector size range
+limit of -4096 to 4095 full pixels, regardless of image size (VP8
+defines 14 raw bits for width and height; 16383x16383 is the maximum
+possible image size). Bitstream-compliant encoders and decoders
+shall enforce this limit.
-Because the motion vectors applied to the chroma subblocks have 1/8 pixel resolution, the synthetic pixel calculation, outlined in Chapter 5 and detailed below, uses this resolution for the luma subblocks as well. In accordance, the stored luma motion vectors are all doubled, each component of each luma vector becoming an even integer in the range -2046 to +2046, inclusive.
+Because the motion vectors applied to the chroma subblocks have
+1/8-pixel resolution, the synthetic pixel calculation, outlined in
+Section 5 and detailed below, uses this resolution for the luma
+subblocks as well. In accordance, the stored luma motion vectors are
+all doubled, each component of each luma vector becoming an even
+integer in the range -2046 to +2046, inclusive.
-The vector applied to each chroma subblock is calculated by averaging the vectors for the 4 luma subblocks occupying the same visible area as the chroma subblock in the usual correspondence, that is, the vector for U and V block 0 is the average of the vectors for the Y subblocks { 0, 1, 4, 5}, chroma block 1 corresponds to Y blocks { 2, 3, 6, 7}, chroma block 2 to Y blocks { 8, 9, 12, 13}, and chroma block 3 to Y blocks { 10, 11, 14, 15}.
+The vector applied to each chroma subblock is calculated by averaging
+the vectors for the 4 luma subblocks occupying the same visible area
+as the chroma subblock in the usual correspondence; that is, the
+vector for U and V block 0 is the average of the vectors for the Y
+subblocks { 0, 1, 4, 5}, chroma block 1 corresponds to Y blocks { 2,
+3, 6, 7}, chroma block 2 to Y blocks { 8, 9, 12, 13}, and chroma
+block 3 to Y blocks { 10, 11, 14, 15}.
-In detail, each of the two components of the vectors for each of the chroma subblocks is calculated from the corresponding luma vector components as follows:
+In detail, each of the two components of the vectors for each of the
+chroma subblocks is calculated from the corresponding luma vector
+components as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -17,10 +40,10 @@
{
int s = c1 + c2 + c3 + c4;
- /* The shift divides by 8 (not 4) because chroma pixels
- have twice the diameter of luma pixels. The handling
- of negative motion vector components is slightly
- cumbersome because, strictly speaking, right shifts
+ /* The shift divides by 8 (not 4) because chroma pixels
+ have twice the diameter of luma pixels. The handling
+ of negative motion vector components is slightly
+ cumbersome because, strictly speaking, right shifts
of negative numbers are not well-defined in C. */
return s >= 0 ? (s + 4) >> 3 : -( (-s + 4) >> 3);
@@ -28,7 +51,11 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{: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 pseudocode (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 +65,16 @@
{: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 `NEWMV` 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 `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.
+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.02__vp8-bitstream__prediction-subblocks.txt b/text_src/18.02__vp8-bitstream__prediction-subblocks.txt
index aac5626..ab5f4cc 100644
--- a/text_src/18.02__vp8-bitstream__prediction-subblocks.txt
+++ b/text_src/18.02__vp8-bitstream__prediction-subblocks.txt
@@ -1,9 +1,18 @@
-#### 18.2 Prediction Subblocks {#h-18-02}
+#### 18.2 Prediction Subblocks {#h-18-02}
-The prediction calculation for each subblock is then as follows. Temporarily disregarding the fractional part of the motion vector (that is, rounding "up" or "left" by right-shifting each component 3 bits with sign propagation) and adding the origin (upper left position) of the (16x16 luma or 8x8 chroma) current macroblock gives us an origin in the Y, U, or V plane of the predictor frame (either the golden frame or previous frame).
+The prediction calculation for each subblock is then as follows.
+Temporarily disregarding the fractional part of the motion vector
+(that is, rounding "up" or "left" by right-shifting each component
+3 bits with sign propagation) and adding the origin (upper left
+position) of the (16x16 luma or 8x8 chroma) current macroblock gives
+us an origin in the Y, U, or V plane of the predictor frame (either
+the golden frame or previous frame).
-Considering that origin to be the upper left corner of a (luma or chroma) macroblock, we need to specify the relative positions of the pixels associated to that subblock, that is, any pixels that might be involved in the sub-pixel interpolation processes for the subblock.
+Considering that origin to be the upper left corner of a (luma or
+chroma) macroblock, we need to specify the relative positions of the
+pixels associated to that subblock, that is, any pixels that might be
+involved in the sub-pixel interpolation processes for the subblock.
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 0635a08..3e979ca 100644
--- a/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
+++ b/text_src/18.03__vp8-bitstream__sub-pixel-interpolation.txt
@@ -1,19 +1,53 @@
-#### 18.3 Sub-pixel Interpolation {#h-18-03}
+#### 18.3 Sub-Pixel Interpolation {#h-18-03}
-The sub-pixel interpolation is effected via two one-dimensional convolutions. These convolutions may be thought of as operating on a two-dimensional array of pixels whose origin is the subblock origin, that is the origin of the prediction macroblock described above plus the offset to the subblock. Because motion vectors are arbitrary, so are these "prediction subblock origins".
+The sub-pixel interpolation is effected via two one-dimensional
+convolutions. These convolutions may be thought of as operating on a
+two-dimensional array of pixels whose origin is the subblock origin,
+that is the origin of the prediction macroblock described above plus
+the offset to the subblock. Because motion vectors are arbitrary, so
+are these "prediction subblock origins".
-The integer part of the motion vector is subsumed in the origin of the prediction subblock, the 16 (synthetic) pixels we need to construct are given by 16 offsets from the origin. The integer part of each of these offsets is the offset of the corresponding pixel from the subblock origin (using the vertical stride). To these integer parts is added a constant fractional part, which is simply the difference between the actual motion vector and its integer truncation used to calculate the origins of the prediction macroblock and subblock. Each component of this fractional part is an integer between 0 and 7, representing a forward displacement in eighths of a pixel.
+The integer part of the motion vector is subsumed in the origin of
+the prediction subblock; the 16 (synthetic) pixels we need to
+construct are given by 16 offsets from the origin. The integer part
+of each of these offsets is the offset of the corresponding pixel
+from the subblock origin (using the vertical stride). To these
+integer parts is added a constant fractional part, which is simply
+the difference between the actual motion vector and its integer
+truncation used to calculate the origins of the prediction macroblock
+and subblock. Each component of this fractional part is an integer
+between 0 and 7, representing a forward displacement in eighths of a
+pixel.
-It is these fractional displacements that determine the filtering process. If they both happen to be zero (that is, we had a "whole pixel" motion vector), the prediction subblock is simply copied into the corresponding piece of the current macroblock's prediction buffer. As discussed in Chapter 14, the layout of the macroblock's prediction buffer can depend on the specifics of the reconstruction implementation chosen. Of course, the vertical displacement between lines of the prediction subblock is given by the stride, as are all vertical displacements used here.
+It is these fractional displacements that determine the filtering
+process. If they both happen to be zero (that is, we had a "whole
+pixel" motion vector), the prediction subblock is simply copied into
+the corresponding piece of the current macroblock's prediction
+buffer. As discussed in Section 14, the layout of the macroblock's
+prediction buffer can depend on the specifics of the reconstruction
+implementation chosen. Of course, the vertical displacement between
+lines of the prediction subblock is given by the stride, as are all
+vertical displacements used here.
-Otherwise, at least one of the fractional displacements is non-zero. We then synthesize the missing pixels via a horizontal, followed by a vertical, one-dimensional interpolation.
+Otherwise, at least one of the fractional displacements is non-zero.
+We then synthesize the missing pixels via a horizontal, followed by a
+vertical, one-dimensional interpolation.
-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.
+The two interpolations are essentially identical. Each uses a (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 `version
+number` field in the frame tag, either a bicubic or a bilinear tap set
+is used.
The exact implementation of subsampling is as follows.
@@ -51,7 +85,7 @@
Pixel interp(
const int fil[6], /* filter to apply */
- const Pixel *p, /* origin (rounded "before") in
+ const Pixel *p, /* origin (rounded "before") in
prediction area */
const int s /* size of one forward step "" */
) {
@@ -64,31 +98,31 @@
p += s;
} while( ++i < 6);
- return clamp255( (a + 64) >> 7); /* round to nearest
+ return clamp255( (a + 64) >> 7); /* round to nearest
8-bit value */
}
-/* First do horizontal interpolation, producing intermediate
+/* First do horizontal interpolation, producing intermediate
buffer. */
void Hinterp(
- Pixel temp[9][4], /* 9 rows of 4 (intermediate)
+ Pixel temp[9][4], /* 9 rows of 4 (intermediate)
destination values */
- const Pixel *p, /* subblock origin in prediction
+ const Pixel *p, /* subblock origin in prediction
frame */
- int s, /* vertical stride to be used in
+ int s, /* vertical stride to be used in
prediction frame */
uint hfrac, /* 0 <= horizontal displacement <= 7 */
uint bicubic /* 1=bicubic filter, 0=bilinear */
) {
- const int * const fil = bicubic ? filters [hfrac] :
+ const int * const fil = bicubic ? filters [hfrac] :
BilinearFilters[hfrac];
int r = 0; do /* for each row */
{
int c = 0; do /* for each destination sample */
- {
+ {
/* Pixel separation = one horizontal step = 1 */
temp[r][c] = interp( fil, p + c, 1);
@@ -108,14 +142,14 @@
uint vfrac, /* 0 <= vertical displacement <= 7 */
uint bicubic /* 1=bicubic filter, 0=bilinear */
) {
- const int * const fil = bicubic ? filters [vfrac] :
+ const int * const fil = bicubic ? filters [vfrac] :
BilinearFilters[vfrac];
int r = 0; do /* for each row */
{
int c = 0; do /* for each destination sample */
- {
- /* Pixel separation = one vertical step = width
+ {
+ /* Pixel separation = one vertical step = width
of array = 4 */
final[r][c] = interp( fil, temp[r] + c, 4);
diff --git a/text_src/18.04__vp8-bitstream__filter-properties.txt b/text_src/18.04__vp8-bitstream__filter-properties.txt
index d7dea60..2dabd4f 100644
--- a/text_src/18.04__vp8-bitstream__filter-properties.txt
+++ b/text_src/18.04__vp8-bitstream__filter-properties.txt
@@ -1,27 +1,90 @@
-#### 18.4 Filter Properties {#h-18-04}
+#### 18.4 Filter Properties {#h-18-04}
-We discuss briefly the rationale behind the choice of filters. Our approach is necessarily cursory; a genuinely accurate discussion would require a couple of books. Readers unfamiliar with signal processing may or may not wish to skip this.
+We discuss briefly the rationale behind the choice of filters. Our
+approach is necessarily cursory; a genuinely accurate discussion
+would require a couple of books. Readers unfamiliar with signal
+processing may or may not wish to skip this.
-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.
+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; 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.
+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.
+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.
-It is true that the theoretically correct subsampling procedure, as well as any approximation thereof, is always given by a translation-invariant weighted sum (or filter) similar to that used by VP8. It is also true that the reconstruction error made by such a filter can be simply represented as a multiplier in the frequency domain, that is, such filters simply multiply the Fourier transform of any signal to which they are applied by a fixed function associated to the filter. This fixed function is usually called the frequency response (or transfer function); the ideal subsampling filter has a frequency response equal to one in the Nyquist rectangle and zero everywhere else.
+It is true that the theoretically correct subsampling procedure, as
+well as any approximation thereof, is always given by a translation-
+invariant weighted sum (or filter) similar to that used by VP8. It
+is also true that the reconstruction error made by such a filter can
+be simply represented as a multiplier in the frequency domain; that
+is, such filters simply multiply the Fourier transform of any signal
+to which they are applied by a fixed function associated to the
+filter. This fixed function is usually called the frequency response
+(or transfer function); the ideal subsampling filter has a frequency
+response equal to one in the Nyquist rectangle and zero everywhere
+else.
-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.
+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 0th 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.
+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.
-To get slightly more specific, the filters chosen by VP8 are the best resonance-free 4- or 6-tap filters possible, where "best" describes the frequency response near the origin: the response at 0 is required to be 1 and the graph of the response at 0 is as flat as possible.
+To get slightly more specific, the filters chosen by VP8 are the best
+resonance-free 4- or 6-tap filters possible, where "best" describes
+the frequency response near the origin: The response at 0 is required
+to be 1, and the graph of the response at 0 is as flat as possible.
-To provide an intuitively more obvious point of reference, the "best" 2-tap filter is given by simple linear interpolation between the surrounding actual pixels.
+To provide an intuitively more obvious point of reference, the "best"
+2-tap filter is given by simple linear interpolation between the
+surrounding actual pixels.
-Finally, it should be noted that, because of the way motion vectors are calculated, the (shorter) 4-tap filters (used for odd fractional displacements) are applied in the chroma plane only. Human color perception is notoriously poor, especially where higher spatial frequencies are involved. The shorter filters are easier to understand mathematically, and the difference between them and a theoretically slightly better 6-tap filter is negligible where chroma is concerned.
+Finally, it should be noted that, because of the way motion vectors
+are calculated, the (shorter) 4-tap filters (used for odd fractional
+displacements) are applied in the chroma plane only. Human color
+perception is notoriously poor, especially where higher spatial
+frequencies are involved. The shorter filters are easier to
+understand mathematically, and the difference between them and a
+theoretically slightly better 6-tap filter is negligible where chroma
+is concerned.
diff --git a/text_src/a.00_vp8-bitstream__syntax.txt b/text_src/a.00_vp8-bitstream__syntax.txt
index 1104047..8a0e337 100644
--- a/text_src/a.00_vp8-bitstream__syntax.txt
+++ b/text_src/a.00_vp8-bitstream__syntax.txt
@@ -1,15 +1,27 @@
-### Annex A: Bitstream Syntax {#h-0a-00}
+### Annex A: Bitstream Syntax {#h-0a-00}
-This annex presents the bitstream syntax in a tabular form. All the information elements have been introduced and explained in the previous chapters but are collected here for a quick reference. Each syntax element is shortly described after the tabular representation along with a reference to the corresponding paragraph in the main document. The meaning of each syntax element value is not repeated here.
+This annex presents the bitstream syntax in a tabular form. All the
+information elements have been introduced and explained in the
+previous sections but are collected here for a quick reference. Each
+syntax element is briefly described after the tabular representation
+along with a reference to the corresponding paragraph in the main
+document. The meaning of each syntax element value is not repeated
+here.
-The top-level hierarchy of the bitstream is introduced in [Chapter 4](#h-04-00).
+The top-level hierarchy of the bitstream is introduced in Section 4.
-Definition of syntax element coding types can be found in [Chapter 8](#h-08-00). The types used in the representation in this annex are:
+Definition of syntax element coding types can be found in Section 8.
+The types used in the representation in this annex are:
- * `f(n)`, n-bit value from stream (n successive bits, not boolean encoded)
- * `L(n)`, n-bit number encoded as n booleans (with equal probability of being `0` or `1`)
+ * `f(n)`, n-bit value from stream (n successive bits, not boolean
+ encoded)
+
+ * `L(n)`, n-bit number encoded as n booleans (with equal probability
+ of being `0` or `1`)
+
* `B(p)`, bool with probability `p` of being `0`
- * `T`, tree-encoded value
+
+ * `T`, tree-encoded value
diff --git a/text_src/a.01_vp8-bitstream__frame_tag.txt b/text_src/a.01_vp8-bitstream__frame_tag.txt
index 157ce28..a642ce9 100644
--- a/text_src/a.01_vp8-bitstream__frame_tag.txt
+++ b/text_src/a.01_vp8-bitstream__frame_tag.txt
@@ -1,16 +1,17 @@
-#### A.1 Uncompressed Data Chunk {#h-0a-01}
+#### A.1 Uncompressed Data Chunk {#h-0a-01}
-| Frame Tag | Type |
-|-------------------------------------------------------|-------|
-| `frame_tag` | f(24) |
-| `if (key_frame) {` | |
-| ` start_code` | f(24) |
-| ` horizontal_size_code` | f(16) |
-| ` vertical_size_code` | f(16) |
-| `}` | |
+| ---------------------------------------------- | ----- |
+| Frame Tag | Type |
+| ---------------------------------------------- | ----- |
+| frame_tag | f(24) |
+| if (key_frame) { | |
+| start_code | f(24) |
+| horizontal_size_code | f(16) |
+| vertical_size_code | f(16) |
+| } | |
{:.col1-pre}
@@ -27,24 +28,26 @@
version = (tmp >> 1) & 0x7;
show_frame = (tmp >> 4) & 0x1;
first_part_size = (tmp >> 5) & 0x7FFFF;
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{:lang="c"}
Where:
- * `key_frame` indicates if the current frame is a key frame or not.
- * `version` determines the bitstream version.
- * `show_frame` indicates if the current frame is meant to be displayed
+ * `key_frame` indicates whether the current frame is a key frame
or not.
+
+ * `version` determines the bitstream version.
+
+ * `show_frame` indicates whether the current frame is meant to be
+ displayed or not.
+
* `first_part_size` determines the size of the first partition
(control partition), excluding the uncompressed data chunk.
-The `start_code` is a constant 3-byte pattern having value 0x9d012a. The
-latter part of the uncompressed chunk (after the `start_code`) can be
-parsed as follows:
-
+The `start_code` is a constant 3-byte pattern having value 0x9d012a.
+The latter part of the uncompressed chunk (after the `start_code`) can
+be parsed as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
unsigned char *c = pbi->source + 6;
diff --git a/text_src/a.02_vp8-bitstream__frame_header.txt b/text_src/a.02_vp8-bitstream__frame_header.txt
index 67a4480..f28e277 100644
--- a/text_src/a.02_vp8-bitstream__frame_header.txt
+++ b/text_src/a.02_vp8-bitstream__frame_header.txt
@@ -1,244 +1,351 @@
-#### A.2 Frame Header {#h-0a-02}
+#### A.2 Frame Header {#h-0a-02}
-| Frame Header | Type |
-|----------------------------------------------|-------|
-| `if (key_frame) {` | |
-| ` color_space` | L(1) |
-| ` clamping_type` | L(1) |
-| `}` | |
-| `segmentation_enabled` | L(1) |
-| `if (segmentation_enabled) {` | |
-| ` update_segmentation()` | |
-| `}` | |
-| `filter_type` | L(1) |
-| `loop_filter_level` | L(6) |
-| `sharpness_level` | L(3) |
-| `mb_lf_adjustments()` | |
-| `log2_nbr_of_dct_partitions` | L(2) |
-| `quant_indices()` | |
-| `if (key_frame) {` | |
-| ` refresh_entropy_probs` | L(1) |
-| `} else {` | |
-| ` refresh_golden_frame` | L(1) |
-| ` refresh_alternate_frame` | L(1) |
-| ` if (!refresh_golden_frame)` | |
-| ` copy_buffer_to_golden` | L(2) |
-| ` if (!refresh_alternate_frame)` | |
-| ` copy_buffer_to_alternate` | L(2) |
-| ` sign_bias_golden` | L(1) |
-| ` sign_bias_alternate` | L(1) |
-| ` refresh_entropy_probs` | L(1) |
-| ` refresh_last` | L(1) |
-| `}` | |
-| `token_prob_update()` | |
-| `mb_no_skip_coeff` | L(1) |
+| ---------------------------------------------- | ----- |
+| Frame Header | Type |
+| ---------------------------------------------- | ----- |
+| if (key_frame) { | |
+| color_space | L(1) |
+| clamping_type | L(1) |
+| } | |
+| segmentation_enabled | L(1) |
+| if (segmentation_enabled) | |
+| update_segmentation() | |
+| filter_type | L(1) |
+| loop_filter_level | L(6) |
+| sharpness_level | L(3) |
+| mb_lf_adjustments() | |
+| log2_nbr_of_dct_partitions | L(2) |
+| quant_indices() | |
+| if (key_frame) | |
+| refresh_entropy_probs | L(1) |
+| else { | |
+| refresh_golden_frame | L(1) |
+| refresh_alternate_frame | L(1) |
+| if (!refresh_golden_frame) | |
+| copy_buffer_to_golden | L(2) |
+| if (!refresh_alternate_frame) | |
+| copy_buffer_to_alternate | L(2) |
+| sign_bias_golden | L(1) |
+| sign_bias_alternate | L(1) |
+| refresh_entropy_probs | L(1) |
+| refresh_last | L(1) |
+| } | |
+| token_prob_update() | |
+| mb_no_skip_coeff | L(1) |
+| if (mb_no_skip_coeff) | |
+| prob_skip_false | L(8) |
+| if (!key_frame) { | |
+| prob_intra | L(8) |
+| prob_last | 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++) | |
+| intra_16x16_prob | L(8) |
+| } | |
+| intra_chroma prob_update_flag | L(1) |
+| if (intra_chroma_prob_update_flag) { | |
+| for (i = 0; i < 3; i++) | |
+| intra_chroma_prob | L(8) |
+| } | |
+| mv_prob_update() | |
+| } | |
{:.col1-pre}
-| Frame Header | Type |
-|----------------------------------------------|-------|
-| `prob_skip_false` | L(8) |
-| `if (!key_frame) {` | |
-| ` prob_intra` | L(8) |
-| ` prob_last` | 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++)` | |
-| ` intra_16x16_prob` | L(8) |
-| } | |
-| ` intra_chroma prob_update_flag` | L(1) |
-| ` if (intra_chroma_prob_update_flag) {` | |
-| ` for (i = 0; i < 3; i++)` | |
-| ` intra_chroma_prob` | L(8) |
-| ` }` | |
-| ` mv_prob_update()` | |
-| `}` | |
+ * `color_space` defines the YUV color space of the sequence
+ ([Section 9.2](#h-09-02))
+
+ * `clamping_type` specifies if the decoder is required to clamp the
+ reconstructed pixel values ([Section 9.2](#h-09-02))
+
+ * `segmentation_enabled` enables the segmentation feature for the
+ current frame ([Section 9.3](#h-09-03))
+
+ * `filter_type` determines whether the normal or the simple loop
+ filter is used ([Sections 9.4](#h-09-04), [15](#h-15-00))
+
+ * `loop_filter_level` controls the deblocking filter
+ ([Sections 9.4](#h-09-04), [15](#h-15-00))
+
+ * `sharpness_level` controls the deblocking filter
+ ([Sections 9.4](#h-09-04), [15](#h-15-00))
+
+ * `log2_nbr_of_dct_partitions` determines the number of separate
+ partitions containing the DCT coefficients of the macroblocks
+ ([Section 9.5](#h-09-05))
+
+ * `refresh_entropy_probs` determines whether updated token
+ probabilities are used only for this frame or until further update
+
+ * `refresh_golden_frame` determines if the current decoded frame
+ refreshes the golden frame ([Section 9.7](#h-09-07))
+
+ * `refresh_alternate_frame` determines if the current decoded frame
+ refreshes the alternate reference frame ([Section 9.7](#h-09-07))
+
+ * `copy_buffer_to_golden` determines if the golden reference is
+ replaced by another reference ([Section 9.7](#h-09-07))
+
+ * `copy_buffer_to_alternate` determines if the alternate reference is
+ replaced by another reference ([Section 9.7](#h-09-07))
+
+ * `sign_bias_golden` controls the sign of motion vectors when the
+ golden frame is referenced ([Section 9.7](#h-09-07))
+
+ * `sign_bias_alternate` controls the sign of motion vectors when the
+ alternate frame is referenced ([Section 9.7](#h-09-07))
+
+ * `refresh_last` determines if the current decoded frame refreshes the
+ last frame reference buffer ([Section 9.8](#h-09-08))
+
+ * `mb_no_skip_coeff` enables or disables the skipping of macroblocks
+ containing no non-zero coefficients ([Section 9.10](#h-09-10))
+
+ * `prob_skip_false` indicates the probability that the macroblock is
+ not skipped (flag indicating skipped macroblock is false)
+ ([Section 9.10](#h-09-10))
+
+ * `prob_intra` indicates the probability of an intra macroblock
+ ([Section 9.10](#h-09-10))
+
+ * `prob_last` indicates the probability that the last reference frame
+ is used for inter-prediction ([Section 9.10](#h-09-10))
+
+ * `prob_gf` indicates the probability that the golden reference frame
+ is used for inter-prediction ([Section 9.10](#h-09-10))
+
+ * `intra_16x16_prob_update_flag` indicates if the branch probabilities
+ used in the decoding of the luma intra-prediction mode are updated
+ ([Section 9.10](#h-09-10))
+
+ * `intra_16x16_prob` indicates the branch probabilities of the luma
+ intra-prediction mode decoding tree
+
+ * `intra_chroma_prob_update_flag` indicates if the branch
+ probabilities used in the decoding of the chroma intra-prediction
+ mode are updated ([Section 9.10](#h-09-10))
+
+ * `intra_chroma_prob` indicates the branch probabilities of the chroma
+ intra-prediction mode decoding tree
+
+
+| ---------------------------------------------- | ----- |
+| update_segmentation() | Type |
+| ---------------------------------------------- | ----- |
+| update_mb_segmentation_map | L(1) |
+| update_segment_feature_data | L(1) |
+| if (update_segment_feature_data) { | |
+| segment_feature_mode | L(1) |
+| for (i = 0; i < 4; i++) { | |
+| quantizer_update | L(1) |
+| if (quantizer_update) { | |
+| quantizer_update_value | L(7) |
+| quantizer_update_sign | L(1) |
+| } | |
+| } | |
+| for (i = 0; i < 4; i++) { | |
+| loop_filter_update | L(1) |
+| if (loop_filter_update) { | |
+| lf_update_value | L(6) |
+| lf_update_sign | L(1) |
+| } | |
+| } | |
+| } | |
+| if (update_mb_segmentation_map) { | |
+| for (i = 0; i < 3; i++) { | |
+| segment_prob_update | L(1) |
+| if (segment_prob_update) | |
+| segment_prob | L(8) |
+| } | |
+| } | |
{:.col1-pre}
- * `color_space` defines the YUV color space of the sequence ([9.2](#h-09-02))
- * `clamping_type` specifies if the decoder is required to clamp the reconstructed pixel values ([9.2](#h-09-02))
- * `segmentation_enabled` enables the segmentation feature for the current frame ([9.3](#h-09-03))
- * `filter_type` determines whether the normal or the simple loop filter is used ([9.4](#h-09-04), [15](#h-15-00))
- * `loop_filter_level` controls the deblocking filter ([9.4](#h-09-04), [15](#h-15-00))
- * `sharpness_level` controls the deblocking filter ([9.4](#h-09-04), [15](#h-15-00))
- * `log2_nbr_of_dct_partitions` determines the number of separate partitions containing the DCT coefficients of the macroblocks ([9.5](#h-09-05))
- * `refresh_entropy_probs` determines whether updated token probabilities are used only for this frame or until further update
- * `refresh_golden_frame` determines if the current decoded frame refreshes the golden frame ([9.7](#h-09-07))
- * `refresh_alternate_frame` determines if the current decoded frame refreshes the alternate reference frame ([9.7](#h-09-07))
- * `copy_buffer_to_golden` determines if the golden reference is replaced by another reference ([9.7](#h-09-07))
- * `copy_buffer_to_alternate` determines if the alternate reference is replaced by another reference ([9.7](#h-09-07))
- * `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_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_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))
- * `intra_chroma_prob` the branch probabilities of the chroma intra prediction mode decoding tree
+ * `update_mb_segmentation_map` determines if the MB segmentation map
+ is updated in the current frame ([Section 9.3](#h-09-03))
+
+ * `update_segment_feature_data` indicates if the segment feature data
+ is updated in the current frame ([Section 9.3](#h-09-03))
+
+ * `segment_feature_mode` indicates the feature data update mode, 0
+ for delta and 1 for the absolute value ([Section 9.3](#h-09-03))
+
+ * `quantizer_update` indicates if the quantizer value is updated for
+ the i^(th) segment ([Section 9.3](#h-09-03))
+
+ * `quantizer_update_value` indicates the update value for the segment
+ quantizer ([Section 9.3](#h-09-03))
+
+ * `quantizer_update_sign` indicates the update sign for the segment
+ quantizer ([Section 9.3](#h-09-03))
+
+ * `loop_filter_update` indicates if the loop filter level value is
+ updated for the i^(th) segment ([Section 9.3](#h-09-03))
+
+ * `lf_update_value` indicates the update value for the loop filter
+ level ([Section 9.3](#h-09-03))
+
+ * `lf_update_sign` indicates the update sign for the loop filter level
+ ([Section 9.3](#h-09-03))
+
+ * `segment_prob_update` indicates whether the branch probabilities
+ used to decode the `segment_id` in the MB header are decoded from
+ the stream or use the default value of 255 ([Section 9.3](#h-09-03))
+
+ * `segment_prob` indicates the branch probabilities of the `segment_id`
+ decoding tree ([Section 9.3](#h-09-03))
-| update_segmentation() | Type |
-| -------------------------------------------- | ----- |
-| `update_mb_segmentation_map` | L(1) |
-| `update_segment_feature_data` | L(1) |
-| `if (update_segment_feature_data) {` | |
-| ` segment_feature_mode` | L(1) |
-| ` for (i = 0; i < 4; i++) {` | |
-| ` quantizer_update` | L(1) |
-| ` if (quantizer_update) {` | |
-| ` quantizer_update_value` | L(7) |
-| ` quantizer_update_sign` | L(1) |
-| ` }` | |
-| ` }` | |
-| ` for (i = 0; i < 4; i++) {` | |
-| ` loop_filter_update` | L(1) |
-| ` if (loop_filter_update) {` | |
-| ` lf_update_value` | L(6) |
-| ` lf_update_sign` | L(1) |
-| ` }` | |
-| ` }` | |
-| `}` | |
-| `if (update_mb_segmentation_map) {` | |
-| ` for (i = 0; i < 3; i++) {` | |
-| ` segment_prob_update` | L(1) |
-| ` if (segment_prob_update) {` | |
-| ` segment_prob` | L(8) |
-| ` }` | |
-| ` }` | |
-| `}` | |
+| ---------------------------------------------- | ----- |
+| mb_lf_adjustments() | Type |
+| ---------------------------------------------- | ----- |
+| loop_filter_adj_enable | L(1) |
+| if (loop_filter_adj_enable) { | |
+| mode_ref_lf_delta_update | L(1) |
+| if (mode_ref_lf_delta_update) { | |
+| for (i = 0; i < 4; i++) { | |
+| ref_frame_delta_update_flag | L(1) |
+| if (ref_frame_delta_update_flag) { | |
+| delta_magnitude | L(6) |
+| delta_sign | L(1) |
+| } | |
+| } | |
+| for (i = 0; i < 4; i++) { | |
+| mb_mode_delta_update_flag | L(1) |
+| if (mb_mode_delta_update_flag) { | |
+| delta_magnitude | L(6) |
+| delta_sign | L(1) |
+| } | |
+| } | |
+| } | |
+| } | |
{:.col1-pre}
- * `update_mb_segmentation_map` determines if the MB segmentation map is updated in the current frame ([9.3](#h-09-03))
- * `update_segment_feature_data` indicates if the segment feature data is updated in the current frame ([9.3](#h-09-03))
- * `segment_feature_mode` indicates the feature data update mode, 0 for delta and 1 for the absolute value ([9.3](#h-09-03))
- * `quantizer_update` indicates if the quantizer value is updated for the [[ i^(th) ]] segment ([9.3](#h-09-03))
- * `quantizer_update_value` indicates the update value for the segment quantizer ([9.3](#h-09-03))
- * `quantizer_update_sign` indicates the update sign for the segment quantizer ([9.3](#h-09-03))
- * `loop_filter_update` indicates if the loop filter level value is updated for the [[ i^(th) ]] segment ([9.3](#h-09-03))
- * `lf_update_value` indicates the update value for the loop filter level ([9.3](#h-09-03))
- * `lf_update_sign` indicates the update sign for the loop filter level ([9.3](#h-09-03))
- * `segment_prob_update` indicates if the branch probabilities used to decode the `segment_id` in the MB header are decoded from the stream or use the default value of 255 ([9.3](#h-09-03))
- * `segment_prob` the branch probabilities of the `segment_id` decoding tree ([9.3](#h-09-03))
+ * `loop_filter_adj_enable` indicates if the MB-level loop filter
+ adjustment (based on the used reference frame and coding mode) is
+ on for the current frame ([Section 9.4](#h-09-04))
+ * `mode_ref_lf_delta_update` indicates if the delta values used in an
+ adjustment are updated in the current frame ([Section 9.4](#h-09-04))
-| mb_lf_adjustments() | Type |
-|----------------------------------------------|-------|
-| `loop_filter_adj_enable` | L(1) |
-| `if (loop_filter_adj_enable) {` | |
-| ` mode_ref_lf_delta_update` | L(1) |
-| ` if (mode_ref_lf_delta_update) {` | |
-| ` for (i = 0; i < 4; i++) {` | |
-| ` ref_frame_delta_update_flag` | L(1) |
-| ` if (ref_frame_delta_update_flag) {` | |
-| ` delta_magnitude` | L(6) |
-| ` delta_sign` | L(1) |
-| ` }` | |
-| ` }` | |
-| ` for (i = 0; i < 4; i++) {` | |
-| ` mb_mode_delta_update_flag` | L(1) |
-| ` if (mb_mode_delta_update_flag) {` | |
-| ` delta_magnitude` | L(6) |
-| ` delta_sign` | L(1) |
-| ` }` | |
-| ` }` | |
-| ` }` | |
-| `}` | |
-{:.col1-pre}
+ * `ref_frame_delta_update_flag` indicates if the adjustment delta
+ value corresponding to a certain used reference frame is updated
+ ([Section 9.4](#h-09-04))
-
- * `loop_filter_adj_enable` indicates if the MB-level loop filter adjustment (based on the used reference frame and coding mode) is on for the current frame ([9.4](#h-09-04))
- * `mode_ref_lf_delta_update` indicates if the delta values used in adjustment are updated in the current frame ([9.4](#h-09-04))
- * `ref_frame_delta_update_flag` indicates if the adjustment delta value corresponding to a certain used reference frame is updated ([9.4](#h-09-04))
* `delta_magnitude` is the absolute value of the delta value
+
* `delta_sign` is the sign of the delta value
- * `mb_mode_delta_update_flag` indicates if the adjustment delta value corresponding to certain MB prediction mode is updated ([9.4](#h-09-04))
+
+ * `mb_mode_delta_update_flag` indicates if the adjustment delta value
+ corresponding to a certain MB prediction mode is updated
+ ([Section 9.4](#h-09-04))
-| quant_indices() | Type |
-|----------------------------------------------|-------|
-| `y_ac_qi` | L(7) |
-| `y_dc_delta_present` | L(1) |
-| `if (y_dc_delta_present) {` | |
-| ` y_dc_delta_magnitude` | L(4) |
-| ` y_dc_delta_sign` | L(1) |
-| `}` | |
-| `y2_dc_delta_present` | L(1) |
-| `if (y2_dc_delta_present) {` | |
-| ` y2_dc_delta_magnitude` | L(4) |
-| ` y2_dc_delta_sign` | L(1) |
-| `}` | |
-| `y2_ac_delta_present` | L(1) |
-| `if (y2_ac_delta_present) {` | |
-| ` y2_ac_delta_magnitude` | L(4) |
-| ` y2_ac_delta_sign` | L(1) |
-| `}` | |
-| `uv_dc_delta_present` | L(1) |
-| `if (uv_dc_delta_present) {` | |
-| ` uv_dc_delta_magnitude` | L(4) |
-| ` uv_dc_delta_sign` | L(1) |
-| `}` | |
-| `uv_ac_delta_present` | L(1) |
-| `if (uv_ac_delta_present) {` | |
-| ` uv_ac_delta_magnitude` | L(4) |
-| ` uv_ac_delta_sign` | L(1) |
-| } | |
+| ---------------------------------------------- | ----- |
+| quant_indices() | Type |
+| ---------------------------------------------- | ----- |
+| y_ac_qi | L(7) |
+| y_dc_delta_present | L(1) |
+| if (y_dc_delta_present) { | |
+| y_dc_delta_magnitude | L(4) |
+| y_dc_delta_sign | L(1) |
+| } | |
+| y2_dc_delta_present | L(1) |
+| if (y2_dc_delta_present) { | |
+| y2_dc_delta_magnitude | L(4) |
+| y2_dc_delta_sign | L(1) |
+| } | |
+| y2_ac_delta_present | L(1) |
+| if (y2_ac_delta_present) { | |
+| y2_ac_delta_magnitude | L(4) |
+| y2_ac_delta_sign | L(1) |
+| } | |
+| uv_dc_delta_present | L(1) |
+| if (uv_dc_delta_present) { | |
+| uv_dc_delta_magnitude | L(4) |
+| uv_dc_delta_sign | L(1) |
+| } | |
+| uv_ac_delta_present | L(1) |
+| if (uv_ac_delta_present) { | |
+| uv_ac_delta_magnitude | L(4) |
+| uv_ac_delta_sign | L(1) |
+| } | |
{:.col1-pre}
- * `y_ac_qi` is the dequantization table index used for the luma AC coefficients (and other coefficient groups if no delta value is present) ([9.6](#h-09-06))
- * `y_dc_delta_present` indicates if the stream contains a delta value that is added to the baseline index to obtain the luma DC coefficient dequantization index ([9.6](#h-09-06))
- * `y_dc_delta_magnitude` the magnitude of the delta value ([9.6](#h-09-06))
- * `y_dc_delta_sign` the sign of the delta value ([9.6](#h-09-06))
- * `y2_dc_delta_present` indicates if the stream contains a delta value that is added to the baseline index to obtain the Y2 block DC coefficient dequantization index ([9.6](#h-09-06))
- * `y2_ac_delta_present` indicates if the stream contains a delta value that is added to the baseline index to obtain the Y2 block AC coefficient dequantization index ([9.6](#h-09-06))
- * `uv_dc_delta_present` indicates if the stream contains a delta value that is added to the baseline index to obtain the chroma DC coefficient dequantization index ([9.6](#h-09-06))
- * `uv_ac_delta_present` indicates if the stream contains a delta value that is added to the baseline index to obtain the chroma AC coefficient dequantization index ([9.6](#h-09-06))
+ * `y_ac_qi` is the dequantization table index used for the luma AC
+ coefficients (and other coefficient groups if no delta value is
+ present) ([Section 9.6](#h-09-06))
+
+ * `y_dc_delta_present` indicates if the stream contains a delta value
+ that is added to the baseline index to obtain the luma DC
+ coefficient dequantization index ([Section 9.6](#h-09-06))
+
+ * `y_dc_delta_magnitude` is the magnitude of the delta value
+ ([Section 9.6](#h-09-06))
+
+ * `y_dc_delta_sign` is the sign of the delta value ([Section 9.6](#h-09-06))
+
+ * `y2_dc_delta_present` indicates if the stream contains a delta value
+ that is added to the baseline index to obtain the Y2 block DC
+ coefficient dequantization index ([Section 9.6](#h-09-06))
+
+ * `y2_ac_delta_present` indicates if the stream contains a delta value
+ that is added to the baseline index to obtain the Y2 block AC
+ coefficient dequantization index ([Section 9.6](#h-09-06))
+
+ * `uv_dc_delta_present` indicates if the stream contains a delta value
+ that is added to the baseline index to obtain the chroma DC
+ coefficient dequantization index ([Section 9.6](#h-09-06))
+
+ * `uv_ac_delta_present` indicates if the stream contains a delta value
+ that is added to the baseline index to obtain the chroma AC
+ coefficient dequantization index ([Section 9.6](#h-09-06))
-| token_prob_update() | Type |
-| -------------------------------------------- | ----- |
-| `for (i = 0; i < 4; i++) {` | |
-| ` for (j = 0; j < 8; j++) {` | |
-| ` for (k = 0; k < 3; k++) {` | |
-| ` for (l = 0; l < 11; l++) {` | |
-| ` coeff_prob_update_flag` | L(1) |
-| ` if (coeff_prob_update_flag) {` | |
-| ` coeff_prob` | L(8) |
-| ` }` | |
-| ` }` | |
-| ` }` | |
-| ` }` | |
-| `}` | |
+| ---------------------------------------------- | ----- |
+| token_prob_update() | Type |
+| ---------------------------------------------- | ----- |
+| for (i = 0; i < 4; i++) { | |
+| for (j = 0; j < 8; j++) { | |
+| for (k = 0; k < 3; k++) { | |
+| for (l = 0; l < 11; l++) { | |
+| coeff_prob_update_flag | L(1) |
+| if (coeff_prob_update_flag) | |
+| coeff_prob | L(8) |
+| } | |
+| } | |
+| } | |
+| } | |
{:.col1-pre}
- * `coeff_prob_update_flag` indicates if the corresponding branch probability is updated in the current frame ([13.4](#h-13-04))
+ * `coeff_prob_update_flag` indicates if the corresponding branch
+ probability is updated in the current frame ([Section 13.4](#h-13-04))
+
* `coeff_prob` is the new branch probability ([13.4](#h-13-04))
-| mv_prob_update() | Type |
-| -------------------------------------------- | ----- |
-| `for (i = 0; i < 2; i++) {` | |
-| ` for (j = 0; j < 19; j++) {` | |
-| ` mv_prob_update_flag` | L(1) |
-| ` if (mv_prob_update_flag) {` | |
-| ` prob` | L(7) |
-| ` }` | |
-| ` }` | |
-| `}` | |
+| ---------------------------------------------- | ----- |
+| mv_prob_update() | Type |
+| ---------------------------------------------- | ----- |
+| for (i = 0; i < 2; i++) { | |
+| for (j = 0; j < 19; j++) { | |
+| mv_prob_update_flag | L(1) |
+| if (mv_prob_update_flag) | |
+| prob | L(7) |
+| } | |
+| } | |
{:.col1-pre}
- * `mv_prob_update_flag` indicates if the corresponding MV decoding probability is updated in the current frame ([17.2](#h-17-02))
- * `prob` is the updated probability ([17.2](#h-17-02))
+ * `mv_prob_update_flag` indicates if the corresponding MV decoding
+ probability is updated in the current frame ([Section 17.2](#h-17-02))
+
+ * `prob` is the updated probability ([Section 17.2](#h-17-02))
diff --git a/text_src/a.03_vp8-bitstream__mb_header.txt b/text_src/a.03_vp8-bitstream__mb_header.txt
index 994aea5..1dd09a8 100644
--- a/text_src/a.03_vp8-bitstream__mb_header.txt
+++ b/text_src/a.03_vp8-bitstream__mb_header.txt
@@ -1,97 +1,125 @@
-#### A.3 Macroblock Data {#h-0a-03}
+#### A.3 Macroblock Data {#h-0a-03}
+| ---------------------------------------------- | ----- |
| Macroblock Data | Type |
-|-------------------- --------------------------|-------|
-| `macroblock_header()` | |
-| `residual_data()` | |
+| ---------------------------------------------- | ----- |
+| macroblock_header() | |
+| residual_data() | |
{:.col1-pre}
+| ---------------------------------------------- | ----- |
| macroblock_header() | Type |
-|------------------------ ----------------------|-------|
-| `if (segmentation_map_update) {` | |
-| ` segment_id` | T |
-| `if (mb_no_skip_coeff) {` | |
-| ` mb_skip_coeff` | B(p) |
-| `}` | |
-| `if (!key_frame) {` | |
-| ` is_inter_mb` | B(p) |
-| `if (is_inter_mb) {` | |
-| ` mb_ref_frame_sel1` | B(p) |
-| ` if (mb_ref_frame_sel1)` | |
-| ` mb_ref_frame_sel2` | B(p) |
-| ` mv_mode` | T |
-| ` if (mv_mode == SPLITMV) {` | |
-| ` mv_split_mode` | T |
-| ` for (i = 0; i < numMvs; i++) {` | |
-| ` sub_mv_mode` | T |
-| ` if (sub_mv_mode == NEWMV4x4) {` | |
-| ` read_mvcomponent()` | |
-| ` read_mvcomponent()` | |
-| ` }` | |
-| ` }` | |
-| ` } else if (mv_mode == NEWMV) {` | |
-| ` read_mvcomponent()` | |
-| ` read_mvcomponent()` | |
-| ` }` | |
-| `} else { /* intra mb */` | |
-| ` intra_y_mode` | T |
+| ---------------------------------------------- | ----- |
+| if (update_mb_segmentation_map) | |
+| segment_id | T |
+| if (mb_no_skip_coeff) | |
+| mb_skip_coeff | B(p) |
+| if (!key_frame) | |
+| is_inter_mb | B(p) |
+| if (is_inter_mb) { | |
+| mb_ref_frame_sel1 | B(p) |
+| if (mb_ref_frame_sel1) | |
+| mb_ref_frame_sel2 | B(p) |
+| mv_mode | T |
+| if (mv_mode == SPLITMV) { | |
+| mv_split_mode | T |
+| for (i = 0; i < numMvs; i++) { | |
+| sub_mv_mode | T |
+| if (sub_mv_mode == NEWMV4x4) { | |
+| read_mvcomponent() | |
+| read_mvcomponent() | |
+| } | |
+| } | |
+| } else if (mv_mode == NEWMV) { | |
+| read_mvcomponent() | |
+| read_mvcomponent() | |
+| } | |
+| } else { /* intra mb */ | |
+| intra_y_mode | T |
+| if (intra_y_mode == B_PRED) { | |
+| for (i = 0; i < 16; i++) | |
+| intra_b_mode | T |
+| } | |
+| intra_uv_mode | T |
+| } | |
{:.col1-pre}
-| macroblock_header() | Type |
-|------------------------------------------------|-------|
-| ` if (intra_y_mode == B_PRED) {` | |
-| ` for (i = 0; i < 16; i++)` | |
-| ` intra_b_mode` | T |
-| ` }` | |
-| ` intra_uv_mode` | T |
-| `}` | |
-{:.col1-pre}
+ * `segment_id` indicates to which segment the macroblock belongs
+ ([Section 10](#h-10-00))
+
+ * `mb_skip_coeff` indicates whether the macroblock contains any coded
+ coefficients or not ([Section 11.1](#h-11-01))
+
+ * `is_inter_mb` indicates whether the macroblock is intra- or inter-
+ coded ([Section 16](#h-16-00))
+
+ * `mb_ref_frame_sel1` selects the reference frame to be used; last
+ frame (0), golden/alternate (1) ([Section 16.2](#h-16-02))
+
+ * `mb_ref_frame_sel2` selects whether the golden (0) or alternate
+ reference frame (1) is used ([Section 16.2](#h-16-02))
+
+ * `mv_mode` determines the macroblock motion vector mode
+ ([Section 16.2](#h-16-02))
+
+ * `mv_split_mode` gives the macroblock partitioning specification and
+ determines the number of motion vectors used (numMvs)
+ ([Section 16.2](#h-16-02))
+
+ * `sub_mv_mode` determines the sub-macroblock motion vector mode for
+ macroblocks coded using the `SPLITMV` motion vector mode
+ ([Section 16.2](#h-16-02))
+
+ * `intra_y_mode` selects the luminance intra-prediction mode
+ ([Section 16.1](#h-16-01))
+
+ * `intra_b_mode` selects the sub-macroblock luminance prediction mode
+ for macroblocks coded using `B_PRED` mode ([Section 16.1](#h-16-01))
+
+ * `intra_uv_mode` selects the chrominance intra-prediction mode
+ ([Section 16.1](#h-16-01))
- * `segment_id` indicates to which segment the macroblock belongs ([10](#h-10-00))
- * `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))
- * `mv_mode` determines the macroblock motion vector mode ([16.2](#h-16-02))
- * `mv_split_mode` gives macroblock partitioning specification and determines number of motion vectors used (numMvs)([16.2](#h-16-02))
- * `sub_mv_mode` determines the sub-macroblock motion vector mode for macroblocks coded using `SPLITMV` motion vector mode ([16.2](#h-16-02))
- * `intra_y_mode` selects the luminance intra prediction mode ([16.1](#h-16-01))
- * `intra_b_mode` selects the sub-macroblock luminance prediction mode for macroblocks coded using `B_PRED` mode ([16.1](#h-16-01))
- * `intra_uv_mode` selects the chrominance intra prediction mode ([16.1](#h-16-01))
-
-
+| ----------------------------------------------------- | ----- |
| residual_data() | Type |
| ----------------------------------------------------- | ----- |
-| `if (!mb_skip_coeff) {` | |
-| ` if ( (is_inter_mb && mv_mode != SPLITMV) \|\|` | |
-| ` (!is_inter_mb && intra_y_mode != B_PRED) ) {` | |
-| ` residual_block() /* Y2 */` | |
-| ` }` | |
-| ` for (i = 0; i < 24; i++)` | |
-| ` residual_block() /* 16 Y, 4 U, 4 V */` | |
-| `}` | |
+| if (!mb_skip_coeff) { | |
+| if ( (is_inter_mb && mv_mode != SPLITMV) || | |
+| (!is_inter_mb && intra_y_mode != B_PRED) ) | |
+| residual_block() /* Y2 */ | |
+| for (i = 0; i < 24; i++) | |
+| residual_block() /* 16 Y, 4 U, 4 V */ | |
+| } | |
{:.col1-pre}
+| ----------------------------------------------------- | ----- |
| residual_block() | Type |
| ----------------------------------------------------- | ----- |
-| `for (i = firstCoeff; i < 16; i++) {` | |
-| ` token` | T |
-| ` if (token == EOB) break;` | |
-| ` if (token_has_extra_bits) {` | |
-| ` extra_bits` | L(n) |
-| ` sign` | L(1) |
+| for (i = firstCoeff; i < 16; i++) { | |
+| token | T |
+| if (token == EOB) break; | |
+| if (token_has_extra_bits) | |
+| extra_bits | L(n) |
+| if (coefficient != 0) | |
+| sign | L(1) |
+| } | |
{:.col1-pre}
- * firstCoeff is 1 for luma blocks of macroblocks containing Y2 subblock, otherwise 0
- * `token` defines the value of the coefficient, the value range of the coefficient or the end of block ([13.2](#h-13-02))
- * `extra_bits` determine the value of the coefficient within the value range defined by `token` ([13.2](#h-13-02))
- * `sign` indicates the sign of the coefficient ([13.2](#h-13-02))
+ * firstCoeff is 1 for luma blocks of macroblocks containing Y2
+ subblock; otherwise 0
+
+ * `token` defines the value of the coefficient, the value range of the
+ coefficient, or the end of block ([Section 13.2](#h-13-02))
+
+ * `extra_bits` determines the value of the coefficient within the
+ value range defined by the `token` ([Section 13.2](#h-13-02))
+
+ * `sign` indicates the sign of the coefficient ([Section 13.2](#h-13-02))
diff --git a/text_src/atch1/00__atch1.txt b/text_src/atch1/00__atch1.txt
new file mode 100644
index 0000000..a770b95
--- /dev/null
+++ b/text_src/atch1/00__atch1.txt
@@ -0,0 +1,4 @@
+
+
+### Attachment One: Reference Decoder Source Code
+
diff --git a/text_src/atch1/AUTHORS b/text_src/atch1/AUTHORS
index 7c7d92f..f4f6af5 100644
--- a/text_src/atch1/AUTHORS
+++ b/text_src/atch1/AUTHORS
@@ -1,86 +1,45 @@
-Aaron Watry <awatry@gmail.com>
-
-Adrian Grange <agrange@google.com>
-
-Alex Converse <alex.converse@gmail.com>
-
-Andoni Morales Alastruey <ylatuya@gmail.com>
-
-Andres Mejia <mcitadel@gmail.com>
-
-Attila Nagy <attilanagy@google.com>
-
-Fabio Pedretti <fabio.ped@libero.it>
-
-Frank Galligan <fgalligan@google.com>
-
-Fredrik Söderquist <fs@opera.com>
-
-Fritz Koenig <frkoenig@google.com>
-
-Gaute Strokkenes <gaute.strokkenes@broadcom.com>
-
-Giuseppe Scrivano <gscrivano@gnu.org>
-
-Guillermo Ballester Valor <gbvalor@gmail.com>
-
-Henrik Lundin <hlundin@google.com>
-
-James Berry <jamesberry@google.com>
-
-James Zern <jzern@google.com>
-
-Jan Kratochvil <jan.kratochvil@redhat.com>
-
-Jeff Muizelaar <jmuizelaar@mozilla.com>
-
-Jim Bankoski <jimbankoski@google.com>
-
-Johann Koenig <johannkoenig@google.com>
-
-John Koleszar <jkoleszar@google.com>
-
-Justin Clift <justin@salasaga.org>
-
-Justin Lebar <justin.lebar@gmail.com>
-
-Luca Barbato <lu_zero@gentoo.org>
-
-Makoto Kato <makoto.kt@gmail.com>
-
-Martin Ettl <ettl.martin78@googlemail.com>
-
-Michael Kohler <michaelkohler@live.com>
-
-Mikhal Shemer <mikhal@google.com>
-
-Pascal Massimino <pascal.massimino@gmail.com>
-
-Patrik Westin <patrik.westin@gmail.com>
-
-Paul Wilkins <paulwilkins@google.com>
-
-Pavol Rusnak <stick@gk2.sk>
-
-Philip Jägenstedt <philipj@opera.com>
-
-Scott LaVarnway <slavarnway@google.com>
-
-Tero Rintaluoma <teror@google.com>
-
-Timothy B. Terriberry <tterribe@xiph.org>
-
-Tom Finegan <tomfinegan@google.com>
-
-Yaowu Xu <yaowu@google.com>
-
-Yunqing Wang <yunqingwang@google.com>
-
-Google Inc.
-
-The Mozilla Foundation
-
-The Xiph.Org Foundation
+Aaron Watry <awatry@gmail.com>
+Adrian Grange <agrange@google.com>
+Alex Converse <alex.converse@gmail.com>
+Andoni Morales Alastruey <ylatuya@gmail.com>
+Andres Mejia <mcitadel@gmail.com>
+Attila Nagy <attilanagy@google.com>
+Fabio Pedretti <fabio.ped@libero.it>
+Frank Galligan <fgalligan@google.com>
+Fredrik Söderquist <fs@opera.com>
+Fritz Koenig <frkoenig@google.com>
+Gaute Strokkenes <gaute.strokkenes@broadcom.com>
+Giuseppe Scrivano <gscrivano@gnu.org>
+Guillermo Ballester Valor <gbvalor@gmail.com>
+Henrik Lundin <hlundin@google.com>
+James Berry <jamesberry@google.com>
+James Zern <jzern@google.com>
+Jan Kratochvil <jan.kratochvil@redhat.com>
+Jeff Muizelaar <jmuizelaar@mozilla.com>
+Jim Bankoski <jimbankoski@google.com>
+Johann Koenig <johannkoenig@google.com>
+John Koleszar <jkoleszar@google.com>
+Justin Clift <justin@salasaga.org>
+Justin Lebar <justin.lebar@gmail.com>
+Luca Barbato <lu_zero@gentoo.org>
+Makoto Kato <makoto.kt@gmail.com>
+Martin Ettl <ettl.martin78@googlemail.com>
+Michael Kohler <michaelkohler@live.com>
+Mikhal Shemer <mikhal@google.com>
+Pascal Massimino <pascal.massimino@gmail.com>
+Patrik Westin <patrik.westin@gmail.com>
+Paul Wilkins <paulwilkins@google.com>
+Pavol Rusnak <stick@gk2.sk>
+Philip Jägenstedt <philipj@opera.com>
+Scott LaVarnway <slavarnway@google.com>
+Tero Rintaluoma <teror@google.com>
+Timothy B. Terriberry <tterribe@xiph.org>
+Tom Finegan <tomfinegan@google.com>
+Yaowu Xu <yaowu@google.com>
+Yunqing Wang <yunqingwang@google.com>
+Google Inc.
+The Mozilla Foundation
+The Xiph.Org Foundation
diff --git a/text_src/atch1/bit_ops.h b/text_src/atch1/bit_ops.h
index 0c37a32..abeb71f 100644
--- a/text_src/atch1/bit_ops.h
+++ b/text_src/atch1/bit_ops.h
@@ -1,12 +1,13 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
+
#ifndef BIT_OPS_H
#define BIT_OPS_H
diff --git a/text_src/atch1/bool_decoder.h b/text_src/atch1/bool_decoder.h
index 48d2dec..8389a17 100644
--- a/text_src/atch1/bool_decoder.h
+++ b/text_src/atch1/bool_decoder.h
@@ -1,13 +1,13 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
- * Use of this source code is governed by a BSD-style license and
- * patent grant that can be found in the LICENSE file in the root of
- * the source tree. All contributing project authors may be found in
- * the AUTHORS file in the root of the source tree.
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
*/
-
#ifndef BOOL_DECODER_H
#define BOOL_DECODER_H
#include <stddef.h>
diff --git a/text_src/atch1/dequant_data.h b/text_src/atch1/dequant_data.h
index a03583e..bb641c0 100644
--- a/text_src/atch1/dequant_data.h
+++ b/text_src/atch1/dequant_data.h
@@ -1,3 +1,13 @@
+/*
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
+ *
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
+ */
+
static const int dc_q_lookup[128] =
{
4, 5, 6, 7, 8, 9, 10, 10,
@@ -17,6 +27,7 @@
122, 124, 126, 128, 130, 132, 134, 136,
138, 140, 143, 145, 148, 151, 154, 157
};
+
static const int ac_q_lookup[128] =
{
4, 5, 6, 7, 8, 9, 10, 11,
diff --git a/text_src/atch1/dixie.c b/text_src/atch1/dixie.c
index 883f7fb..2982906 100644
--- a/text_src/atch1/dixie.c
+++ b/text_src/atch1/dixie.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -492,7 +492,7 @@
if (sz < 10)
return VPX_CODEC_CORRUPT_FRAME;
- /* The frame header is defined as a three byte little endian
+ /* The frame header is defined as a three-byte little endian
* value
*/
raw = data[0] | (data[1] << 8) | (data[2] << 16);
@@ -511,7 +511,7 @@
{
unsigned int update = 0;
- /* Keyframe header consists of a three byte sync code
+ /* Keyframe header consists of a three-byte sync code
* followed by the width and height and associated scaling
* factors.
*/
diff --git a/text_src/atch1/dixie.h b/text_src/atch1/dixie.h
index 84a75a5..35cf7cf 100644
--- a/text_src/atch1/dixie.h
+++ b/text_src/atch1/dixie.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/dixie_loopfilter.c b/text_src/atch1/dixie_loopfilter.c
index eea6cad..18f1016 100644
--- a/text_src/atch1/dixie_loopfilter.c
+++ b/text_src/atch1/dixie_loopfilter.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -373,7 +373,7 @@
{
int edge_limit, interior_limit, hev_threshold;
- /* TODO: only need to recalculate every MB if segmentation is
+ /* TODO: Only need to recalculate every MB if segmentation is
* enabled.
*/
calculate_filter_parameters(ctx, mbi, &edge_limit,
@@ -393,8 +393,8 @@
/* NOTE: This conditional is actually dependent on the
* number of coefficients decoded, not the skip flag as
- * coded in the bitstream. The tokens task is expected to
- * set 31 if there is *any* non-zero data.
+ * coded in the bitstream. The tokens task is expected
+ * to set 31 if there is *any* non-zero data.
*/
if (mbi->base.eob_mask
|| mbi->base.y_mode == SPLITMV
@@ -478,7 +478,7 @@
{
int edge_limit, interior_limit, hev_threshold;
- /* TODO: only need to recalculate every MB if segmentation is
+ /* TODO: Only need to recalculate every MB if segmentation is
* enabled.
*/
calculate_filter_parameters(ctx, mbi, &edge_limit,
@@ -489,8 +489,8 @@
/* NOTE: This conditional is actually dependent on the
* number of coefficients decoded, not the skip flag as
- * coded in the bitstream. The tokens task is expected to
- * set 31 if there is *any* non-zero data.
+ * coded in the bitstream. The tokens task is expected
+ * to set 31 if there is *any* non-zero data.
*/
int filter_subblocks = (mbi->base.eob_mask
|| mbi->base.y_mode == SPLITMV
diff --git a/text_src/atch1/dixie_loopfilter.h b/text_src/atch1/dixie_loopfilter.h
index ce7bbac..2cd90dc 100644
--- a/text_src/atch1/dixie_loopfilter.h
+++ b/text_src/atch1/dixie_loopfilter.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/idct_add.c b/text_src/atch1/idct_add.c
index eecbb48..bf867cf 100644
--- a/text_src/atch1/idct_add.c
+++ b/text_src/atch1/idct_add.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/idct_add.h b/text_src/atch1/idct_add.h
index a55b57d..0023b30 100644
--- a/text_src/atch1/idct_add.h
+++ b/text_src/atch1/idct_add.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/mem.h b/text_src/atch1/mem.h
index 5f42b69..fe6edb9 100644
--- a/text_src/atch1/mem.h
+++ b/text_src/atch1/mem.h
@@ -1,14 +1,12 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
-
-
#ifndef VPX_PORTS_MEM_H
#define VPX_PORTS_MEM_H
#include "vpx_config.h"
diff --git a/text_src/atch1/modemv.c b/text_src/atch1/modemv.c
index 0def09c..e8e6320 100644
--- a/text_src/atch1/modemv.c
+++ b/text_src/atch1/modemv.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -378,7 +378,7 @@
cnt[CNT_ZEROZERO] += 1;
}
- /* If we have three distinct MV's ... */
+ /* If we have three distinct MVs ... */
if (cnt[CNT_SPLITMV])
{
/* See if above-left MV can be merged with NEAREST */
@@ -459,7 +459,7 @@
assert(0);
}
- /* Fill the MV's for this partition */
+ /* Fill the MVs for this partition */
for (; k < 16; k++)
if (j == partition[k])
{
diff --git a/text_src/atch1/modemv.h b/text_src/atch1/modemv.h
index 8ac1bf4..3d13773 100644
--- a/text_src/atch1/modemv.h
+++ b/text_src/atch1/modemv.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/modemv_data.h b/text_src/atch1/modemv_data.h
index d6e67b5..21d09c8 100644
--- a/text_src/atch1/modemv_data.h
+++ b/text_src/atch1/modemv_data.h
@@ -1,3 +1,12 @@
+/*
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
+ *
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
+ */
static const unsigned char kf_y_mode_probs[] = { 145, 156, 163, 128};
static const unsigned char kf_uv_mode_probs[] = { 142, 114, 183};
static const unsigned char kf_b_mode_probs[10][10][9] =
diff --git a/text_src/atch1/predict.c b/text_src/atch1/predict.c
index 6294a90..00a8411 100644
--- a/text_src/atch1/predict.c
+++ b/text_src/atch1/predict.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -30,7 +30,7 @@
{ 3, -16, 77, 77, -16, 3 },
{ 0, -6, 50, 93, -9, 0 },
{ 1, -8, 36, 108, -11, 2 },
- { 0, -1, 12, 123, -6, 0 },
+ { 0, -1, 12, 123, -6, 0 }
};
@@ -775,7 +775,7 @@
{
int mx, my;
- /* Handle 0,0 as a special case. TODO: does this make it any
+ /* Handle 0,0 as a special case. TODO: Does this make it any
* faster?
*/
if (!mv->raw)
@@ -968,7 +968,7 @@
int mb_col,
int mb_row)
{
- /* TODO: move this into its own buffer. This only works because
+ /* TODO: Move this into its own buffer. This only works because
* we still have a border allocated.
*/
unsigned char *emul_block = ctx->frame_strg[0].img.img_data;
diff --git a/text_src/atch1/predict.h b/text_src/atch1/predict.h
index d1d18a2..487f895 100644
--- a/text_src/atch1/predict.h
+++ b/text_src/atch1/predict.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/tokens.c b/text_src/atch1/tokens.c
index 414de09..bc84e28 100644
--- a/text_src/atch1/tokens.c
+++ b/text_src/atch1/tokens.c
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -283,7 +283,7 @@
b_tokens[zigzag[15]] = v;
BLOCK_FINISHED:
eob_mask |= (c > 1) << i;
- t = (c != !type); // any nonzero data?
+ t = (c != !type); // any non-zero data?
eob_mask |= t << 31;
left[left_context_index[i]] = above[above_context_index[i]] = t;
@@ -337,8 +337,8 @@
token_entropy_ctx_t *above,
enum prediction_mode mode)
{
- /* Reset the macroblock context on the left and right. We have to
- * preserve the context of the second order block if this mode
+ /* Reset the macroblock context on the left and right. We have
+ * to preserve the context of the second order block if this mode
* would not have updated it.
*/
memset(left, 0, sizeof((*left)[0]) * 8);
diff --git a/text_src/atch1/tokens.h b/text_src/atch1/tokens.h
index 304234b..72993d3 100644
--- a/text_src/atch1/tokens.h
+++ b/text_src/atch1/tokens.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
diff --git a/text_src/atch1/vp8_prob_data.h b/text_src/atch1/vp8_prob_data.h
index f4256ec..10029fe 100644
--- a/text_src/atch1/vp8_prob_data.h
+++ b/text_src/atch1/vp8_prob_data.h
@@ -1,3 +1,13 @@
+/*
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
+ *
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
+ */
+
static const
unsigned char k_coeff_entropy_update_probs[BLOCK_TYPES][COEFF_BANDS]
[PREV_COEFF_CONTEXTS]
diff --git a/text_src/atch1/vpx_codec_internal.h b/text_src/atch1/vpx_codec_internal.h
index 9e991c5..611aefa 100644
--- a/text_src/atch1/vpx_codec_internal.h
+++ b/text_src/atch1/vpx_codec_internal.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -40,7 +40,7 @@
* }
* </pre>
*
- * Once initialized, the instance is manged using other functions
+ * Once initialized, the instance is managed using other functions
* from the vpx_codec_* family.
*/
#ifndef VPX_CODEC_INTERNAL_H
@@ -52,10 +52,11 @@
/*!\brief Current ABI version number
*
* \internal
- * If this file is altered in any way that changes the ABI, this
- * value must be bumped. Examples include, but are not limited to,
- * changing types, removing or reassigning enums,
- * adding/removing/rearranging fields to structures
+ * If this file is altered in any way that changes the Application
+ * Binary Interface (ABI), this value must be bumped. Examples
+ * include, but are not limited to, changing types, removing or
+ * reassigning enums, adding/removing/rearranging fields to
+ * structures.
*/
#define VPX_CODEC_INTERNAL_ABI_VERSION (3)
@@ -101,10 +102,10 @@
*
* \param[in] data Pointer to a block of data to parse
* \param[in] data_sz Size of the data buffer
- * \param[in,out] si Pointer to stream info to update. The size
- * member \ref MUST be properly initialized,
- * but \ref MAY be clobbered by the
- * algorithm. This parameter \ref MAY be
+ * \param[in,out] si Pointer to stream info to update. The
+ * size member \ref MUST be properly
+ * initialized, but \ref MAY be clobbered by
+ * the algorithm. This parameter \ref MAY be
* NULL.
*
* \retval #VPX_CODEC_OK
@@ -121,11 +122,11 @@
* decoding.
*
* \param[in] ctx Pointer to this instance's context
- * \param[in,out] si Pointer to stream info to update. The size
- * member \ref MUST be properly initialized,
- * but \ref MAY be clobbered by the
- * algorithm. This parameter \ref MAY be
- * NULL.
+ * \param[in,out] si Pointer to stream info to update. The
+ * size member \ref MUST be properly
+ * initialized, but \ref MAY be clobbered by
+ * the algorithm. This parameter \ref MAY
+ * be NULL.
*
* \retval #VPX_CODEC_OK
* Bitstream is parsable and stream information updated
@@ -136,7 +137,7 @@
/*!\brief control function pointer prototype
*
- * This function is used to exchange algorithm specific data with the
+ * This function is used to exchange algorithm-specific data with the
* decoder instance. This can be used to implement features specific
* to a particular algorithm.
*
@@ -147,11 +148,11 @@
* assign meanings to the control codes. Those details should be
* specified in the algorithm's header file. In particular, the
* ctrl_id parameter is guaranteed to exist in the algorithm's
- * control mapping table, and the data paramter may be NULL.
+ * control mapping table, and the data parameter may be NULL.
*
*
* \param[in] ctx Pointer to this instance's context
- * \param[in] ctrl_id Algorithm specific control identifier
+ * \param[in] ctrl_id Algorithm-specific control identifier
* \param[in,out] data Data to exchange with algorithm instance.
*
* \retval #VPX_CODEC_OK
@@ -166,11 +167,11 @@
*
* This structure stores the mapping between control identifiers and
* implementing functions. Each algorithm provides a list of these
- * mappings. This list is searched by the vpx_codec_control() wrapper
- * function to determine which function to invoke. The special
- * value {0, NULL} is used to indicate end-of-list, and must be
- * present. The special value {0, <non-null>} can be used as a
- * catch-all mapping. This implies that ctrl_id values chosen by the
+ * mappings. This list is searched by the vpx_codec_control()
+ * wrapper function to determine which function to invoke. The
+ * special value {0, NULL} is used to indicate end-of-list, and must
+ * be present. The special value {0, <non-null>} can be used as a
+ * catch-all mapping. This implies that ctrl_id values chosen by the
* algorithm \ref MUST be non-zero.
*/
typedef const struct
@@ -183,14 +184,14 @@
*
* Processes a buffer of coded data. If the processing results in a
* new decoded frame becoming available, #VPX_CODEC_CB_PUT_SLICE and
- * #VPX_CODEC_CB_PUT_FRAME events are generated as appropriate. This
- * function is called by the generic vpx_codec_decode() wrapper
+ * #VPX_CODEC_CB_PUT_FRAME events are generated as appropriate.
+ * This function is called by the generic vpx_codec_decode() wrapper
* function, so plugins implementing this interface may trust the
* input parameters to be properly initialized.
*
* \param[in] ctx Pointer to this instance's context
- * \param[in] data Pointer to this block of new coded data. If
- * NULL, a #VPX_CODEC_CB_PUT_FRAME event is
+ * \param[in] data Pointer to this block of new coded data.
+ * If NULL, a #VPX_CODEC_CB_PUT_FRAME event is
* posted for the previously decoded frame.
* \param[in] data_sz Size of the coded data, in bytes.
*
@@ -237,7 +238,7 @@
*
* \param[in out] iter Iterator storage, initialized to NULL
*
- * \return Returns a pointer to an memory segment descriptor, or NULL
+ * \return Returns a pointer to a memory segment descriptor, or NULL
* to indicate end-of-list.
*/
typedef vpx_codec_err_t (*vpx_codec_get_mmap_fn_t)(
@@ -353,7 +354,7 @@
* can be extended in one of two ways. First, a second, algorithm
* specific structure can be allocated and the priv member pointed to
* it. Alternatively, this structure can be made the first member of
- * the algorithm specific structure, and the pointer casted to the
+ * the algorithm-specific structure, and the pointer casted to the
* proper type.
*/
struct vpx_codec_priv
diff --git a/text_src/atch1/vpx_decoder.h b/text_src/atch1/vpx_decoder.h
index 8f4229b..1b1f862 100644
--- a/text_src/atch1/vpx_decoder.h
+++ b/text_src/atch1/vpx_decoder.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
@@ -12,8 +12,8 @@
/*!\defgroup decoder Decoder Algorithm Interface
* \ingroup codec
* This abstraction allows applications using this decoder to easily
- * support multiple video formats with minimal code duplication. This
- * section describes the interface common to all decoders.
+ * support multiple video formats with minimal code duplication.
+ * This section describes the interface common to all decoders.
* @{
*/
@@ -49,7 +49,7 @@
* are extra interfaces or functionality, and are not required
* to be supported by a decoder.
*
- * The available flags are specifiedby VPX_CODEC_CAP_* defines.
+ * The available flags are specified by VPX_CODEC_CAP_* defines.
*/
#define VPX_CODEC_CAP_PUT_SLICE 0x10000 /**< Will issue put_slice
callbacks */
@@ -71,8 +71,8 @@
/*!\brief Stream properties
*
* This structure is used to query or set properties of the
- * decoded stream. Algorithms may extend this structure with data
- * specific to their bitstream by setting the sz member
+ * decoded stream. Algorithms may extend this structure with
+ * data specific to their bitstream by setting the sz member
* appropriately.
*/
typedef struct vpx_codec_stream_info
@@ -118,7 +118,7 @@
* been set.
*
* \param[in] ctx Pointer to this instance's context.
- * \param[in] iface Pointer to the alogrithm interface to
+ * \param[in] iface Pointer to the algorithm interface to
* use.
* \param[in] cfg Configuration to use, if known. May be
* NULL.
@@ -153,7 +153,7 @@
* if the bitstream is of the proper format, and to extract
* information from the stream.
*
- * \param[in] iface Pointer to the alogrithm interface
+ * \param[in] iface Pointer to the algorithm interface
* \param[in] data Pointer to a block of data to parse
* \param[in] data_sz Size of the data buffer
* \param[in,out] si Pointer to stream info to update. The
@@ -195,8 +195,8 @@
/*!\brief Decode data
*
- * Processes a buffer of coded data. If the processing results in
- * a new decoded frame becoming available, PUT_SLICE and
+ * Processes a buffer of coded data. If the processing results
+ * in a new decoded frame becoming available, PUT_SLICE and
* PUT_FRAME events may be generated, as appropriate. Encoded
* data \ref MUST be passed in DTS (decode time stamp) order.
* Frames produced will always be in PTS (presentation time
@@ -208,7 +208,7 @@
* VPX_CODEC_CB_PUT_FRAME event is posted
* for the previously decoded frame.
* \param[in] data_sz Size of the coded data, in bytes.
- * \param[in] user_priv Application specific data to associate
+ * \param[in] user_priv Application-specific data to associate
* with this frame.
* \param[in] deadline Soft deadline the decoder should
* attempt to meet, in us. Set to zero
diff --git a/text_src/atch1/vpx_decoder_compat.h b/text_src/atch1/vpx_decoder_compat.h
index 79c5a29..26d02ef 100644
--- a/text_src/atch1/vpx_decoder_compat.h
+++ b/text_src/atch1/vpx_decoder_compat.h
@@ -1,18 +1,18 @@
/*
- * Copyright (c) 2010 The WebM project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
- * Use of this source code is governed by a BSD-style license
- * that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
- * found in the file PATENTS. All contributing project authors may
- * be found in the AUTHORS file in the root of the source tree.
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
*/
/*!\defgroup decoder Common Decoder Algorithm Interface
* This abstraction allows applications using this decoder to easily
- * support multiple video formats with minimal code duplication. This
- * section describes the interface common to all codecs.
+ * support multiple video formats with minimal code duplication.
+ * This section describes the interface common to all codecs.
* @{
*/
@@ -20,8 +20,8 @@
* \brief Provides a compatibility layer between version 1 and 2 of
* this API.
*
- * This interface has been deprecated. Only existing code should make
- * use of this interface, and therefore, it is only thinly
+ * This interface has been deprecated. Only existing code should
+ * make use of this interface, and therefore, it is only thinly
* documented. Existing code should be ported to the vpx_codec_* API.
*/
#ifdef __cplusplus
@@ -56,10 +56,11 @@
/*!\brief Encoded bitstream uses an unsupported feature
*
* The decoder does not implement a feature required by the
- * encoder. This return code should only be used for features
- * that prevent future pictures from being properly decoded.
- * This error \ref MAY be treated as fatal to the stream or
- * \ref MAY be treated as fatal to the current GOP.
+ * encoder. This return code should only be used for
+ * features that prevent future pictures from being properly
+ * decoded. This error \ref MAY be treated as fatal to the
+ * stream or \ref MAY be treated as fatal to the current
+ * Group of Pictures (GOP).
*/
VPX_DEC_UNSUP_FEATURE = VPX_CODEC_UNSUP_FEATURE,
@@ -102,7 +103,7 @@
callbacks */
#define VPX_DEC_CAP_PUT_FRAME 0x0002 /**< Will issue put_frame
callbacks */
-#define VPX_DEC_CAP_XMA 0x0004 /**< Supports eXternal Memory
+#define VPX_DEC_CAP_XMA 0x0004 /**< Supports External Memory
Allocation */
/*!\brief Stream properties
@@ -184,8 +185,8 @@
/*!\brief Convert error number to printable string
*
* Returns a human readable string for the last error returned
- * by the algorithm. The returned error will be one line and will
- * not contain any newline characters.
+ * by the algorithm. The returned error will be one line and
+ * will not contain any newline characters.
*
*
* \param[in] err Error number.
@@ -328,7 +329,7 @@
/*!\brief Control algorithm
*
- * This function is used to exchange algorithm specific data with
+ * This function is used to exchange algorithm-specific data with
* the decoder instance. This can be used to implement features
* specific to a particular algorithm.
*
@@ -338,7 +339,7 @@
* the request could not be dispatched.
*
* \param[in] ctx Pointer to this instance's context
- * \param[in] ctrl_id Algorithm specific control
+ * \param[in] ctrl_id Algorithm-specific control
* identifier
* \param[in,out] data Data to exchange with algorithm
* instance.
@@ -356,12 +357,12 @@
/*!\brief Decode data
*
- * Processes a buffer of coded data. If the processing results in
- * a new decoded frame becoming available, #VPX_DEC_CB_PUT_SLICE
- * and #VPX_DEC_CB_PUT_FRAME events may be generated, as
- * appropriate. Encoded data \ref MUST be passed in DTS (decode
- * time stamp) order. Frames produced will always be in PTS
- * (presentation time stamp) order.
+ * Processes a buffer of coded data. If the processing results
+ * in a new decoded frame becoming available,
+ * #VPX_DEC_CB_PUT_SLICE and #VPX_DEC_CB_PUT_FRAME events may be
+ * generated, as appropriate. Encoded data \ref MUST be passed
+ * in DTS (decode time stamp) order. Frames produced will always
+ * be in PTS (presentation time stamp) order.
*
* \param[in] ctx Pointer to this instance's context
* \param[in] data Pointer to this block of new coded
@@ -369,7 +370,7 @@
* event is posted for the previously
* decoded frame.
* \param[in] data_sz Size of the coded data, in bytes.
- * \param[in] user_priv Application specific data to associate
+ * \param[in] user_priv Application-specific data to associate
* with this frame.
* \param[in] rel_pts PTS relative to the previous frame, in
* us. If unknown or unavailable, set to
@@ -580,17 +581,17 @@
/*!\brief Iterate over the list of segments to allocate.
*
- * Iterates over a list of the segments to allocate. The iterator
- * storage should be initialized to NULL to start the iteration.
- * Iteration is complete when this function returns
- * VPX_DEC_LIST_END. The amount of memory needed to allocate is
- * dependent upon the size of the encoded stream. This means that
- * the stream info structure must be known at allocation time. It
- * can be populated with the vpx_dec_peek_stream_info() function.
- * In cases where the stream to be decoded is not available at
- * allocation time, a fixed size must be requested. The decoder
- * will not be able to decode streams larger than the size used
- * at allocation time.
+ * Iterates over a list of the segments to allocate. The
+ * iterator storage should be initialized to NULL to start the
+ * iteration. Iteration is complete when this function returns
+ * VPX_DEC_LIST_END. The amount of memory needed to allocate is
+ * dependent upon the size of the encoded stream. This means
+ * that the stream info structure must be known at allocation
+ * time. It can be populated with the vpx_dec_peek_stream_info()
+ * function. In cases where the stream to be decoded is not
+ * available at allocation time, a fixed size must be requested.
+ * The decoder will not be able to decode streams larger than the
+ * size used at allocation time.
*
* \param[in] ctx Pointer to this instance's context.
* \param[out] mmap Pointer to the memory map entry to
diff --git a/text_src/atch1/vpx_image.c b/text_src/atch1/vpx_image.c
index 9ce4e13..d481c6b 100644
--- a/text_src/atch1/vpx_image.c
+++ b/text_src/atch1/vpx_image.c
@@ -1,11 +1,11 @@
/*
- * Copyright (c) 2010 The WebM project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
- * Use of this source code is governed by a BSD-style license
- * that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
- * found in the file PATENTS. All contributing project authors may
- * be found in the AUTHORS file in the root of the source tree.
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
*/
@@ -240,10 +240,10 @@
{
/* Note: In the calculation pointer adjustment calculation, we
* want the rhs to be promoted to a signed type. Section 6.3.1.8
- * of the ISO C99 standard indicates that if the adjustment
- * parameter is unsigned, the stride parameter will be promoted
- * to unsigned, causing errors when the lhs is a larger type than
- * the rhs.
+ * of the ISO C99 standard [ISO-C99] indicates that if the
+ * adjustment parameter is unsigned, the stride parameter will
+ * be promoted to unsigned, causing errors when the lhs is a
+ * larger type than the rhs.
*/
img->planes[VPX_PLANE_Y] += (signed)
(img->d_h - 1) * img->stride[VPX_PLANE_Y];
diff --git a/text_src/atch1/vpx_image.h b/text_src/atch1/vpx_image.h
index d61617d..82724b1 100644
--- a/text_src/atch1/vpx_image.h
+++ b/text_src/atch1/vpx_image.h
@@ -1,11 +1,11 @@
/*
- * Copyright (c) 2010 The WebM project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
- * Use of this source code is governed by a BSD-style license
- * that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
- * found in the file PATENTS. All contributing project authors may
- * be found in the AUTHORS file in the root of the source tree.
+ * Use of this source code is governed by a BSD-style license
+ * that can be found in the LICENSE file in the root of the source
+ * tree. An additional intellectual property rights grant can be
+ * found in the file PATENTS. All contributing project authors may
+ * be found in the AUTHORS file in the root of the source tree.
*/
@@ -187,8 +187,8 @@
* Returns a descriptor for storing an image of the given format.
* The storage for the descriptor is allocated on the heap.
*
- * \param[in] img Pointer to storage for descriptor. If
- * this parameter is NULL, the storage
+ * \param[in] img Pointer to storage for descriptor.
+ * If this parameter is NULL, the storage
* for the descriptor will be allocated
* on the heap.
* \param[in] fmt Format for the image
@@ -214,8 +214,8 @@
* The storage for descriptor has been allocated elsewhere, and a
* descriptor is desired to "wrap" that storage.
*
- * \param[in] img Pointer to storage for descriptor. If
- * this parameter is NULL, the storage
+ * \param[in] img Pointer to storage for descriptor.
+ * If this parameter is NULL, the storage
* for the descriptor will be
* allocated on the heap.
* \param[in] fmt Format for the image
@@ -249,7 +249,7 @@
* \param[in] w width
* \param[in] h height
*
- * \return 0 if the requested rectangle is valid, nonzero
+ * \return 0 if the requested rectangle is valid, non-zero
* otherwise.
*/
int vpx_img_set_rect(vpx_image_t *img,
diff --git a/text_src/atch1/vpx_integer.h b/text_src/atch1/vpx_integer.h
index ff83919..23eb46d 100644
--- a/text_src/atch1/vpx_integer.h
+++ b/text_src/atch1/vpx_integer.h
@@ -1,9 +1,9 @@
/*
- * Copyright (c) 2010 The VP8 project authors. All Rights Reserved.
+ * Copyright (c) 2010, 2011, Google Inc. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
- * tree. An additional intellectual property rights grant can be
+ * tree. An additional intellectual property rights grant can be
* found in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
