RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 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 (3)

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.

Report New Errata



Advanced Search