mirror of
https://github.com/google/brotli.git
synced 2024-11-21 19:20:09 +00:00
Use consistent bit ordering and variable names
If bit-orderings are to be parsed from left-to-right, then make the bit-strings left-justified. If bit-orderings are to be parsed from right-to-left, then make the bit-strings right-justified. Section 3.1, which describes how prefix codes work shows prefix codes that are "left-to-right", which is better for demonstrating how the work. However, most of the rest of the document uses a "right-to-left" convention. We should distinctly say at the end of section 3.1 that we are switching conventions. Thus, change the prefix code in section 3.5 to be "right-to-left" to be consistent with sections 9.1 and 9.2. Also, change the variable names in section 7.3 to be consistent with those used in section 10. Also, change the description of MNIBBLES to be "MNIBBLES - 4", similar to the convention of saying "MLEN - 1". Beforehand, the phrase "If MNIBBLES is 0, then ..." was unclear whether it meant MNIBBLES before the "plus 4" or after.
This commit is contained in:
parent
4f1fce1681
commit
c996c06e8d
@ -217,7 +217,7 @@ In other words, if one were to print out the compressed data as
|
||||
a sequence of bytes, starting with the first byte at the
|
||||
*right* margin and proceeding to the *left*, with the most-
|
||||
significant bit of each byte on the left as usual, one would be
|
||||
able to parse the result from right to left, with fixed-width
|
||||
able to parse the result from right-to-left, with fixed-width
|
||||
elements in the correct MSB-to-LSB order and prefix codes in
|
||||
bit-reversed order (i.e., with the first bit of the code in the
|
||||
relative LSB position).
|
||||
@ -424,8 +424,8 @@ the leaf labeled with that symbol. For example:
|
||||
.KS
|
||||
/\\ Symbol Code
|
||||
0 1 ------ ----
|
||||
/ \\ A 00
|
||||
/\\ B B 1
|
||||
/ \\ A 00
|
||||
/\\ B B 1
|
||||
0 1 C 011
|
||||
/ \\ D 010
|
||||
A /\\
|
||||
@ -559,17 +559,22 @@ Step 3 produces the following code values:
|
||||
.KS
|
||||
Symbol Length Code
|
||||
------ ------ ----
|
||||
A 3 010
|
||||
B 3 011
|
||||
C 3 100
|
||||
D 3 101
|
||||
E 3 110
|
||||
F 2 00
|
||||
A 3 010
|
||||
B 3 011
|
||||
C 3 100
|
||||
D 3 101
|
||||
E 3 110
|
||||
F 2 00
|
||||
G 4 1110
|
||||
H 4 1111
|
||||
.KE
|
||||
.fi
|
||||
|
||||
The above prefix code contains codes that are parsed from left-to-right
|
||||
(with MSB on the left). All subsequent prefix codes in this
|
||||
specification will have codes that are parsed from right-to-left
|
||||
(with MSB on the right) as they actually appear in the compressed data.
|
||||
|
||||
.ti 0
|
||||
3.3. Alphabet sizes
|
||||
|
||||
@ -708,18 +713,18 @@ earlier. A complex prefix code must have at least two non-zero
|
||||
code lengths.
|
||||
|
||||
The bit lengths of the prefix code over the code length alphabet
|
||||
are compressed with the following static prefix code (where the
|
||||
bits shown are reversed in the actual compressed stream):
|
||||
are compressed with the following static prefix code (as it appears
|
||||
in the compressed data, where the bits are parsed from right-to-left):
|
||||
|
||||
.nf
|
||||
.KS
|
||||
Symbol Code
|
||||
------ ----
|
||||
0 00
|
||||
1 1110
|
||||
2 110
|
||||
3 01
|
||||
4 10
|
||||
1 0111
|
||||
2 011
|
||||
3 10
|
||||
4 01
|
||||
5 1111
|
||||
.KE
|
||||
.fi
|
||||
@ -1184,11 +1189,11 @@ The context map is encoded as a one-dimensional array,
|
||||
CMAPL[0..(64 * NBLTYPESL - 1)] and CMAPD[0..(4 * NBLTYPESD - 1)].
|
||||
|
||||
The index of the prefix code for encoding a literal or distance
|
||||
code with context ID "cid" and block type "bltype" is
|
||||
code with context ID, CIDx, and block type, BTYPE_x, is:
|
||||
|
||||
index of literal prefix code = CMAPL[bltype * 64 + cid]
|
||||
index of literal prefix code = CMAPL[64 * BTYPE_L + CIDL]
|
||||
|
||||
index of distance prefix code = CMAPD[bltype * 4 + cid]
|
||||
index of distance prefix code = CMAPD[4 * BTYPE_D + CIDD]
|
||||
|
||||
The values of the context map are encoded with the combination
|
||||
of run length encoding for zero values and prefix coding. Let
|
||||
@ -1394,7 +1399,7 @@ The stream header has only the following one field:
|
||||
1-7 bits: WBITS, a value in the range 10 - 24, encoded with
|
||||
the following variable length code (as it appears in
|
||||
the compressed data, where the bits are parsed from
|
||||
right to left):
|
||||
right-to-left):
|
||||
|
||||
Value Bit Pattern
|
||||
----- -----------
|
||||
@ -1442,12 +1447,11 @@ the following:
|
||||
of the compressed stream filled with zeros (if the
|
||||
fill bits are not zero, then the stream should be
|
||||
rejected as invalid)
|
||||
2 bits: MNIBBLES, # of nibbles to represent the uncompressed
|
||||
length, encoded as follows: if set to 3, MNIBBLES is 0,
|
||||
otherwise MNIBBLES is the value of this field plus 4.
|
||||
If MNIBBLES is 0, the meta-block is empty, i.e. it does
|
||||
not generate any uncompressed data. In this case, the
|
||||
rest of the meta-block has the following format:
|
||||
2 bits: MNIBBLES - 4, # of nibbles to represent the uncompressed
|
||||
length. If MNIBBLES is 7, then MNIBBLES is set to 0 and
|
||||
the meta-block is empty, i.e. it does not generate any
|
||||
uncompressed data. In this case, the rest of the
|
||||
meta-block has the following format:
|
||||
|
||||
1 bit: reserved, must be zero
|
||||
|
||||
@ -1469,8 +1473,8 @@ the following:
|
||||
uncompressed data or the sliding window
|
||||
|
||||
MNIBBLES x 4 bits: MLEN - 1, where MLEN is the length
|
||||
of the meta-block uncompressed data in bytes (if the
|
||||
number of nibbles is greater than 4, and the last
|
||||
of the meta-block uncompressed data in bytes (if
|
||||
MNIBBLES is greater than 4, and the last
|
||||
nibble is all zeros, then the stream should be
|
||||
rejected as invalid)
|
||||
|
||||
@ -1484,7 +1488,7 @@ the following:
|
||||
1-11 bits: NBLTYPESL, # of literal block types, encoded with
|
||||
the following variable length code (as it appears in
|
||||
the compressed data, where the bits are parsed from
|
||||
right to left, so 0110111 has the value 12):
|
||||
right-to-left, so 0110111 has the value 12):
|
||||
|
||||
Value Bit Pattern
|
||||
----- -----------
|
||||
|
Loading…
Reference in New Issue
Block a user