Re: Various typo in spec

> 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.
_______________________________________________
theora-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/theora-dev