> I have few questions on the specification.
>
> * Just to understand :
> - What is the interest of super blocks ? Is it to save place when
> recording coded block flags (7.3) ?
That is basically their only purpose, though they're also the level at
which the Hilbert traversal that makes up "coded order" is defined.
> - What is the advantage of using the coded order ? it is more often
> easier with raster order (especially to find neighbor in 7.8.1 for
> exemple). Is it to simplify the correspondence between block, macro
> block and super block ?
The theory was supposed to be something like: every block is an
immediate neighbor of the preceding block in "coded order", except
when
you reach the end of a super-block row (i.e., the traversal has a high
fractal dimension). This was actually an idea I'd had before I ever even
heard of VP3, but I rejected it for being too complex to be worth it
(although I was thinking of a traversal of the entire image, rather than
restricting it to four rows at a time... that turns out to be a lot more
complicated, though, especially once you start trying to handle
non-square sizes where the number of blocks is not a power of two).
Theory aside, coded order mostly adds a lot of bookkeeping overhead to
the code, and makes some steps of encoder optimization _really_ _hard_.
One of my biggest pet peeves with the format is that DC prediction is
not done in coded order. I doubt it really has a big influence on
compression performance: even in raster order, everything except the
last block in a row is an immediate neighbor of its predecessor, though
it's always a horizontal neighbor. It might be appreciably worse if
there's strong vertical but no horizontal correlation... though it will
perform better if there's strong horizontal but no vertical correlation.
On average I expect it's pretty close to a wash.
On2 dropped the Hilbert curve idea in later VPx formats. We could have
done so ourselves when moving from VP3 to Theora, but back in the days
when those decisions were made, trivial lossless VP3->Theora transcoding
(basically, just fixing up a few header bits) was seen as a desirable
feature, both for easy access to content and for IPR safety reasons.
> ?Each component can take on integer values from ?31 . . . 31, inclusive, at
> half-pixel resolution, i.e. ?15.5 . . . 15.5 pixels in the luma plane.
> For each sub-
> sampled axis in the chroma planes, the corresponding motion vector
> component
> is interpreted as being at quarter-pixel resolution, i.e. ?7.75 . . .
> 7.75 pixels. The
I agree the wording here is not very clear.
> I do not understand. Maybe MVECTS[bi ] should be replaced by MVECTS[bi ]
> /2 in all these expressions ?
What is meant is that, for luma blocks, the integers -31...31 should be
interpreted as -15.5...15.5, and for chroma blocks, the interpretation
depends on whether or not the corresponding dimension is subsampled in
the current pixel format: it will be either -15.5...15.5 or
-7.75...7.75. Either way, they should not be interpreted directly as
integers.
If you have suggestions for making this clearer, I am all ears.
> * Few typos :
>
> in section 7.8.1
> Variables used :
> PDIV (...) The valud -> the valu*e*
> mbi->mb*j* (...) The index ... block bj
> 7. If block bi is not along the *the* bottom
There was actually another one of these in the "Notations and
Conventions" chapter. Thank you search and replace.
>
> in table 7.47 :
> p[0] p[1] p[2] p[3] w[3] w[1] w[2] w[3] -> p[0] p[1] p[2] p[3] w[*0*]
> w[1] w[2] w[3]
These are all fixed in r17912. I'll think about the MV issue (I knew
about it before, but there were always other "more important" things
to
distract me). Proposed text suggestions are likely to make me fix it faster.