chromium / webm / bitstream-guide / 6ce3fb29c1a3c178da271e0b6589ec099171e576^2..6ce3fb29c1a3c178da271e0b6589ec099171e576 / .

commit | 6ce3fb29c1a3c178da271e0b6589ec099171e576 | [log] [tgz] |
---|---|---|

author | Lou Quillio <louquillio@google.com> | Mon May 16 19:30:01 2011 |

committer | Code Review <code-review@webmproject.org> | Mon May 16 19:30:01 2011 |

tree | c9c51971c48e3a67adf5dd5bb21cb7913469dab6 | |

parent | f7f9bb617a10163ded3b9b1a9d3c7ad8bd6ccdba [diff] | |

parent | 75582f114dffcbaf3530e88d5ddba7832cba8f9d [diff] |

Merge "Strike unclear comment, 12.3 https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/d76485da84a72029# Change-Id: I5ebd987143060135531f4c8d7b13f53b079a6b96 modified: text_src/12.03__vp8-bitstream__luma-prediction.txt"

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 42bb661..9936fb4 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

@@ -23,7 +23,7 @@ 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. -A related matter, which is true for most lossless compression formats, 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. +A related matter is that seeking within a partition is not supported. The data must be decompressed and processed (or at least stored) in the order in which it occurs in the partition. While this document specifies the ordering of the partition data correctly, the details and semantics of this data are discussed in a more logical fashion to facilitate comprehension. For example, the frame header contains updates to many probability tables used in decoding per-macroblock data. The latter is often described before the layouts of the probabilities and their updates, even though this is the opposite of their order in the bitstream.

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 e49f9da..6a9cda4 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

@@ -53,7 +53,7 @@ {:lang="c"} -While in general all DCT coefficients are decoded using the same tree, decoding of certain DCT coefficients may skip the first branch, whose preceding coefficient is a `DCT_0`. This makes use of the fact that in any block last non zero coefficient before the end of the block is not `0`, therefore no `dct_eob` follows a `DCT_0` coefficient in any block. +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.

diff --git a/text_src/13.03__vp8-bitstream__token-probabilities.txt b/text_src/13.03__vp8-bitstream__token-probabilities.txt index 56dc2b0..da58239 100644 --- a/text_src/13.03__vp8-bitstream__token-probabilities.txt +++ b/text_src/13.03__vp8-bitstream__token-probabilities.txt

@@ -43,7 +43,7 @@ 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. +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.