RFC Errata
Found 6 records.
Status: Verified (1)
RFC 6386, "VP8 Data Format and Decoding Guide", November 2011
Source of RFC: INDEPENDENT
Errata ID: 3395
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Butter
Date Reported: 2012-10-30
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-01
Section 20.16./p.239 says:
void
vp8_dixie_tokens_process_row(struct vp8_decoder_ctx *ctx,
unsigned int partition,
unsigned int row,
unsigned int start_col,
unsigned int num_cols)
{
struct token_decoder *tokens = &ctx->tokens[partition];
short coeffs = tokens->coeffs + 25 * 16 * start_col;
It should say:
void
vp8_dixie_tokens_process_row(struct vp8_decoder_ctx *ctx,
unsigned int partition,
unsigned int row,
unsigned int start_col,
unsigned int num_cols)
{
struct token_decoder *tokens = &ctx->tokens[partition];
short *coeffs = tokens->coeffs + 25 * 16 * start_col;
Notes:
It seems "coeffs" should be a pointer to a short instead of a short.
Status: Reported (5)
RFC 6386, "VP8 Data Format and Decoding Guide", November 2011
Source of RFC: INDEPENDENT
Errata ID: 5534
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ard Oerlemans
Date Reported: 2018-10-18
Section 19.1 says:
unsigned char *c = pbi->source; unsigned int tmp; tmp = (c[2] << 16) | (c[1] << 8) | c[0]; key_frame = tmp & 0x1; version = (tmp >> 1) & 0x7; show_frame = (tmp >> 4) & 0x1; first_part_size = (tmp >> 5) & 0x7FFFF;
It should say:
unsigned char *c = pbi->source; unsigned int tmp; tmp = (c[2] << 16) | (c[1] << 8) | c[0]; key_frame = !(tmp & 0x1); version = (tmp >> 1) & 0x7; show_frame = (tmp >> 4) & 0x1; first_part_size = (tmp >> 5) & 0x7FFFF;
Notes:
In section 9.1, where the frame tag is described, the field for the key frame is defined as "A 1-bit frame type (0 for key frames, 1 for interframes)."
The code block in section 19.1 interprets the bit in the opposite way: 1 for key frames and 0 for interframes.
Errata ID: 7370
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nico Weber
Date Reported: 2023-02-25
Section 19.1 says:
The start_code is a constant 3-byte pattern having value 0x9d012a.
It should say:
The start_code is a constant 3-byte pattern having value 0x2a019d.
Notes:
The bytes in the file are 9D 01 2A, but if they are read little-endian like `tmp = (c[2] << 16) | (c[1] << 8) | c[0];` as is done for frame_tag just before, then start_code will end up as 0x2a019d in an uint32_t.
Alternatively, it could say "...having value 0x9d 0x01 0x2a".
Errata ID: 7519
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nico Weber
Date Reported: 2023-05-22
Section 9.3 says:
a. L(1), the mode of segment feature data
(segment_feature_mode), can be absolute-value mode (0) or
delta value mode (1).
It should say:
a. L(1), the mode of segment feature data
(segment_feature_mode), can be delta value mode (0) or
absolute-value mode (1).
Notes:
9.3 lists the meanings of the bits the wrong way round.
Section 19.2 has it the right way round:
"""
o segment_feature_mode indicates the feature data update mode, 0 for
delta and 1 for the absolute value
"""
That is, at the moment two sections in the spec directly contradict each other. Section 19.2 is right, section 9.3 is wrong from what I can tell.
Errata ID: 7903
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Pahl
Date Reported: 2024-04-21
Section 13.2 says:
-dct_cat1, -dct_cat2, /* cat1 = "111100",
cat2 = "111101" */
18, 20,
-dct_cat3, -dct_cat4, /* cat3 = "1111100",
cat4 = "1111101" */
-dct_cat5, -dct_cat6 /* cat4 = "1111110",
cat4 = "1111111" */
It should say:
-dct_cat1, -dct_cat2, /* cat1 = "111100",
cat2 = "111101" */
18, 20,
-dct_cat3, -dct_cat4, /* cat3 = "1111100",
cat4 = "1111101" */
-dct_cat5, -dct_cat6 /* cat5 = "1111110",
cat6 = "1111111" */
Notes:
The last two bit strings are for categories 5 and 6; only the preceding one is for category 4.
Errata ID: 7904
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Pahl
Date Reported: 2024-04-21
Section 19.2 says:
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) |
| } | |
| } | |
| } | |
| } | |
It should say:
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 | B(p) |
| if (coeff_prob_update_flag) | |
| coeff_prob | L(8) |
| } | |
| } | |
| } | |
| } | |
Notes:
The type of the flag coeff_prob_update_flag is given as L(1), which, according to the table in Section 8 on p. 25, means that this is a single literal bit that should be read with a 50/50 probability coded as 128.
But other parts of the RFC say that these flags are actually read with predetermined probabilities other than 128: Section 13.4 (“Token Probability Updates”) on p. 68 specifies these probabilities in the array coeff_update_probs, and the function decode_entropy_header in the reference implementation (file dixie.c, p. 138/139) uses them (in the array k_coeff_entropy_update_probs) to decode these flags. The current version of libwebp follows the reference implementation and uses these predetermined probabilities.
According to the table on p. 25, the type of such a flag should be specified as B(p), not as L(1).