[theora-dev] Updated VP3 Document

[Timothy B. Terriberry]

> 	No real reason other than it makes more sense to render from top
> -> bottom. I won't dwell on the issue, though. I thought Dan Miller was
> proposing a header bit to specify frame orientation; what happened to that
> idea?

It makes more sense, certainly, but if we're already required to support 
the "backwards" way, then why add the headache of supporting another 
way, too?

Note that when I say we're changing the orientation that this is 
entirely internal to the library: the user will still hand in frames in 
a top-down manner, and receive decoded frames top-down.

> [should I be paranoid about the absense of item 3? :)]
Not really... there isn't a whole lot to say about this one. One thing 
that is curious is that although the same base quantization levels are 
used for luma and chroma in inter modes, the VP3 code actually generates 
two (identical) tables for them. I haven't brought it up yet to the 
other Theora people, but it may be worth specifying different base 
quantization levels for the two.

4) I forgot to mention that Theora also adds an extra 0 bit to the 
beginning of the frame header to inidcate that the packet is a data 
packet (as opposed to a header packet, which starts with a 1 bit).

5) As you may realize, the VP3 run-length codes for 
partially/(fully/not) coded super blocks are limited to a run of 4129. 
Now, one would not expect to come across more than 4129 super blocks in 
an image, but at HDTV resolutions there can be as many as 2040 super 
blocks in an image plane. If we want Theora to eventually be able to 
support a 4:4:4 pixel format, then there will be 6120 total super 
blocks, far exceeded the 4129 number.

For this reason, we made a slightly non-backward compatible change, but 
one that is unlikely to ever be run into in practice (and is still 
losslessly transcodable): After a run of length 4129 is decoded, instead 
of toggling the bit between coded or not coded, another bit value is 
read from the stream. Thus for a run of 6119 0's and one 1 one would have:

0-bit Run of 4129 0's     Another 0-bit Run of 1990 0's     Run of 1 1
0     111111 111111111111 0             111111 011110100100 0

6) Theora requires an encoded frame size that is a multiple of 16. I'm 
not entirely sure how VP3 handled non-multiple-of-16 frame sizes, but 
I've heard that people have had problems with some Quicktime files like 
this.

In Theora, although the encoded frame size is a multiple of 16, the 
header also describes a cropping rectangle so that the _displayed_ frame 
size may take on any dimensions.

<p>Btw., for the HIGHBITDUPPED() stuff... all this is doing is implementing 
normal integer division (truncation towards 0). The problem with using a 
shift to divide is that shifting truncates towards negative infinity, so 
  non-integer negative results are rounded down instead of up. The 
HIGHBITDUPPED() macro is used to correct for this.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.