RFC Errata
Found 8 records.
Status: Verified (2)
RFC 6386, "VP8 Data Format and Decoding Guide", November 2011
Source of RFC: INDEPENDENT
Errata ID: 7903
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Pahl
Date Reported: 2024-04-21
Verifier Name: Eliot Lear
Date Verified: 2024-12-02
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: 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 (6)
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: 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).
Errata ID: 8717
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: 20kdc
Date Reported: 2026-01-23
Section 20.4 says:
if (dqf->quant_idx != q || quant_hdr->delta_update)
It should say:
/* if (dqf->quant_idx != q || quant_hdr->delta_update) */
Notes:
In the reference decoder as-provided, in the event that the decoder has previously decoded a frame with a given yac_qi (`vp8_quant_hdr.q_index` in the code) and non-zero deltas, and in the next frame, `yac_qi` remains the same, but all deltas are not provided or are 0, then `quant_idx` will equal q and `delta_update` will be 0, so the table update will not be applied, leading to the previously decoded deltas being used.
libvpx v1.15.2 `vp8/decoder/decodeframe.c` lines 1083 and following (and the equivalent location in the first commit of libvpx) handles a similar optimization; however, the delta values are compared to their previous values in the 'get_delta_q' function.
I believe the error in the reference decoder stems from a misoptimization attempting to 'lay the groundwork' for the same prevention of rebuilding of optimized dequantization tables.
These tables do not exist in the reference decoder, so the code being guarded here is relatively trivial.
I have tested this change on a personal stripped-down fork of the libvpx 'dixie' branch (the closest 'relative' to the reference decoder that can easily be compiled) in order to confirm it does not immediately break decoding, but my test vector library is not particularly extensive, and the bug is one that would likely have to be triggered by chance in a normal encoding.
Still, I believe the evidence in libvpx points to this errata being correct.
libvpx's interpretation appears to better align with the specification (section 9.6. Dequantization Indices), but not with the reference code; as it is the major shipping implementation, and as the behaviour doesn't really make sense, I'm inclined to believe libvpx is correct.
The `get_delta_q` function's use and behaviour is present in the optimized decoder since the 'Initial WebM release' commit, which indicates that the 'non-sticky' behaviour appears to have superseded the reference decoder.
Please note that only removing/commenting this line creates unused code which would not be correctable without a deeper series of changes.
The effects of disabling this optimization in this decoder appear to be trivial (simple once-per-frame logic), but in the 'full' decoder the process is a little more expensive for what appears to be dequantizer optimization reasons.
Errata ID: 7950
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Felix Pahl
Date Reported: 2024-05-22
Section 12.3 says:
B[2][0] = B[3][2] = svg2p(E + 1); /* ( 3/2, -1) */
It should say:
B[2][0] = B[3][2] = avg2p(E + 1); /* ( 3/2, -1) */
Notes:
This is a typo; the call to avg2p computes the desired value, and svg2p is not defined.