discrepancies between VP8 software and the specification

[Veeraraghavan Ramamurthy]

Hi All,

I'm using libvpx codec verison v0.9.5-135-gc28b10a.There are some discrepancies between VP8 software and the specification. I was wondering if these are updated in the current version of the software.

1. Out of frame data for 4x4 mode (B_PRED) in intra prediction should be taken as 128, but the software is taking the left out of frame data as 127 and top out of frame data as 129.

2. In the same context, any neighbor unavailable MB's pixel should be considered to have a value of 128. If we take the following scenario:
While predicting MB number 43 in a CIF frame (last MB of second row in CIF frame), some prediction modes requires 8 pixels on the top. If we consider 4x4 index number 3, the top 8 pixels should be bottom 4 pixels of top MB (MB number 21) and 4 pixels of top right MB. But in this case the Top right MB is unavailable (frame boundary). According to the spec, these 4 pixels should be taken as 128, but the software takes the bottom right pixel of MB number 21 and replicates them 4 times.

-Thanks,
Veeraraghavan.R
Design Engineer
Atria Logic Inc

[Pascal Massimino]

Hi,

On Thu, May 12, 2011 at 11:53 PM, Veeraraghavan Ramamurthy <veerar...@atrialogic.com> wrote:

Hi All,

I'm using libvpx codec verison v0.9.5-135-gc28b10a.There are some discrepancies between VP8 software and the specification. I was wondering if these are updated in the current version of the software.

1. Out of frame data for 4x4 mode (B_PRED) in intra prediction should be taken as 128, but the software is taking the left out of frame data as 127 and top out of frame data as 129.

these values are following the specification in chapter 12. of the RFC document:

http://tools.ietf.org/html/draft-bankoski-vp8-bitstream-01

2. In the same context, any neighbor unavailable MB's pixel should be considered to have a value of 128. If we take the following scenario:
  While predicting MB number 43 in a CIF frame (last MB of second row in CIF frame), some prediction modes requires 8 pixels on the top. If we consider 4x4 index number 3, the top 8 pixels should be bottom 4 pixels of top MB (MB number 21) and 4 pixels of top right MB. But in this case the Top right MB is unavailable (frame boundary). According to the spec, these 4 pixels should be taken as 128, but the software takes the bottom right pixel of MB number 21 and replicates them 4 times.

In my opinion, this also seems coherent with the description from chapter 12.3..

skal

-Thanks,
Veeraraghavan.R
Design Engineer
Atria Logic Inc

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To post to this group, send email to codec...@webmproject.org.
To unsubscribe from this group, send email to codec-devel...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/codec-devel/?hl=en.

[John Koleszar]

+lou

Hi,
I think this behavior is correctly described in the english part of
the spec, but the comment in the C code immediately following it is
wrong. From 12.3 in draft-bankoski-vp8-bitstream-01:

For the right-most macroblock in each
macroblock row except the top row, the extra pixels shall use the
same value as the pixel at position (-1, 15), which is the right-most
visible pixel on the line immediately above the macroblock row. For
the top macroblock row, all the extra pixels assume a value of 127.

There's similar language (but harder to quote) describing the L/A arrays.

The only discrepancy I could find is this comment:

/* Main function. Out-of-frame pixels in A or L should be set
to 128. */
void subblock_intra_predict(...)

which is not correct. We'll fix this in the next version of the draft.;