[theora-dev] Updated VP3 Document
Timothy B. Terriberry
tterribe at vt.edu
Fri Oct 10 12:11:22 PDT 2003
> 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
It makes more sense, certainly, but if we're already required to support
the "backwards" way, then why add the headache of supporting another
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
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.
More information about the Theora-dev