Imported Upstream version 1.1.1upstream/1.1.1upstream

1 files changed, 8171 insertions, 0 deletions

diff --git a/doc/spec/spec.tex b/doc/spec/spec.tex
new file mode 100644
index 0000000..b29d4ef
--- /dev/null
+++ b/doc/spec/spec.tex
@@ -0,0 +1,8171 @@
+\documentclass[9pt,letterpaper]{book}
+
+\usepackage{latexsym}
+\usepackage{amssymb}
+\usepackage{amsmath}
+\usepackage{bm}
+\usepackage{textcomp}
+\usepackage{graphicx}
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{longtable}
+\usepackage{ltablex}
+\usepackage{wrapfig}
+\usepackage[pdfpagemode=None,pdfstartview=FitH,pdfview=FitH,colorlinks=true]%
+ {hyperref}
+
+\newtheorem{theorem}{Theorem}[section]
+\newcommand{\idx}[1]{{\ensuremath{\mathit{#1}}}}
+\newcommand{\qti}{\idx{qti}}
+\newcommand{\qtj}{\idx{qtj}}
+\newcommand{\pli}{\idx{pli}}
+\newcommand{\plj}{\idx{plj}}
+\newcommand{\qi}{\idx{qi}}
+\newcommand{\ci}{\idx{ci}}
+\newcommand{\bmi}{\idx{bmi}}
+\newcommand{\bmj}{\idx{bmj}}
+\newcommand{\qri}{\idx{qri}}
+\newcommand{\qrj}{\idx{qrj}}
+\newcommand{\hti}{\idx{hti}}
+\newcommand{\sbi}{\idx{sbi}}
+\newcommand{\bi}{\idx{bi}}
+\newcommand{\bj}{\idx{bj}}
+\newcommand{\mbi}{\idx{mbi}}
+\newcommand{\mbj}{\idx{mbj}}
+\newcommand{\mi}{\idx{mi}}
+\newcommand{\cbi}{\idx{cbi}}
+\newcommand{\qii}{\idx{qii}}
+\newcommand{\ti}{\idx{ti}}
+\newcommand{\tj}{\idx{tj}}
+\newcommand{\rfi}{\idx{rfi}}
+\newcommand{\zzi}{\idx{zzi}}
+\newcommand{\ri}{\idx{ri}}
+%This somewhat odd construct ensures that \bitvar{\qi}, etc., will set the
+% qi in bold face, even though it is in a \mathit font, yet \bitvar{VAR} will
+% set VAR in a bold, roman font.
+\newcommand{\bitvar}[1]{\ensuremath{\mathbf{\bm{#1}}}}
+\newcommand{\locvar}[1]{\ensuremath{\mathrm{#1}}}
+\newcommand{\term}[1]{{\em #1}}
+\newcommand{\bin}[1]{\ensuremath{\mathtt{b#1}}}
+\newcommand{\hex}[1]{\ensuremath{\mathtt{0x#1}}}
+\newcommand{\ilog}{\ensuremath{\mathop{\mathrm{ilog}}\nolimits}}
+\newcommand{\round}{\ensuremath{\mathop{\mathrm{round}}\nolimits}}
+\newcommand{\sign}{\ensuremath{\mathop{\mathrm{sign}}\nolimits}}
+\newcommand{\lflim}{\ensuremath{\mathop{\mathrm{lflim}}\nolimits}}
+
+%Section-based table, figure, and equation numbering.
+\numberwithin{equation}{chapter}
+\numberwithin{figure}{chapter}
+\numberwithin{table}{chapter}
+
+\keepXColumns
+
+\pagestyle{headings}
+\bibliographystyle{alpha}
+
+\title{Theora Specification}
+\author{Xiph.org Foundation}
+\date{\today}
+
+
+\begin{document}
+
+\frontmatter
+
+\begin{titlepage}
+\maketitle
+\end{titlepage}
+\thispagestyle{empty}
+\cleardoublepage
+
+\pagenumbering{roman}
+
+\thispagestyle{plain}
+\tableofcontents
+\cleardoublepage
+
+\thispagestyle{plain}
+\listoffigures
+\cleardoublepage
+
+\thispagestyle{plain}
+\listoftables
+\cleardoublepage
+
+\thispagestyle{plain}
+\markboth{{\sc Notation and Conventions}}{{\sc Notation and Conventions}}
+\chapter*{Notation and Conventions}
+
+All parameters either passed in or out of a decoding procedure are given in
+ \bitvar{bold\ face}.
+
+The prefix \bin{} indicates that the following value is to be interpreted as a
+ binary number (base 2).
+\begin{verse}
+{\bf Example:} The value \bin{1110100} is equal to the decimal value 116.
+\end{verse}
+
+The prefix \hex{} indicates the the following value is to be interpreted as a
+ hexadecimal number (base 16).
+\begin{verse}
+{\bf Example:} The value \hex{74} is equal to the decimal value 116.
+\end{verse}
+
+All arithmetic defined by this specification is exact.
+However, any real numbers that do arise will always be converted back to
+ integers again in short order.
+The entire specification can be implemented using only normal integer
+ operations.
+All operations are to be implemented with sufficiently large integers so that
+ overflow cannot occur.
+Where the result of a computation is to be truncated to a fixed-sized binary
+ representation, this will be explicitly noted.
+The size given for all variables is the maximum number of bits needed to store
+ any value in that variable.
+Intermediate computations involving that variable may require more bits.
+
+The following operators are defined:
+
+\begin{description}
+\item[$|a|$]
+The absolute value of a number $a$.
+\begin{align*}
+|a| & = \left\{\begin{array}{ll}
+-a, & a < 0 \\
+a, & a \ge 0
+\end{array}\right.
+\end{align*}
+
+\item[$a*b$]
+Multiplication of a number $a$ by a number $b$.
+\item[$\frac{a}{b}$]
+Exact division of a number $a$ by a number $b$, producing a potentially
+ non-integer result.
+
+\item[$\left\lfloor a\right\rfloor$] 
+The largest integer less than or equal to a real number $a$.
+
+\item[$\left\lceil a\right\rceil$]
+The smallest integer greater than or equal to a real number $a$.
+
+\item[$a//b$]
+Integer division of $a$ by $b$.
+\begin{align*}
+a//b & = \left\{\begin{array}{ll}
+\left\lceil\frac{a}{b}\right\rceil, & a < 0 \\
+\left\lfloor\frac{a}{b}\right\rfloor, & a \ge 0
+\end{array}\right.
+\end{align*}
+
+\item[$a\%b$]
+The remainder from the integer division of $a$ by $b$.
+\begin{align*}
+a\%b & = a-|b|*\left\lfloor\frac{a}{|b|}\right\rfloor
+\end{align*}
+Note that with this definition, the result is always non-negative and less than
+ $|b|$.
+
+\item[$a<<b$]
+The value obtained by left-shifting the two's complement integer $a$ by $b$
+ bits.
+For purposes of this specification, overflow is ignored, and so this is
+ equivalent to integer multiplication of $a$ by $2^b$.
+
+\item[$a>>b$]
+The value obtained by right-shifting the two's complement integer $a$ by $b$
+ bits, filling in the leftmost bits of the new value with $0$ if $a$ is
+ non-negative and $1$ if $a$ is negative.
+This is {\em not} equivalent to integer division of $a$ by $2^b$.
+Instead,
+\begin{align*}
+a>>b & = \left\lfloor\frac{a}{2^b}\right\rfloor.
+\end{align*}
+
+\item[$\round(a)$]
+Rounds a number $a$ to the nearest integer, with ties rounded away from $0$.
+\begin{align*}
+\round(a) = \left\{\begin{array}{ll}
+\lceil a-\frac{1}{2}\rceil   & a \le 0 \\
+\lfloor a+\frac{1}{2}\rfloor & a > 0
+\end{array}\right.
+\end{align*}
+
+\item[$\sign(a)$]
+Returns the sign of a given number.
+\begin{align*}
+\sign(a) = \left\{\begin{array}{ll}
+-1 & a < 0 \\
+0  & a = 0 \\
+1  & a > 0
+\end{array}\right.
+\end{align*}
+
+\item[$\ilog(a)$]
+The minimum number of bits required to store a positive integer $a$ in
+ two's complement notation, or $0$ for a non-positive integer $a$.
+\begin{align*}
+\ilog(a) = \left\{\begin{array}{ll}
+0, & a \le 0 \\
+\left\lfloor\log_2{a}\right\rfloor+1, & a > 0
+\end{array}\right.
+\end{align*}
+
+\begin{verse}
+{\bf Examples:}
+\begin{itemize}
+\item $\ilog(-1)=0$
+\item $\ilog(0)=0$
+\item $\ilog(1)=1$
+\item $\ilog(2)=2$
+\item $\ilog(3)=2$
+\item $\ilog(4)=3$
+\item $\ilog(7)=3$
+\end{itemize}
+\end{verse}
+
+\item[$\min(a,b)$]
+The minimum of two numbers $a$ and $b$.
+
+\item[$\max(a,b)$]
+The maximum of two numbers $a$ and $b$.
+
+\end{description}
+\cleardoublepage
+
+
+\thispagestyle{plain}
+\markboth{{\sc Key words}}{{\sc Key words}}
+\chapter*{Key words}
+
+%We can't rewrite this, because this is text required by RFC 2119, so we use
+% some emergency stretching to get it typeset properly.
+\setlength{\emergencystretch}{2em}
+The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'',
+ ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' in this
+ document are to be intrepreted as described in RFC 2119 \cite{rfc2119}.\par
+\setlength{\emergencystretch}{0em}
+
+Where such assertions are placed on the contents of a Theora bitstream itself,
+ implementations should be prepared to encounter bitstreams that do not follow
+ these requirements.
+An application's behavior in the presecence of such non-conforming bitstreams
+ is not defined by this specification, but any reasonable method of handling 
+ them MAY be used.
+By way of example, applications MAY discard the current frame, retain the
+ current output thus far, or attempt to continue on by assuming some default
+ values for the erroneous bits.
+When such an error occurs in the bitstream headers, an application MAY refuse
+ to decode the entire stream.
+An application SHOULD NOT allow such non-conformant bitstreams to overflow
+ buffers and potentially execute arbitrary code, as this represents a serious
+ security risk.
+
+An application MUST, however, ensure any bits marked as reserved have the value
+ zero, and refuse to decode the stream if they do not.
+These are used as place holders for future bitstream features with which the
+ current bitstream is forward-compatible.
+Such features may not increment the bitstream version number, and can only be
+ recognized by checking the value of these reserved bits.
+
+\cleardoublepage
+
+
+
+\mainmatter
+
+\pagenumbering{arabic}
+\setcounter{page}{1}
+
+\chapter{Introduction}
+
+Theora is a general purpose, lossy video codec.
+It is based on the VP3 video codec produced by On2 Technologies
+ (\url{http://www.on2.com/}).
+On2 donated the VP3.1 source code to the Xiph.org Foundation and released it
+ under a BSD-like license.
+On2 also made an irrevocable, royalty-free license grant for any patent claims
+ it might have over the software and any derivatives.
+No formal specification exists for the VP3 format beyond this source code,
+ however Mike Melanson maintains a detailed description \cite{Mel04}.
+Portions of this specification were adopted from that text with permission.
+
+\section{VP3 and Theora}
+
+Theora contains a superset of the features that were available in the original
+ VP3 codec.
+Content encoded with VP3.1 can be losslessly transcoded into the Theora format.
+Theora content cannot, in general, be losslessly transcoded into the VP3
+ format.
+If a feature is not available in the original VP3 format, this is mentioned
+ when that feature is defined.
+A complete list of these features appears in Appendix~\ref{app:vp3-compat}.
+%TODO: VP3 - theora comparison in appendix
+
+\section{Video Formats}
+
+Theora currently supports progressive video data of arbitrary dimensions at a
+ constant frame rate in one of several $Y'C_bC_r$ color spaces.
+The precise definition the supported color spaces appears in
+ Section~\ref{sec:colorspaces}.
+Three different chroma subsampling formats are supported: 4:2:0, 4:2:2,
+ and 4:4:4.
+The precise details of each of these formats and their sampling locations are
+ described in Section~\ref{sec:pixfmts}.
+
+The Theora format does not support interlaced material, variable frame rates,
+ bit-depths larger than 8 bits per component, nor alternate color spaces such
+ as RGB or arbitrary multi-channel spaces.
+Black and white content can be efficiently encoded, however, because the
+ uniform chroma planes compress well.
+Support for interlaced material is planned for a future version.
+\begin{verse}
+{\bf Note:} Infrequently changing frame rates---as when film and video
+ sequences are cut together---can be supported in the Ogg container format by
+ chaining several Theora streams together.
+\end{verse}
+Support for increased bit depths or additional color spaces is not planned.
+
+\section{Classification}
+
+Theora is a block-based lossy transform codec that utilizes an
+ $8\times 8$ Type-II Discrete Cosine Transform and block-based motion
+ compensation.
+This places it in the same class of codecs as MPEG-1, -2, -4, and H.263.
+The details of how individual blocks are organized and how DCT coefficients are
+ stored in the bitstream differ substantially from these codecs, however.
+Theora supports only intra frames (I frames in MPEG) and inter frames (P frames
+ in MPEG).
+There is no equivalent to the bi-predictive frames (B frames) found in MPEG
+ codecs.
+
+\section{Assumptions}
+
+The Theora codec design assumes a complex, psychovisually-aware encoder and a
+ simple, low-complexity decoder.
+%TODO: Talk more about implementation complexity.
+
+Theora provides none of its own framing, synchronization, or protection against
+ transmission errors. 
+An encoder is solely a method of accepting input video frames and
+ compressing these frames into raw, unformatted `packets'.
+The decoder then accepts these raw packets in sequence, decodes them, and
+ synthesizes a fascimile of the original video frames.
+Theora is a free-form variable bit rate (VBR) codec, and packets have no
+ minimum size, maximum size, or fixed/expected size.
+
+Theora packets are thus intended to be used with a transport mechanism that
+ provides free-form framing, synchronization, positioning, and error correction
+ in accordance with these design assumptions, such as Ogg (for file transport)
+ or RTP (for network multicast).
+For the purposes of a few examples in this document, we will assume that Theora
+ is embedded in an Ogg stream specifically, although this is by no means a
+ requirement or fundamental assumption in the Theora design.
+
+The specification for embedding Theora into an Ogg transport stream is given in
+ Appendix~\ref{app:oggencapsulation}.
+
+\section{Codec Setup and Probability Model}
+
+Theora's heritage is the proprietary commerical codec VP3, and it retains a
+ fair amount of inflexibility when compared to Vorbis \cite{vorbis}, the first
+ Xiph.org codec, which began as a research codec.
+However, to provide additional scope for encoder improvement, Theora adopts
+ some of the configurable aspects of decoder setup that are present in Vorbis.
+This configuration data is not available in VP3, which uses hardcoded values
+ instead.
+
+Theora makes the same controversial design decision that Vorbis made to include
+ the entire probability model for the DCT coefficients and all the quantization
+ parameters in the bitstream headers.
+This is often several hundred fields.
+It is therefore impossible to decode any frame in the stream without
+ having previously fetched the codec info and codec setup headers.
+
+\begin{verse}
+{\bf Note:} Theora {\em can} initiate decode at an arbitrary intra-frame packet
+ within a bitstream so long as the codec has been initialized with the setup
+ headers.
+\end{verse}
+
+Thus, Theora headers are both required for decode to begin and relatively large
+ as bitstream headers go.
+The header size is unbounded, although as a rule-of-thumb less than 16kB is
+ recommended, and Xiph.org's reference encoder follows this suggestion.
+%TODO: Is 8kB enough? My setup header is 7.4kB, that doesn't leave much room
+% for comments.
+%RG: the lesson from vorbis is that as small as possible is really
+% important in some applications. Practically, what's acceptable
+% depends a great deal on the target bitrate. I'd leave 16 kB in the
+% spec for now. fwiw more than 1k of comments is quite unusual.
+
+Our own design work indicates that the primary liability of the required header
+ is in mindshare; it is an unusual design and thus causes some amount of
+ complaint among engineers as this runs against current design trends and
+ points out limitations in some existing software/interface designs.
+However, we find that it does not fundamentally limit Theora's suitable
+ application space.
+
+%silvia: renamed
+%\subsection{Format Specification}
+\section{Format Conformance}
+
+The Theora format is well-defined by its decode specification; any encoder that
+ produces packets that are correctly decoded by an implementation following
+ this specification may be considered a proper Theora encoder.
+A decoder must faithfully and completely implement the specification defined
+ herein %, except where noted,
+ to be considered a conformant Theora decoder.
+A decoder need not be implemented strictly as described, but the
+ actual decoder process MUST be {\em entirely mathematically equivalent}
+ to the described process.
+Where appropriate, a non-normative description of encoder processes is
+ included.
+These sections will be marked as such, and a proper Theora encoder is not
+ bound to follow them.
+
+%TODO: \subsection{Hardware Profile}
+
+
+\chapter{Coded Video Structure}
+
+Theora's encoding and decoding process is based on $8\times 8$ blocks of
+ pixels.
+This sections describes how a video frame is laid out, divided into
+ blocks, and how those blocks are organized.
+
+\section{Frame Layout}
+
+A video frame in Theora is a two-dimensional array of pixels.
+Theora, like VP3, uses a right-handed coordinate system, with the origin in the
+ lower-left corner of the frame.
+This is contrary to many video formats which use a left-handed coordinate
+ system with the origin in the upper-left corner of the frame.
+%INT: This means that for interlaced material, the definition of `even fields'
+%INT:  and `odd fields' may be reversed between Theora and other video codecs.
+%INT: This document will always refer to them as `top fields' and `bottom
+%INT:  fields'.
+
+Theora divides the pixel array up into three separate \term{color planes}, one
+ for each of the $Y'$, $C_b$, and $C_r$ components of the pixel.
+The $Y'$ plane is also called the \term{luma plane}, and the $C_b$ and $C_r$
+ planes are also called the \term{chroma planes}.
+Each plane is assigned a numerical value, as shown in
+ Table~\ref{tab:color-planes}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Index & Color Plane \\\midrule
+$0$   & $Y'$        \\
+$1$   & $C_b$       \\
+$2$   & $C_r$       \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Color Plane Indices}
+\label{tab:color-planes}
+\end{table}
+
+In some pixel formats, the chroma planes are subsampled by a factor of two
+ in one or both directions.
+This means that the width or height of the chroma planes may be half that of
+ the total frame width and height.
+The luma plane is never subsampled.
+
+\section{Picture Region}
+
+An encoded video frame in Theora is required to have a width and height that
+ are multiples of sixteen, making an integral number of blocks even when the
+ chroma planes are subsampled.
+However, inside a frame a smaller \term{picture region} may be defined
+ to present material whose dimensions are not a multiple of sixteen pixels, as
+ shown in Figure~\ref{fig:pic-frame}.
+The picture region can be offset from the lower-left corner of the frame by up
+ to 255 pixels in each direction, and may have an arbitrary width and height,
+ provided that it is contained entirely within the coded frame.
+It is this picture region that contains the actual video data.
+The portions of the frame which lie outside the picture region may contain
+ arbitrary image data, so the frame must be cropped to the picture region
+ before display.
+The picture region plays no other role in the decode process, which operates on
+ the entire video frame.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pic-frame}
+\end{center}
+\caption{Location of frame and picture regions}
+\label{fig:pic-frame}
+\end{figure}
+
+\section{Blocks and Super Blocks}
+\label{sec:blocks-and-sbs}
+
+Each color plane is subdivided into \term{blocks} of $8\times 8$ pixels.
+Blocks are grouped into $4\times 4$ arrays called \term{super blocks} as
+ shown in Figure~\ref{fig:superblock}.
+Each color plane has its own set of blocks and super blocks.
+If the chroma planes are subsampled, they are still divided into $8\times 8$
+ blocks of pixels; there are just fewer blocks than in the luma plane.
+The boundaries of blocks and super blocks in the luma plane do not necessarily
+ coincide with those of the chroma planes, if the chroma planes have been
+ subsampled.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{superblock}
+\end{center}
+\caption{Subdivision of a frame into blocks and super blocks}
+\label{fig:superblock}
+\end{figure}
+
+Blocks are accessed in two different orders in the various decoder processes.
+The first is \term{raster order}, illustrated in Figure~\ref{fig:raster-block}.
+This accesses each block in row-major order, starting in the lower left of the
+ frame and continuing along the bottom row of the entire frame, followed by the
+ next row up, starting on the left edge of the frame, etc.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{raster-block}
+\end{center}
+\caption{Raster ordering of $n\times m$ blocks}
+\label{fig:raster-block}
+\end{figure}
+
+The second is \term{coded order}.
+In coded order, blocks are accessed by super block.
+Within each frame, super blocks are traversed in raster order,
+ similar to raster order for blocks.
+Within each super block, however, blocks are accessed in a Hilbert curve
+ pattern, illustrated in Figure~\ref{fig:hilbert-block}.
+If a color plane does not contain a complete super block on the top or right
+ sides, the same ordering is still used, simply with any blocks outside the
+ frame boundary ommitted.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{hilbert-block}
+\end{center}
+\caption{Hilbert curve ordering of blocks within a super block}
+\label{fig:hilbert-block}
+\end{figure}
+
+To illustrate this ordering, consider a frame that is 240 pixels wide and
+ 48 pixels high.
+Each row of the luma plane has 30 blocks and 8 super blocks, and there are 6
+ rows of blocks and two rows of super blocks.
+
+%When accessed in raster order, each block in the luma plane is assigned the
+% following indices:
+
+%\vspace{\baselineskip}
+%\begin{center}
+%\begin{tabular}{|ccccccc|}\hline
+%150 & 151 & 152 & 153 & $\ldots$ & 178 & 179 \\
+%120 & 121 & 122 & 123 & $\ldots$ & 148 & 149 \\\hline
+% 90 &  91 &  92 &  93 & $\ldots$ & 118 & 119 \\
+% 60 &  61 &  62 &  63 & $\ldots$ &  88 &  89 \\
+% 30 &  31 &  32 &  33 & $\ldots$ &  58 &  59 \\
+%  0 &   1 &   2 &   3 & $\ldots$ &  28 &  29 \\\hline
+%\end{tabular}
+%\end{center}
+%\vspace{\baselineskip}
+
+When accessed in coded order, each block in the luma plane is assigned the
+ following indices:
+
+\vspace{\baselineskip}
+\begin{center}
+\begin{tabular}{|cccc|c|cc|}\hline
+123 & 122 & 125 & 124 & $\ldots$ & 179 & 178 \\
+120 & 121 & 126 & 127 & $\ldots$ & 176 & 177 \\\hline
+  5 &   6 &   9 &  10 & $\ldots$ & 117 & 118 \\
+  4 &   7 &   8 &  11 & $\ldots$ & 116 & 119 \\
+  3 &   2 &  13 &  12 & $\ldots$ & 115 & 114 \\
+  0 &   1 &  14 &  15 & $\ldots$ & 112 & 113 \\\hline
+\end{tabular}
+\end{center}
+\vspace{\baselineskip}
+
+Here the index values specify the order in which the blocks would be accessed.
+The indices of the blocks are numbered continuously from one color plane to the
+ next.
+They do not reset to zero at the start of each plane.
+Instead, the numbering increases continuously from the $Y'$ plane to the $C_b$
+ plane to the $C_r$ plane.
+The implication is that the blocks from all planes are treated as a unit during
+ the various processing steps.
+
+Although blocks are sometimes accessed in raster order, in this document the
+ index associated with a block is {\em always} its index in coded order.
+
+\section{Macro Blocks}
+\label{sec:mbs}
+
+A macro block contains a $2\times 2$ array of blocks in the luma plane
+ {\em and} the co-located blocks in the chroma planes, as shown in
+ Figure~\ref{fig:macroblock}.
+Thus macro blocks can represent anywhere from six to twelve blocks, depending
+ on how the chroma planes are subsampled.
+This is in contrast to super blocks, which only contain blocks from a single
+ color plane.
+% the whole super vs. macro blocks thing is a little confusing, and it can be
+% hard to remember which is what initially. A figure would/will help here,
+% but I tried to add some text emphasizing the difference in terms of
+% functionality.
+%TBT: At this point we haven't described any functionality yet.
+%TBT: As far as the reader knows, the only purpose of the blocks, macro blocks
+%TBT:  and super blocks is for data organization---and for blocks and super
+%TBT:  blocks, this is essentially true.
+%TBT: So lets restrict the differences we emphasize to those of data
+%TBT:  organization, which the sentence I just added above does.
+Macro blocks contain information about coding mode and motion vectors for the
+ corresponding blocks in all color planes.
+
+\begin{figure}[htbp]
+ \begin{center}
+ \includegraphics{macroblock}
+ \end{center}
+ \caption{Subdivision of a frame into macro blocks}
+ \label{fig:macroblock}
+\end{figure}
+
+Macro blocks are also accessed in a \term{coded order}.
+This coded order proceeds by examining each super block in the luma plane in
+ raster order, and traversing the four macro blocks inside using a smaller
+ Hilbert curve, as shown in Figure~\ref{fig:hilbert-mb}.
+%r: I rearranged the wording to make a more formal idiom here
+If the luma plane does not contain a complete super block on the top or right
+ sides, the same ordering is still used, with any macro blocks outside
+ the frame boundary simply omitted.
+Because the frame size is constrained to be a multiple of 16, there are never
+ any partial macro blocks.
+Unlike blocks, macro blocks need never be accessed in a pure raster order.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{hilbert-mb}
+\end{center}
+\caption{Hilbert curve ordering of macro blocks within a super block}
+\label{fig:hilbert-mb}
+\end{figure}
+
+Using the same frame size as the example above, there are 15 macro blocks in
+ each row and 3 rows of macro blocks.
+The macro blocks are assigned the following indices:
+
+\vspace{\baselineskip}
+\begin{center}
+\begin{tabular}{|cc|cc|c|cc|c|}\hline
+30 & 31 & 32 & 33 & $\cdots$ & 42 & 43 & 44 \\\hline
+ 1 &  2 &  5 &  6 & $\cdots$ & 25 & 26 & 29 \\
+ 0 &  3 &  4 &  7 & $\cdots$ & 24 & 27 & 28 \\\hline
+\end{tabular}
+\end{center}
+\vspace{\baselineskip}
+
+\section{Coding Modes and Prediction}
+
+Each block is coded using one of a small, fixed set of \term{coding modes} that
+ define how the block is predicted from previous frames.
+A block is predicted using one of two \term{reference frames}, selected
+ according to the coding mode.
+A reference frame is the fully decoded version of a previous frame in the
+ stream.
+The first available reference frame is the previous intra frame, called the
+ \term{golden frame}.
+The second available reference frame is the previous frame, whether it was an
+ intra frame or an inter frame.
+If the previous frame was an intra frame, then both reference frames are the
+ same.
+See Figure~\ref{fig:reference-frames} for an illustration of the reference
+ frames used for an intra frame that does not follow an intra frame.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{reference-frames}
+\end{center}
+\caption{Example of reference frames for an inter frame}
+\label{fig:reference-frames}
+\end{figure}
+
+Two coding modes in particular are worth mentioning here.
+The INTRA mode is used for blocks that are not predicted from either reference
+ frame.
+This is the only coding mode allowed in intra frames.
+The INTER\_NOMV coding mode uses the co-located contents of the block in the
+ previous frame as the predictor.
+This is the default coding mode.
+
+\section{DCT Coefficients}
+\label{sec:dct-coeffs}
+
+A \term{residual} is added to the predicted contents of a block to form the
+ final reconstruction.
+The residual is stored as a set of quantized coefficients from an integer
+ approximation of a two-dimensional Type II Discrete Cosine Transform.
+The DCT takes an $8\times 8$ array of pixel values as input and returns an
+ $8\times 8$ array of coefficient values.
+The \term{natural ordering} of these coefficients is defined to be row-major
+ order, from lowest to highest frequency.
+They are also often indexed in \term{zig-zag order}, as shown in
+ Figure~\ref{tab:zig-zag}.
+
+\begin{figure}[htbp]
+\begin{center}
+\begin{tabular}[c]{rr|c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c}
+ &\multicolumn{1}{r}{} & && &&&&&$c$&&& && &&  \\
+ &\multicolumn{1}{r}{} &0&&1&&2&&3&&4&&5&&6&&7 \\\cline{3-17}
+ &0 &  0 &$\rightarrow$&  1 &&  5 &$\rightarrow$&  6 && 14 &$\rightarrow$& 15 && 27 &$\rightarrow$& 28            \\[-0.5\defaultaddspace]
+ &  &    &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&                  \\
+ &1 &  2 &             &  4 &&  7 &             & 13 && 16 &             & 26 && 29 &             & 42            \\[-0.5\defaultaddspace]
+ &  &$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &2 &  3 &             &  8 && 12 &             & 17 && 25 &             & 30 && 41 &             & 43            \\[-0.5\defaultaddspace]
+ &  &    &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&                  \\
+ &3 &  9 &             & 11 && 18 &             & 24 && 31 &             & 40 && 44 &             & 53            \\[-0.5\defaultaddspace]
+$r$&&$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &4 & 10 &             & 19 && 23 &             & 32 && 39 &             & 45 && 52 &             & 54            \\[-0.5\defaultaddspace]
+ &  &    &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&                  \\
+ &5 & 20 &             & 22 && 33 &             & 38 && 46 &             & 51 && 55 &             & 60            \\[-0.5\defaultaddspace]
+ &  &$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &6 & 21 &             & 34 && 37 &             & 47 && 50 &             & 56 && 59 &             & 61            \\[-0.5\defaultaddspace]
+ &  &    &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&                  \\
+ &7 & 35 &$\rightarrow$& 36 && 48 &$\rightarrow$& 49 && 57 &$\rightarrow$& 58 && 62 &$\rightarrow$& 63
+\end{tabular}
+\end{center}
+\caption{Zig-zag order}
+\label{tab:zig-zag}
+\end{figure}
+
+\begin{verse}
+{\bf Note:} the row and column indices refer to {\em frequency number} and not
+ pixel locations.
+The frequency numbers are defined independently of the memory organization of
+ the pixels.
+They have been written from top to bottom here to follow conventional notation,
+ despite the right-handed coordinate system Theora uses for pixel locations.
+%RG: I'd rather we were internally consistent and put dc at the lower left.
+Many implementations of the DCT operate `in-place'.
+That is, they return DCT coefficients in the same memory buffer that the
+ initial pixel values were stored in.
+Due to the right-handed coordinate system used for pixel locations in Theora,
+ one must note carefully how both pixel values and DCT coefficients are
+ organized in memory in such a system.
+\end{verse}
+
+DCT coefficient $(0,0)$ is called the \term{DC coefficient}.
+All the other coefficients are called \term{AC coefficients}.
+
+
+\chapter{Decoding Overview}
+
+This section provides a high level description of the Theora codec's
+ construction.
+A bit-by-bit specification appears beginning in Section~\ref{sec:bitpacking}.
+The later sections assume a high-level understanding of the Theora decode
+ process, which is provided below.
+
+\section{Decoder Configuration}
+
+Decoder setup consists of configuration of the quantization matrices and the
+ Huffman codebooks for the DCT coefficients, and a table of limit values for
+ the deblocking filter.
+The remainder of the decoding pipeline is not configurable.
+
+\subsection{Global Configuration}
+
+The global codec configuration consists of a few video related fields, such as
+ frame rate, frame size, picture size and offset, aspect ratio, color space,
+ pixel format, and a version number.
+The version number is divided into a major version, a minor version, amd a
+ minor revision number.
+%r: afaik the released vp3 codec called itself 3.1 and is compatible w/ theora
+%r: even though we received the in-progress 3.2 codebase
+For the format defined in this specification, these are `3', `2', and
+ `1', respectively, in reference to Theora's origin as a successor to 
+ the VP3.1 format.
+
+\subsection{Quantization Matrices}
+
+Theora allows up to 384 different quantization matrices to be defined, one for
+ each \term{quantization type}, \term{color plane} ($Y'$, $C_b$, or $C_r$), and
+ \term{quantization index}, \qi, which ranges from zero to 63, inclusive.
+There are currently two quantization types defined, which depend on the coding
+ mode of the block being dequantized, as shown in Table~\ref{tab:quant-types}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Quantization Type & Usage                     \\\midrule
+$0$               & INTRA-mode blocks         \\
+$1$               & Blocks in any other mode. \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Quantization Type Indices}
+\label{tab:quant-types}
+\end{table}
+
+%r: I think 'nominally' is more specific than 'generally' here
+The quantization index, on the other hand, nominally represents a progressive
+ range of quality levels, from low quality near zero to high quality near 63.
+However, the interpretation is arbitrary, and it is possible, for example, to
+ partition the scale into two completely separate ranges with 32 levels each
+ that are meant to represent different classes of source material, or any
+ other arrangement that suits the encoder's requirements.
+
+Each quantization matrix is an $8\times 8$ matrix of 16-bit values, which is
+ used to quantize the output of the $8\times 8$ DCT\@.
+Quantization matrices are specified using three components: a
+ \term{base matrix} and two \term{scale values}.
+The first scale value is the \term{DC scale}, which is applied to the DC
+ component of the base matrix.
+The second scale value is the \term{AC scale}, which is applied to all the
+ other components of the base matrix.
+There are 64 DC scale values and 64 AC scale values, one for each \qi\ value.
+
+There are 64 elements in each base matrix, one for each DCT coefficient.
+They are stored in natural order (cf. Section~\ref{sec:dct-coeffs}).
+There is a separate set of base matrices for each quantization type and each
+ color plane, with up to 64 possible base matrices in each set, one for each
+ \qi\ value.
+%r: we will mention that the given matricies must bound the \qi range
+%r: in the detailed section. it's not important at this level.
+Typically the bitstream contains matrices for only a sparse subset of the
+ possible \qi\ values.
+The base matrices for the remainder of the \qi\ values are computed using
+ linear interpolation.
+This configuration allows the encoder to adjust the quantization matrices to
+ approximate the complex, non-linear response of the human visual system to
+ different quantization errors.
+
+Finally, because the in-loop deblocking filter strength depends on the strength
+ of the quantization matrices defined in this header, a table of 64 \term{loop
+ filter limit values} is defined, one for each \qi\ value.
+
+The precise specification of how all of this information is decoded appears in
+ Section~\ref{sub:loop-filter-limits} and Section~\ref{sub:quant-params}.
+
+\subsection{Huffman Codebooks}
+
+Theora uses 80 configurable binary Huffman codes to represent the 32 tokens
+ used to encode DCT coefficients.
+Each of the 32 token values has a different semantic meaning and is used to
+ represent single coefficient values, zero runs, combinations of the two, and
+ \term{End-Of-Block markers}.
+
+The 80 codes are divided up into five groups of 16, with each group
+ corresponding to a set of DCT coefficient indices.
+The first group corresponds to the DC coefficient, while the remaining four
+ groups correspond to different subsets of the AC coefficients.
+Within each frame, two pairs of 4-bit codebook indices are stored.
+The first pair selects which codebooks to use from the DC coefficient group for
+ the $Y'$ coefficients and the $C_b$ and $C_r$ coefficients.
+The second pair selects which codebooks to use from {\em all four} of the AC
+ coefficient groups for the $Y'$ coefficients and the $C_b$ and $C_r$
+ coefficients.
+
+The precise specification of how the codebooks are decoded appears in
+ Section~\ref{sub:huffman-tables}.
+
+\section{High-Level Decode Process}
+
+\subsection{Decoder Setup}
+
+Before decoding can begin, a decoder MUST be initialized using the bitstream
+ headers corresponding to the stream to be decoded.
+Theora uses three header packets; all are required, in order, by this
+ specification.
+Once set up, decode may begin at any intra-frame packet---or even inter-frame
+ packets, provided the appropriate decoded reference frames have already been
+ decoded and cached---belonging to the Theora stream.
+In Theora I, all packets after the three initial headers are intra-frame or
+ inter-frame packets.
+
+The header packets are, in order, the identification header, the comment
+ header, and the setup header.
+
+\paragraph{Identification Header}
+
+The identification header identifies the stream as Theora, provides a version
+ number, and defines the characteristics of the video stream such as frame
+ size.
+A complete description of the identification header appears in
+ Section~\ref{sec:idheader}.
+
+\paragraph{Comment Header}
+
+The comment header includes user text comments (`tags') and a vendor string
+ for the application/library that produced the stream.
+The format of the comment header is the same as that used in the Vorbis I and
+ Speex codecs, with slight modifications due to the use of a different bit
+ packing mechanism.
+A complete description of how the comment header is coded appears in
+ Section~\ref{sec:commentheader}, along with a suggested set of tags.
+
+\paragraph{Setup Header}
+
+The setup header includes extensive codec setup information, including the
+ complete set of quantization matrices and Huffman codebooks needed to decode
+ the DCT coefficients.
+A complete description of the setup header appears in
+ Section~\ref{sec:setupheader}.
+
+\subsection{Decode Procedure}
+
+The decoding and synthesis procedure for all video packets is fundamentally the
+ same, with some steps omitted for intra frames.
+\begin{itemize}
+\item
+Decode packet type flag.
+\item
+Decode frame header.
+\item
+Decode coded block information (inter frames only).
+\item
+Decode macro block mode information (inter frames only).
+\item
+Decode motion vectors (inter frames only).
+\item
+Decode block-level \qi\ information.
+\item
+Decode DC coefficient for each coded block.
+\item
+Decode 1st AC coefficient for each coded block.
+\item
+Decode 2nd AC coefficient for each coded block.
+\item
+$\ldots$
+\item
+Decode 63rd AC coefficient for each coded block.
+\item Perform DC coefficient prediction.
+\item Reconstruct coded blocks.
+\item Copy uncoded bocks.
+\item Perform loop filtering.
+\end{itemize}
+
+\begin{verse}
+{\bf Note:} clever rearrangement of the steps in this process is possible.
+As an example, in a memory-constrained environment, one can make multiple
+ passes through the DCT coefficients to avoid buffering them all in memory.
+On the first pass, the starting location of each coefficient is identified, and
+ then 64 separate get pointers are used to read in the 64 DCT coefficients
+ required to reconstruct each coded block in sequence.
+This operation produces entirely equivalent output and is naturally perfectly
+ legal.
+It may even be a benefit in non-memory-constrained environments due to a
+ reduced cache footprint.
+\end{verse}
+
+Theora makes equivalence easy to check by defining all decoding operations in
+ terms of exact integer operations.
+No floating-point math is required, and in particular, the implementation of
+ the iDCT transform MUST be followed precisely.
+This prevents the decoder mismatch problem commonly associated with codecs that
+ provide a less rigorous transform specification.
+Such a mismatch problem would be devastating to Theora, since a single rounding
+ error in one frame could propagate throughout the entire succeeding frame due
+ to DC prediction.
+
+\paragraph{Packet Type Decode}
+
+Theora uses four packet types.
+The first three packet types mark each of the three Theora headers described
+ above.
+The fourth packet type marks a video packet.
+All other packet types are reserved; packets marked with a reserved type should
+ be ignored.
+
+Additionally, zero-length packets are treated as if they were an inter 
+frame with no blocks coded. That is, as a duplicate frame.
+
+\paragraph{Frame Header Decode}
+
+The frame header contains some global information about the current frame.
+The first is the frame type field, which specifies if this is an intra frame or
+ an inter frame.
+Inter frames predict their contents from previously decoded reference frames.
+Intra frames can be independently decoded with no established reference frames.
+
+The next piece of information in the frame header is the list of \qi\ values
+ allowed in the frame.
+Theora allows from one to three different \qi\ values to be used in a single
+ frame, each of which selects a set of six quantization matrices, one for each
+ quantization type (inter or intra), and one for each color plane.
+The first \qi\ value is {\em always} used when dequantizing DC coefficients.
+The \qi\ value used when dequantizing AC coefficients, however, can vary from
+ block to block.
+VP3, in contrast, only allows a single \qi\ value per frame for both the DC and
+ AC coefficients.
+
+\paragraph{Coded Block Information}
+
+This stage determines which blocks in the frame are coded and which are
+ uncoded.
+A \term{coded block list} is constructed which lists all the coded blocks in
+ coded order.
+For intra frames, every block is coded, and so no data needs to be read from
+ the packet.
+
+\paragraph{Macro Block Mode Information}
+
+For intra frames, every block is coded in INTRA mode, and this stage is
+ skipped.
+In inter frames a \term{coded macro block list} is constructed from the coded
+ block list.
+Any macro block which has at least one of its luma blocks coded is considered
+ coded; all other macro blocks are uncoded, even if they contain coded chroma
+ blocks.
+A coding mode is decoded for each coded macro block, and assigned to all its
+ constituent coded blocks.
+All coded chroma blocks in uncoded macro blocks are assigned the INTER\_NOMV
+ coding mode.
+
+\paragraph{Motion Vectors}
+
+Intra frames are coded entirely in INTRA mode, and so this stage is skipped.
+Some inter coding modes, however, require one or more motion vectors to be
+ specified for each macro block.
+These are decoded in this stage, and an appropriate motion vector is assigned
+ to each coded block in the macro block.
+
+\paragraph{Block-Level \qi\ Information}
+
+If a frame allows multiple \qi\ values, the \qi\ value assigned to each block
+ is decoded here.
+Frames that use only a single \qi\ value have nothing to decode.
+
+\paragraph{DCT Coefficients}
+
+Finally, the quantized DCT coefficients are decoded.
+A list of DCT coefficients in zig-zag order for a single block is represented
+ by a list of tokens.
+A token can take on one of 32 different values, each with a different semantic
+ meaning.
+A single token can represent a single DCT coefficient, a run of zero
+ coefficients within a single block, a combination of a run of zero
+ coefficients followed by a single non-zero coefficient, an
+ \term{End-Of-Block marker}, or a run of EOB markers.
+EOB markers signify that the remainder of the block is one long zero run.
+Unlike JPEG and MPEG, there is no requirement for each block to end with 
+ a special marker.
+If non-EOB tokens yield values for all 64 of the coefficients in a block, then
+ no EOB marker occurs.
+
+Each token is associated with a specific \term{token index} in a block.
+For single-coefficient tokens, this index is the zig-zag index of the token in
+ the block.
+For zero-run tokens, this index is the zig-zag index of the {\em first}
+ coefficient in the run.
+For combination tokens, the index is again the zig-zag index of the first
+ coefficient in the zero run.
+For EOB markers, which signify that the remainder of the block is one long zero
+ run, the index is the zig-zag index of the first zero coefficient in that run.
+For EOB runs, the token index is that of the first EOB marker in the run.
+Due to zero runs and EOB markers, a block does not have to have a token for
+ every zig-zag index.
+
+Tokens are grouped in the stream by token index, not by the block they
+ originate from.
+This means that for each zig-zag index in turn, the tokens with that index from
+ {\em all} the coded blocks are coded in coded block order.
+When decoding, a current token index is maintained for each coded block.
+This index is advanced by the number of coefficients that are added to the
+ block as each token is decoded.
+After fully decoding all the tokens with token index \ti, the current token
+ index of every coded block will be \ti\ or greater.
+
+If an EOB run of $n$ blocks is decoded at token index \ti, then it ends the
+ next $n$ blocks in coded block order whose current token index is equal to
+ \ti, but not greater.
+If there are fewer than $n$ blocks with a current token index of \ti, then the
+ decoder goes through the coded block list again from the start, ending blocks
+ with a current token index of $\ti+1$, and so on, until $n$ blocks have been
+ ended.
+
+Tokens are read by parsing a Huffman code that depends on \ti\ and the color
+ plane of the next coded block whose current token index is equal to \ti, but
+ not greater.
+The Huffman codebooks are selected on a per-frame basis from the 80 codebooks
+ defined in the setup header.
+Many tokens have a fixed number of \term{extra bits} associated with them.
+These bits are read from the packet immediately after the token is decoded.
+These are used to define things such as coefficient magnitude, sign, and the
+ length of runs.
+
+\paragraph{DC Prediction}
+
+After the coefficients for each block are decoded, the quantized DC value of
+ each block is adjusted based on the DC values of its neighbors.
+This adjustment is performed by scanning the blocks in raster order, not coded
+ block order.
+
+\paragraph{Reconstruction}
+
+Finally, using the coding mode, motion vector (if applicable), quantized
+ coefficient list, and \qi\ value defined for each block, all the coded blocks
+ are reconstructed.
+The DCT coefficients are dequantized, an inverse DCT transform is applied, and
+ the predictor is formed from the coding mode and motion vector and added to
+ the result.
+
+\paragraph{Loop Filtering}
+
+To complete the reconstructed frame, an ``in-loop'' deblocking filter is
+ applied to the edges of all coded blocks.
+
+
+\chapter{Video Formats}
+
+This section gives a precise description of the video formats that Theora is
+ capable of storing.
+The Theora bitstream is capable of handling video at any arbitrary resolution
+ up to $1048560\times 1048560$.
+Such video would require almost three terabytes of storage per frame for
+ uncompressed data, so compliant decoders MAY refuse to decode images with
+ sizes beyond their capabilities.
+%TODO: What MUST a "compliant" decoder accept?
+%TODO: What SHOULD a decoder use for an upper bound? (derive from total amount
+%TODO:  of memory and memory bandwidth)
+%TODO: Any lower limits?
+%TODO: We really need hardware device profiles, but such things should be
+%TODO:  developed with input from the hardware community.
+%TODO: And even then sometimes they're useless
+
+The remainder of this section talks about two specific aspects of the video
+ format: the color space and the pixel format.
+The first describes how color is represented and how to transform that color
+ representation into a device independent color space such as CIE $XYZ$ (1931).
+The second describes the various schemes for sampling the color values in time
+ and space.
+
+\section{Color Space Conventions}
+
+There are a large number of different color standards used in digital video.
+Since Theora is a lossy codec, it restricts itself to only a few of them to
+ simplify playback.
+Unlike the alternate method of describing all the parameters of the color
+ model, this allows a few dedicated routines for color conversion to be written
+ and heavily optimized in a decoder.
+More flexible conversion functions should instead be specified in an encoder,
+ where additional computational complexity is more easily tolerated.
+The color spaces were selected to give a fair representation of color standards
+ in use around the world today.
+Most of the standards that do not exactly match one of these can be converted
+ to one fairly easily.
+
+All Theora color spaces are $Y'C_bC_r$ color spaces with one luma channel and
+ two chroma channels.
+Each channel contains 8-bit discrete values in the range $0\ldots255$, which
+ represent non-linear gamma pre-corrected signals.
+The Theora identification header contains an 8-bit value that describes the
+ color space.
+This merely selects one of the color spaces available from an enumerated list.
+Currently, only two color spaces are defined, with a third possibility that
+ indicates the color space is ``unknown".
+
+\section{Color Space Conversions and Parameters}
+\label{sec:color-xforms}
+
+The parameters which describe the conversions between each color space are
+ listed below.
+These are the parameters needed to map colors from the encoded $Y'C_bC_r$
+ representation to the device-independent color space CIE $XYZ$ (1931).
+These parameters define abstract mathematical conversion functions which are
+ infinitely precise.
+The accuracy and precision with which the conversions are performed in a real
+ system is determined by the quality of output desired and the available
+ processing power.
+Exact decoder output is defined by this specification only in the original
+ $Y'C_bC_r$ space.
+
+\begin{description}
+\item[$Y'C_bC_r$ to $Y'P_bP_r$:]
+\vspace{\baselineskip}\hfill
+
+This conversion takes 8-bit discrete values in the range $[0\ldots255]$ and
+ maps them to real values in the range $[0\ldots1]$ for Y and
+ $[-\frac{1}{2}\ldots\frac{1}{2}]$ for $P_b$ and $P_r$.
+Because some values may fall outside the offset and excursion defined for each
+ channel in the $Y'C_bC_r$ space, the results may fall outside these ranges in
+ $Y'P_bP_r$ space.
+No clamping should be done at this stage.
+
+\begin{align}
+Y'_\mathrm{out} & =
+ \frac{Y'_\mathrm{in}-\mathrm{Offset}_Y}{\mathrm{Excursion}_Y} \\
+P_b             & =
+ \frac{C_b-\mathrm{Offset}_{C_b}}{\mathrm{Excursion}_{C_b}} \\
+P_r             & =
+ \frac{C_r-\mathrm{Offset}_{C_r}}{\mathrm{Excursion}_{C_r}}
+\end{align}
+
+Parameters: $\mathrm{Offset}_{Y,C_b,C_r}$, $\mathrm{Excursion}_{Y,C_b,C_r}$.
+
+\item[$Y'P_bP_r$ to $R'G'B'$:]
+\vspace{\baselineskip}\hfill
+
+This conversion takes the one luma and two chroma channel representation and
+ maps it to the non-linear $R'G'B'$ space used to drive actual output devices.
+Values should be clamped into the range $[0\ldots1]$ after this stage.
+
+\begin{align}
+R' & = Y'+2(1-K_r)P_r \\
+G' & = Y'-2\frac{(1-K_b)K_b}{1-K_b-K_r}P_b-2\frac{(1-K_r)K_r}{1-K_b-K_r}P_r\\
+B' & = Y'+2(1-K_b)P_b
+\end{align}
+
+Parameters: $K_b,K_r$.
+
+\item[$R'G'B'$ to $RGB$ (Output device gamma correction):]
+\vspace{\baselineskip}\hfill
+
+This conversion takes the non-linear $R'G'B'$ voltage levels and maps them to
+ linear light levels produced by the actual output device.
+Note that this conversion is only that of the output device, and its inverse is
+ {\em not} that used by the input device.
+Because a dim viewing environment is assumed in most television standards, the
+ overall gamma between the input and output devices is usually around $1.1$ to
+ $1.2$, and not a strict $1.0$.
+
+For calibration with actual output devices, the model
+\begin{align}
+L & =(E'+\Delta)^\gamma
+\end{align}
+ should be used, with $\Delta$ the free parameter and $\gamma$ held fixed to
+ the value specified in this document.
+The conversion function presented here is an idealized version with $\Delta=0$.
+
+\begin{align}
+R & = R'^\gamma \\
+G & = G'^\gamma \\
+B & = B'^\gamma
+\end{align}
+
+Parameters: $\gamma$.
+
+\item[$RGB$ to $R'G'B'$ (Input device gamma correction):]
+\vspace{\baselineskip}\hfill
+
+%TODO: Tag section as non-normative
+
+This conversion takes linear light levels and maps them to the non-linear
+ voltage levels produced in the actual input device.
+This information is merely informative.
+It is not required for building a decoder or for converting between the various
+ formats and the actual output capabilities of a particular device.
+
+A linear segment is introduced on the low end to reduce noise in dark areas of
+ the image.
+The rest of the scale is adjusted so that the power segment of the curve
+ intersects the linear segment with the proper slope, and so that it still maps
+ 0 to 0 and 1 to 1.
+
+\begin{align}
+R' & = \left\{
+\begin{array}{ll}
+\alpha R,                     & 0\le R<\delta   \\
+(1+\epsilon)R^\beta-\epsilon, & \delta\le R\le1
+\end{array}\right. \\
+G' & = \left\{
+\begin{array}{ll}
+\alpha G,                     & 0\le G<\delta   \\
+(1+\epsilon)G^\beta-\epsilon, & \delta\le G\le1
+\end{array}\right. \\
+B' & = \left\{
+\begin{array}{ll}
+\alpha B,                     & 0\le B<\delta   \\
+(1+\epsilon)B^\beta-\epsilon, & \delta\le B\le1
+\end{array}\right.
+\end{align}
+
+Parameters: $\beta$, $\alpha$, $\delta$, $\epsilon$.
+
+\item[$RGB$ to CIE $XYZ$ (1931):]
+\vspace{\baselineskip}\hfill
+
+This conversion maps a device-dependent linear RGB space to the
+ device-independent linear CIE $XYZ$ space.
+The parameters are the CIE chromaticity coordinates of the three
+ primaries---red, green, and blue---as well as the chromaticity coordinates
+ of the white point of the device.
+This is how hardware manufacturers and standards typically describe a
+ particular $RGB$ space.
+The math required to convert these parameters into a useful transformation
+ matrix is reproduced below.
+
+\begin{align}
+F                  & =
+\left[\begin{array}{ccc}
+\frac{x_r}{y_r}       & \frac{x_g}{y_g}       & \frac{x_b}{y_b}       \\
+1                     & 1                     & 1                     \\
+\frac{1-x_r-y_r}{y_r} & \frac{1-x_g-y_g}{y_g} & \frac{1-x_b-y_b}{y_b}
+\end{array}\right] \\
+\left[\begin{array}{c}
+s_r \\
+s_g \\
+s_b
+\end{array}\right] & =
+F^{-1}\left[\begin{array}{c}
+\frac{x_w}{y_w} \\
+1 \\
+\frac{1-x_w-y_w}{y_w}
+\end{array}\right] \\
+\left[\begin{array}{c}
+X \\
+Y \\
+Z
+\end{array}\right] & =
+F\left[\begin{array}{c}
+s_rR \\
+s_gG \\
+s_bB
+\end{array}\right]
+\end{align}
+Parameters: $x_r,x_g,x_b,x_w, y_r,y_g,y_b,y_w$.
+
+\end{description}
+
+\section{Available Color Spaces}
+\label{sec:colorspaces}
+
+These are the color spaces currently defined for use by Theora video.
+Each one has a short name, with which it is referred to in this document, and
+ a more detailed specification of the standards from which its parameters are
+ derived.
+Some standards do not specify all the parameters necessary.
+For these unspecified parameters, this document serves as the definition of
+ what should be used when encoding or decoding Theora video.
+
+\subsection{Rec.~470M (Rec.~ITU-R~BT.470-6 System M/NTSC with
+ Rec.~ITU-R~BT.601-5)}
+\label{sec:470m}
+
+This color space is used by broadcast television and DVDs in much of the
+ Americas, Japan, Korea, and the Union of Myanmar \cite{rec470}.
+This color space may also be used for System M/PAL (Brazil), with an
+ appropriate conversion supplied by the encoder to compensate for the
+ different gamma value.
+See Section~\ref{sec:470bg} for an appropriate gamma value to assume for M/PAL
+ input.
+
+In the US, studio monitors are adjusted to a D65 white point
+ ($x_w,y_w=0.313,0.329$).
+In Japan, studio monitors are adjusted to a D white of 9300K
+ ($x_w,y_w=0.285,0.293$).
+
+Rec.~470 does not specify a digital encoding of the color signals.
+For Theora, Rec.~ITU-R~BT.601-5 \cite{rec601} is used, starting from the
+ $R'G'B'$ signals specified by Rec.~470.
+
+Rec.~470 does not specify an input gamma function.
+For Theora, the Rec.~709 \cite{rec709} input function is assumed.
+This is the same as that specified by SMPTE 170M \cite{smpte170m}, which claims
+ to reflect modern practice in the creation of NTSC signals circa 1994.
+
+The parameters for all the color transformations defined in
+ Section~\ref{sec:color-xforms} are given in Table~\ref{tab:470m}.
+
+\begin{table}[htb]
+\begin{align*}
+\mathrm{Offset}_{Y,C_b,C_r}    & = (16, 128, 128)  \\
+\mathrm{Excursion}_{Y,C_b,C_r} & = (219, 224, 224) \\
+K_r                            & = 0.299           \\
+K_b                            & = 0.114           \\
+\gamma                         & = 2.2             \\
+\beta                          & = 0.45            \\
+\alpha                         & = 4.5             \\
+\delta                         & = 0.018           \\
+\epsilon                       & = 0.099           \\
+x_r,y_r                        & = 0.67, 0.33      \\
+x_g,y_g                        & = 0.21, 0.71      \\
+x_b,y_b                        & = 0.14, 0.08      \\
+\text{(Illuminant C) } x_w,y_w & = 0.310, 0.316    \\
+\end{align*}
+\caption{Rec.~470M Parameters}
+\label{tab:470m}
+\end{table}
+
+\subsection{Rec.~470BG (Rec.~ITU-R~BT.470-6 Systems B and G with
+ Rec.~ITU-R~BT.601-5)}
+\label{sec:470bg}
+
+This color space is used by the PAL and SECAM systems in much of the rest of
+ the world \cite{rec470}
+This can be used directly by systems (B, B1, D, D1, G, H, I, K, N)/PAL and (B,
+ D, G, H, K, K1, L)/SECAM\@.
+
+\begin{verse}
+{\bf Note:} the Rec.~470BG chromaticity values are different from those
+ specified in Rec.~470M\@.
+When PAL and SECAM systems were first designed, they were based upon the same
+ primaries as NTSC\@.
+However, as methods of making color picture tubes have changed, the primaries
+ used have changed as well.
+The U.S. recommends using correction circuitry to approximate the existing,
+ standard NTSC primaries.
+Current PAL and SECAM systems have standardized on primaries in accord with
+ more recent technology.
+\end{verse}
+
+Rec.~470 provisionally permits the use of the NTSC chromaticity values (given
+ in Section~\ref{sec:470m}) with legacy PAL and SECAM equipment.
+In Theora, material must be decoded assuming the new PAL and SECAM primaries.
+Material intended for display on old legacy devices should be converted by the
+ decoder.
+
+The official Rec.~470BG specifies a gamma value of $\gamma=2.8$.
+However, in practice this value is unrealistically high \cite{Poyn97}.
+Rec.~470BG states that the overall system gamma should be approximately
+ $\gamma\beta=1.2$.
+Since most cameras pre-correct with a gamma value of $\beta=0.45$,
+ this suggests an output device gamma of approximately $\gamma=2.67$.
+This is the value recommended for use with PAL systems in Theora.
+
+Rec.~470 does not specify a digital encoding of the color signals.
+For Theora, Rec.~ITU-R~BT.601-5 \cite{rec601} is used, starting from the
+ $R'G'B'$ signals specified by Rec.~470.
+
+Rec.~470 does not specify an input gamma function.
+For Theora, the Rec 709 \cite{rec709} input function is assumed.
+
+The parameters for all the color transformations defined in
+ Section~\ref{sec:color-xforms} are given in Table~\ref{tab:470bg}.
+
+\begin{table}[htb]
+\begin{align*}
+\mathrm{Offset}_{Y,C_b,C_r}    & = (16, 128, 128)  \\
+\mathrm{Excursion}_{Y,C_b,C_r} & = (219, 224, 224) \\
+K_r                            & = 0.299           \\
+K_b                            & = 0.114           \\
+\gamma                         & = 2.67            \\
+\beta                          & = 0.45            \\
+\alpha                         & = 4.5             \\
+\delta                         & = 0.018           \\
+\epsilon                       & = 0.099           \\
+x_r,y_r                        & = 0.64, 0.33      \\
+x_g,y_g                        & = 0.29, 0.60      \\
+x_b,y_b                        & = 0.15, 0.06      \\
+\text{(D65) } x_w,y_w          & = 0.313, 0.329    \\
+\end{align*}
+\caption{Rec.~470BG Parameters}
+\label{tab:470bg}
+\end{table}
+
+\section{Pixel Formats}
+\label{sec:pixfmts}
+
+Theora supports several different pixel formats, each of which uses different
+ subsampling for the chroma planes relative to the luma plane.
+A decoder may need to recover a full resolution chroma plane with samples
+ co-sited with the luma plane in order to convert to RGB for display or perform
+ other processing.
+Decoders can assume that the chroma signal satisfies the Nyquist-Shannon
+ sampling theorem.
+The ideal low-pass reconstruction filter this implies is not practical, but any
+ suitable approximation can be used, depending on the available computing
+ power.
+Decoders MAY simply use a box filter, assigning to each luma sample the chroma
+ sample closest to it.
+Encoders would not go wrong in assuming that this will be the most common
+ approach.
+
+\subsection{4:4:4 Subsampling}
+\label{sec:444}
+
+All three color planes are stored at full resolution---each pixel has a $Y'$,
+ a $C_b$ and a $C_r$ value (see Figure~\ref{fig:pixel444}).
+The samples in the different planes are all at co-located sites.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel444}
+\end{center}
+\caption{Pixels encoded 4:4:4}
+\label{fig:pixel444}
+\end{figure}
+
+% Figure.
+%YRB         YRB
+%
+%
+%
+%YRB         YRB
+%
+%
+%
+
+
+\subsection{4:2:2 Subsampling}
+\label{sec:422}
+
+The $C_b$ and $C_r$ planes are stored with half the horizontal resolution of
+ the $Y'$ plane.
+Thus, each of these planes has half the number of horizontal blocks as the luma
+ plane (see Figure~\ref{fig:pixel422}).
+Similarly, they have half the number of horizontal super blocks, rounded up.
+Macro blocks are defined across color planes, and so their number does not
+ change, but each macro block contains half as many chroma blocks.
+
+The chroma samples are vertically aligned with the luma samples, but
+ horizontally centered between two luma samples.
+Thus, each luma sample has a unique closest chroma sample.
+A horizontal phase shift may be required to produce signals which use different
+ horizontal chroma sampling locations for compatibility with different systems.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel422}
+\end{center}
+\caption{Pixels encoded 4:2:2}
+\label{fig:pixel422}
+\end{figure}
+
+% Figure.
+%Y     RB    Y           Y     RB    Y
+%
+%
+%
+%Y     RB    Y           Y     RB    Y
+%
+%
+%
+
+\subsection{4:2:0 Subsampling}
+\label{sec:420}
+
+The $C_b$ and $C_r$ planes are stored with half the horizontal and half the
+ vertical resolution of the $Y'$ plane.
+Thus, each of these planes has half the number of horizontal blocks and half
+ the number of vertical blocks as the luma plane, for a total of one quarter
+ the number of blocks (see Figure~\ref{fig:pixel420}).
+Similarly, they have half the number of horizontal super blocks and half the
+ number of vertical super blocks, rounded up.
+Macro blocks are defined across color planes, and so their number does not
+ change, but each macro block contains within it one quarter as many 
+ chroma blocks.
+
+The chroma samples are vertically and horizontally centered between four luma
+ samples.
+Thus, each luma sample has a unique closest chroma sample.
+This is the same sub-sampling pattern used with JPEG, MJPEG, and MPEG-1, and
+ was inherited from VP3.
+A horizontal or vertical phase shift may be required to produce signals which
+ use different chroma sampling locations for compatibility with different
+ systems.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel420}
+\end{center}
+\caption{Pixels encoded 4:2:0}
+\label{fig:pixel420}
+\end{figure}
+
+% Figure.
+%Y           Y           Y           Y
+%
+%      RB                      RB
+%
+%Y           Y           Y           Y
+%
+%
+%
+%Y           Y           Y           Y
+%
+%      RB                      RB
+%
+%Y           Y           Y           Y
+%
+%
+%
+
+\subsection{Subsampling and the Picture Region}
+
+Although the frame size must be an integral number of macro blocks, and thus
+ both the number of pixels and the number of blocks in each direction must be
+ even, no such requirement is made of the picture region.
+Thus, when using subsampled pixel formats, careful attention must be paid to
+ which chroma samples correspond to which luma samples.
+
+As mentioned above, for each pixel format, there is a unique chroma sample that
+ is the closest to each luma sample.
+When cropping the chroma planes to the picture region, all the chroma samples
+ corresponding to a luma sample in the cropped picture region must be included.
+Thus, when dividing the width or height of the picture region by two to obtain
+ the size of the subsampled chroma planes, they must be rounded up.
+
+Furthermore, the sampling locations are defined relative to the frame,
+ {\em not} the picture region.
+When using the 4:2:2 and 4:2:0 formats, the locations of chroma samples
+ relative to the luma samples depends on whether or not the X offset of the
+ picture region is odd.
+If the offset is even, each column of chroma samples corresponds to two columns
+ of luma samples (see Figure~\ref{fig:pic_even} for an example).
+The only exception is if the width is odd, in which case the last column
+ corresponds to only one column of luma samples (see Figure~\ref{fig:pic_even_odd}).
+If the offset is odd, then the first column of chroma samples corresponds to
+ only one column of luma samples, while the remaining columns each correspond
+ to two (see Figure~\ref{fig:pic_odd}).
+In this case, if the width is even, the last column again corresponds to only
+ one column of luma samples (see Figure~\ref{fig:pic_odd_even}).
+
+A similar process is followed with the rows of a picture region of odd height
+ encoded in the 4:2:0 format.
+If the Y offset is even, each row of chroma samples corresponds to two rows of
+ luma samples (see Figure~\ref{fig:pic_even}), except with an odd height, where
+ the last row corresponds to one row of chroma luna samples only (see 
+ Figure~\ref{fig:pic_even_odd}).
+If the offset is odd, then it is the first row of chroma samples which
+ corresponds to only one row of luma samples, while the remaining rows each
+ correspond to two (Figure~\ref{fig:pic_odd}), except with an even height, 
+ where the last row also corresponds to one (Figure~\ref{fig:pic_odd_even}).
+
+Encoders should be aware of these differences in the subsampling when using an
+ even or odd offset.
+In the typical case, with an even width and height, where one expects two rows
+ or columns of luma samples for every row or column of chroma samples, the
+ encoder must take care to ensure that the offsets used are both even.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_even}
+\end{center}
+\caption{Pixel correspondence between color planes with even picture 
+ offset and even picture size}
+\label{fig:pic_even}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_even_odd}
+\end{center}
+\caption{Pixel correspondence with even picture offset and 
+ odd picture size}
+\label{fig:pic_even_odd}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_odd}
+\end{center}
+\caption{Pixel correspondence with odd picture offset and 
+ odd picture size}
+\label{fig:pic_odd}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_odd_even}
+\end{center}
+\caption{Pixel correspondence with odd picture offset and 
+ even picture size}
+\label{fig:pic_odd_even}
+\end{figure}
+
+
+\chapter{Bitpacking Convention}
+\label{sec:bitpacking}
+
+\section{Overview}
+
+The Theora codec uses relatively unstructured raw packets containing
+ binary integer fields of arbitrary width.
+Logically, each packet is a bitstream in which bits are written one-by-one by
+ the encoder and then read one-by-one in the same order by the decoder.
+Most current binary storage arrangements group bits into a native storage unit
+ of eight bits (octets), sixteen bits, thirty-two bits, or less commonly other
+ fixed sizes.
+The Theora bitpacking convention specifies the correct mapping of the logical
+ packet bitstream into an actual representation in fixed-width units.
+
+\subsection{Octets and Bytes}
+
+In most contemporary architectures, a `byte' is synonymous with an `octect',
+ that is, eight bits.
+For purposes of the bitpacking convention, a byte implies the smallest native
+ integer storage representation offered by a platform.
+Modern file systems invariably offer bytes as the fundamental atom of storage.
+
+The most ubiquitous architectures today consider a `byte' to be an octet.
+Note, however, that the Theora bitpacking convention is still well defined for
+ any native byte size; an implementation can use the native bit-width of a
+ given storage system.
+This document assumes that a byte is one octet for purposes of example only.
+
+\subsection{Words and Byte Order}
+
+A `word' is an integer size that is a grouped multiple of the byte size.
+Most architectures consider a word to be a group of two, four, or eight bytes.
+Each byte in the word can be ranked by order of `significance', e.g.\ the
+ significance of the bits in each byte when storing a binary integer in the
+ word.
+Several byte orderings are possible in a word.
+The common ones are
+\begin{itemize}
+\item{Big-endian:}
+in which the most significant byte comes first, e.g.\ 3-2-1-0,
+\item{Little-endian:}
+in which the least significant byte comes first, e.g.\ 0-1-2-3, and
+\item{Mixed-endian:}
+one of the less-common orderings that cannot be put into the above two
+ categories, e.g.\ 3-1-2-0 or 0-2-1-3.
+\end{itemize}
+
+The Theora bitpacking convention specifies storage and bitstream manipulation
+ at the byte, not word, level.
+Thus host word ordering is of a concern only during optimization, when writing
+ code that operates on a word of storage at a time rather than a byte.
+Logically, bytes are always encoded and decoded in order from byte zero through
+ byte $n$.
+
+\subsection{Bit Order}
+
+A byte has a well-defined `least significant' bit (LSb), which is the only bit
+ set when the byte is storing the two's complement integer value $+1$.
+A byte's `most significant' bit (MSb) is at the opposite end.
+Bits in a byte are numbered from zero at the LSb to $n$ for the MSb, where
+ $n=7$ in an octet.
+
+\section{Coding Bits into Bytes}
+
+The Theora codec needs to encode arbitrary bit-width integers from zero to 32
+ bits wide into packets.
+These integer fields are not aligned to the boundaries of the byte
+ representation; the next field is read at the bit position immediately
+ after the end of the previous field.
+
+The decoder logically unpacks integers by first reading the MSb of a binary
+ integer from the logical bitstream, followed by the next most significant
+ bit, etc., until the required number of bits have been read.
+When unpacking the bytes into bits, the decoder begins by reading the MSb of
+ the integer to be read from the most significant unread bit position of the
+ source byte, followed by the next-most significant bit position of the
+ destination integer, and so on up to the requested number of bits.
+Note that this differs from the Vorbis I codec, which
+ begins decoding with the LSb of the source integer, reading it from the
+ LSb of the source byte.
+When all the bits of the current source byte are read, decoding continues with
+ the MSb of the next byte.
+Any unfilled bits in the last byte of the packet MUST be cleared to zero by the
+ encoder.
+
+\subsection{Signedness}
+
+The binary integers decoded by the above process may be either signed or
+ unsigned.
+This varies from integer to integer, and this specification
+ indicates how each value should be interpreted as it is read.
+That is, depending on context, the three bit binary pattern \bin{111} can be
+ taken to represent either `$7$' as an unsigned integer or `$-1$' as a signed,
+ two's complement integer.
+
+\subsection{Encoding Example}
+
+The following example shows the state of an (8-bit) byte stream after several
+ binary integers are encoded, including the location of the put pointer for the
+ next bit to write to and the total length of the stream in bytes.
+
+Encode the 4 bit unsigned integer value `12' (\bin{1100}) into an empty byte
+ stream.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{}& &&&&$\downarrow$&&&& \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+                           0 & 0 & 0 & 0 & $\leftarrow$     \\
+byte 1   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                  \\
+byte 2   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                  \\
+byte 3   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                  \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}& \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 1 byte
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 3 bit signed integer value `-1' (\bin{111}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&&&&$\downarrow$& \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+           \textbf{1} & \textbf{1} & \textbf{1} & 0 & $\leftarrow$ \\
+byte 1   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                         \\
+byte 2   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                         \\
+byte 3   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                         \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}&        \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 1 byte
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 7 bit integer value `17' (\bin{0010001}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&&&$\downarrow$&& \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+           \textbf{1} & \textbf{1} & \textbf{1} & \textbf{0} & \\
+byte 1   & \textbf{0} & \textbf{1} & \textbf{0} & \textbf{0} &
+           \textbf{0} & \textbf{1} & 0 & 0 & $\leftarrow$      \\
+byte 2   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                     \\
+byte 3   & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &                     \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}&    \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 2 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 13 bit integer value `6969' (\bin{11011\ 00111001}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&$\downarrow$&&&&& \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 &            \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+           \textbf{1} & \textbf{1} & \textbf{1} & \textbf{0} & \\
+byte 1   & \textbf{0} & \textbf{1} & \textbf{0} & \textbf{0} &
+           \textbf{0} & \textbf{1} & \textbf{1} & \textbf{1} & \\
+byte 2   & \textbf{0} & \textbf{1} & \textbf{1} & \textbf{0} &
+           \textbf{0} & \textbf{1} & \textbf{1} & \textbf{1} & \\
+byte 3   & \textbf{0} & \textbf{0} & \textbf{1} &
+                       0 & 0 & 0 & 0 & 0 & $\leftarrow$        \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}&    \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+\subsection{Decoding Example}
+
+The following example shows the state of the (8-bit) byte stream encoded in the
+ previous example after several binary integers are decoded, including the
+ location of the get pointer for the next bit to read.
+
+Read a two bit unsigned integer from the example encoded above.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&$\downarrow$&&&&&&              \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 &              \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & 0 & 0 & 1 & 1 & 1 & 0 & $\leftarrow$ \\
+byte 1   & 0 & 1 & 0 & 0 & 0 & 1 & 1 & 1 &              \\
+byte 2   & 0 & 1 & 1 & 0 & 0 & 1 & 1 & 1 &              \\
+byte 3   & 0 & 0 & 1 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Value read: 3 (\bin{11}).
+
+Read another two bit unsigned integer from the example encoded above.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&$\downarrow$&&&&              \\
+         & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 &              \\\cline{1-9}
+byte 0   & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+                           1 & 1 & 1 & 0 & $\leftarrow$ \\
+byte 1   & 0 & 1 & 0 & 0 & 0 & 1 & 1 & 1 &              \\
+byte 2   & 0 & 1 & 1 & 0 & 0 & 1 & 1 & 1 &              \\
+byte 3   & 0 & 0 & 1 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Value read: 0 (\bin{00}).
+
+Two things are worth noting here.
+\begin{itemize}
+\item
+Although these four bits were originally written as a single four-bit integer,
+ reading some other combination of bit-widths from the bitstream is well
+ defined.
+No artificial alignment boundaries are maintained in the bitstream.
+\item
+The first value is the integer `$3$' only because the context stated we were
+ reading an unsigned integer.
+Had the context stated we were reading a signed integer, the returned value
+ would have been the integer `$-1$'.
+\end{itemize}
+
+\subsection{End-of-Packet Alignment}
+
+The typical use of bitpacking is to produce many independent byte-aligned
+ packets which are embedded into a larger byte-aligned container structure,
+ such as an Ogg transport bitstream.
+Externally, each bitstream encoded as a byte stream MUST begin and end on a
+ byte boundary.
+Often, the encoded packet bitstream is not an integer number of bytes, and so
+ there is unused space in the last byte of a packet.
+
+%r: I think the generality here is necessary to be consistent with our assertions
+%r: elsewhere about being independent of transport and byte width
+When a Theora encoder produces packets for embedding in a byte-aligned
+ container, unused space in the last byte of a packet is always zeroed during
+ the encoding process.
+Thus, should this unused space be read, it will return binary zeroes.
+There is no marker pattern or stuffing bits that will allow the decoder to
+ obtain the exact size, in bits, of the original bitstream.
+This knowledge is not required for decoding.
+
+Attempting to read past the end of an encoded packet results in an
+ `end-of-packet' condition.
+Any further read operations after an `end-of-packet' condition shall also
+ return `end-of-packet'.
+Unlike Vorbis, Theora does not use truncated packets as a normal mode of
+ operation.
+Therefore if a decoder encounters the `end-of-packet' condition during normal
+ decoding, it may attempt to use the bits that were read to recover as much of
+ encoded data as possible, signal a warning or error, or both.
+
+\subsection{Reading Zero Bit Integers}
+
+Reading a zero bit integer returns the value `$0$' and does not increment
+ the stream pointer.
+Reading to the end of the packet, but not past the end, so that an
+ `end-of-packet' condition is not triggered, and then reading a zero bit
+ integer shall succeed, returning `$0$', and not trigger an `end-of-packet'
+ condition.
+Reading a zero bit integer after a previous read sets the `end-of-packet'
+ condition shall fail, also returning `end-of-packet'.
+
+\chapter{Bitstream Headers}
+\label{sec:headers}
+
+A Theora bitstream begins with three header packets.
+The header packets are, in order, the identification header, the comment
+ header, and the setup header.
+All are required for decode compliance.
+An end-of-packet condition encountered while decoding the identification or
+ setup header packets renders the stream undecodable.
+An end-of-packet condition encountered while decode the comment header is a
+ non-fatal error condition, and MAY be ignored by a decoder.
+
+\paragraph{VP3 Compatibility}
+
+VP3 relies on the headers provided by its container, usually either AVI or
+ Quicktime.
+As such, several parameters available in these headers are not available to VP3
+ streams.
+These are indicated as they appear in the sections below.
+
+\section{Common Header Decode}
+\label{sub:common-header}
+
+\begin{figure}[Htbp]
+\begin{center}
+\begin{verbatim}
+  0                   1                   2                   3   
+  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |  header type  |      `t'      |      `h'      |      `e'      |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |      `o'      |      `r'      |      `a'      |     data...   |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                 ... header-specific data ...                  |
+ |                              ...                              |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+\end{verbatim}
+\end{center}
+\caption{Common Header Packet Layout}
+\label{fig:commonheader}
+\end{figure}
+
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{HEADERTYPE} & Integer & 8 & No & The type of the header being
+ decoded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+Each header packet begins with the same header fields, which are decoded as
+ follows:
+
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as \bitvar{HEADERTYPE}.
+If the most significant bit of this integer is not set, then stop.
+This is not a header packet.
+\item
+Read 6 8-bit unsigned integers.
+If these do not have the values \hex{74}, \hex{68}, \hex{65}, \hex{6F},
+ \hex{72}, and \hex{61}, respectively, then stop.
+This stream is not decodable by this specification.
+These values correspond to the ASCII values of the characters `t', `h', `e',
+ `o', `r', and `a'.
+\end{enumerate}
+
+Decode continues according to \bitvar{HEADERTYPE}.
+The identification header is type \hex{80}, the comment header is type
+ \hex{81}, and the setup header is type \hex{82}.
+These packets must occur in the order: identification, comment, setup.
+%r: I clarified the initial-bit scheme here
+%TBT: Dashes let the reader know they'll have to pick up the rest of the
+%TBT:  sentence after the explanatory phrase.
+%TBT: Otherwise it just sounds like the bit must exist.
+All header packets have the most significant bit of the type
+ field---which is the initial bit in the packet---set.
+This distinguishes them from video data packets in which the first bit
+ is unset.
+% extra header packets are a feature Dan argued for way back when for 
+% backward-compatible extensions (and icc colourspace for example)
+% I think it's reasonable
+%TBT: You can always just stick more stuff in the setup header.
+Packets with other header types (\hex{83}--\hex{FF}) are reserved and MUST be
+ ignored.
+
+\section{Identification Header Decode}
+\label{sec:idheader}
+
+\begin{figure}[Htbp]
+\begin{center}
+\begin{verbatim}
+  0                   1                   2                   3   
+  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |      0x80     |      `t'      |      `h'      |      `e'      |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |      `o'      |      `r'      |      `a'      |     VMAJ      |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |     VMIN      |     VREV      |           FMBW                |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |             FMBH              |           PICW...             |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |   ...PICW     |                 PICH                          |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |     PICX      |     PICY      |            FRN...             |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |           ...FRN              |            FRD...             |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |           ...FRD              |            PARN...            |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |    ...PARN    |                   PARD                        |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |      CS       |                  NOMBR                        |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |    QUAL   | KFGSHIFT| PF| Res |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+\end{verbatim}
+\end{center}
+\caption{Identification Header Packet}
+\label{fig:idheader}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{VMAJ}     & Integer &  8 & No & The major version number. \\
+\bitvar{VMIN}     & Integer &  8 & No & The minor version number. \\
+\bitvar{VREV}     & Integer &  8 & No & The version revision number. \\
+\bitvar{FMBW}     & Integer & 16 & No & The width of the frame in macro
+ blocks. \\
+\bitvar{FMBH}     & Integer & 16 & No & The height of the frame in macro
+ blocks. \\
+\bitvar{NSBS}     & Integer & 32 & No & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS}      & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{NMBS}     & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{PICW}     & Integer & 20 & No & The width of the picture region in
+ pixels. \\
+\bitvar{PICH}     & Integer & 20 & No & The height of the picture region in
+ pixels. \\
+\bitvar{PICX}     & Integer &  8 & No & The X offset of the picture region in
+ pixels. \\
+\bitvar{PICY}     & Integer &  8 & No & The Y offset of the picture region in
+ pixels. \\
+\bitvar{FRN}      & Integer & 32 & No & The frame-rate numerator. \\
+\bitvar{FRD}      & Integer & 32 & No & The frame-rate denominator. \\
+\bitvar{PARN}     & Integer & 24 & No & The pixel aspect-ratio numerator. \\
+\bitvar{PARD}     & Integer & 24 & No & The pixel aspect-ratio denominator. \\
+\bitvar{CS}       & Integer &  8 & No & The color space. \\
+\bitvar{PF}       & Integer &  2 & No & The pixel format. \\
+\bitvar{NOMBR}    & Integer & 24 & No & The nominal bitrate of the stream, in
+ bits per second. \\
+\bitvar{QUAL}     & Integer &  6 & No & The quality hint. \\
+\bitvar{KFGSHIFT} & Integer &  5 & No & The amount to shift the key frame
+ number by in the granule position. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+The identification header is a short header with only a few fields used to
+ declare the stream definitively as Theora and provide detailed information
+ about the format of the fully decoded video data.
+The identification header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{80}, then stop.
+This packet is not the identification header.
+\item
+Read an 8-bit unsigned integer as \bitvar{VMAJ}.
+If \bitvar{VMAJ} is not $3$, then stop.
+This stream is not decodable according to this specification.
+\item
+Read an 8-bit unsigned integer as \bitvar{VMIN}.
+If \bitvar{VMIN} is not $2$, then stop.
+This stream is not decodable according to this specification.
+\item
+Read an 8-bit unsigned integer as \bitvar{VREV}.
+If \bitvar{VREV} is greater than $1$, then this stream
+may contain optional features or interpretational changes 
+documented in a future version of this specification.
+Regardless of the value of \bitvar{VREV}, the stream is decodable 
+according to this specification.
+\item
+Read a 16-bit unsigned integer as \bitvar{FMBW}.
+This MUST be greater than zero.
+This specifies the width of the coded frame in macro blocks.
+The actual width of the frame in pixels is $\bitvar{FMBW}*16$.
+\item
+Read a 16-bit unsigned integer as \bitvar{FMBH}.
+This MUST be greater than zero.
+This specifies the height of the coded frame in macro blocks.
+The actual height of the frame in pixels is $\bitvar{FMBH}*16$.
+\item
+Read a 24-bit unsigned integer as \bitvar{PICW}.
+This MUST be no greater than $(\bitvar{FMBW}*16)$.
+Note that 24 bits are read, even though only 20 bits are sufficient to specify
+ any value of the picture width.
+This is done to preserve octet alignment in this header, to allow for a
+ simplified parser implementation.
+\item
+Read a 24-bit unsigned integer as \bitvar{PICH}.
+This MUST be no greater than $(\bitvar{FMBH}*16)$.
+Together with \bitvar{PICW}, this specifies the size of the displayable picture
+ region within the coded frame.
+See Figure~\ref{fig:pic-frame}.
+Again, 24 bits are read instead of 20.
+\item
+Read an 8-bit unsigned integer as \bitvar{PICX}.
+This MUST be no greater than $(\bitvar{FMBW}*16-\bitvar{PICX})$.
+\item
+Read an 8-bit unsigned integer as \bitvar{PICY}.
+This MUST be no greater than $(\bitvar{FMBH}*16-\bitvar{PICY})$.
+Together with \bitvar{PICX}, this specifies the location of the lower-left
+ corner of the displayable picture region.
+See Figure~\ref{fig:pic-frame}.
+\item
+Read a 32-bit unsigned integer as \bitvar{FRN}.
+This MUST be greater than zero.
+\item
+Read a 32-bit unsigned integer as \bitvar{FRD}.
+This MUST be greater than zero.
+Theora is a fixed-frame rate video codec.
+Frames are sampled at the constant rate of $\frac{\bitvar{FRN}}{\bitvar{FRD}}$
+ frames per second.
+The presentation time of the first frame is at zero seconds.
+No mechanism is provided to specify a non-zero offset for the initial
+ frame.
+\item
+Read a 24-bit unsigned integer as \bitvar{PARN}.
+\item
+Read a 24-bit unsigned integer as \bitvar{PARD}.
+Together with \bitvar{PARN}, these specify the aspect ratio of the pixels
+ within a frame, defined as the ratio of the physical width of a pixel to its
+ physical height.
+This is given by the ratio $\bitvar{PARN}:\bitvar{PARD}$.
+If either of these fields are zero, this indicates that pixel aspect ratio
+ information was not available to the encoder.
+In this case it MAY be specified by the application via an external means, or
+ a default value of $1:1$ MAY be used.
+\item
+Read an 8-bit unsigned integer as \bitvar{CS}.
+This is a value from an enumerated list of the available color spaces, given in
+ Table~\ref{tab:colorspaces}.
+The `Undefined' value indicates that color space information was not available
+ to the encoder.
+It MAY be specified by the application via an external means.
+If a reserved value is given, a decoder MAY refuse to decode the stream.
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular*}{215pt}{cl@{\extracolsep{\fill}}c}\toprule
+Value    & Color Space                               \\\midrule
+$0$      & Undefined.                                \\
+$1$      & Rec.~470M (see Section~\ref{sec:470m}).   \\
+$2$      & Rec.~470BG (see Section~\ref{sec:470bg}). \\
+$3$      & Reserved.                                 \\
+$\vdots$ &                                           \\
+$255$    &                                           \\
+\bottomrule\end{tabular*}
+\end{center}
+\caption{Enumerated List of Color Spaces}
+\label{tab:colorspaces}
+\end{table}
+\item
+Read a 24-bit unsigned integer as \bitvar{NOMBR} signifying a rate in bits
+per second. Rates equal to or greater than $2^{24}-1$ bits per second are
+represented as $2^{24}-1$. 
+The \bitvar{NOMBR} field is used only as a hint.
+For pure VBR streams, this value may be considerably off.
+The field MAY be set to zero to indicate that the encoder did not care to
+speculate. 
+\item
+Read a 6-bit unsigned integer as \bitvar{QUAL}.
+This value is used to provide a hint as to the relative quality of the stream
+ when compared to others produced by the same encoder.
+Larger values indicate higher quality.
+This can be used, for example, to select among several streams containing the
+ same material encoded with different settings.
+\item
+Read a 5-bit unsigned integer as \bitvar{KFGSHIFT}.
+The \bitvar{KFGSHIFT} is used to partition the granule position associated with
+ each packet into two different parts.
+The frame number of the last key frame, starting from zero, is stored in the
+ upper $64-\bitvar{KFGSHIFT}$ bits, while the lower \bitvar{KFGSHIFT} bits
+ contain the number of frames since the last keyframe.
+Complete details on the granule position mapping are specified in Section~REF.
+\item
+Read a 2-bit unsigned integer as \bitvar{PF}.
+The \bitvar{PF} field contains a value from an enumerated list of the available
+ pixel formats, given in Table~\ref{tab:pixel-formats}.
+If the reserved value $1$ is given, stop.
+This stream is not decodable according to this specification.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular*}{215pt}{cl@{\extracolsep{\fill}}c}\toprule
+Value & Pixel Format             \\\midrule
+$0$   & 4:2:0 (see Section~\ref{sec:420}). \\
+$1$   & Reserved.                \\
+$2$   & 4:2:2 (see Section~\ref{sec:422}). \\
+$3$   & 4:4:4 (see Section~\ref{sec:444}). \\
+\bottomrule\end{tabular*}
+\end{center}
+\caption{Enumerated List of Pixel Formats}
+\label{tab:pixel-formats}
+\end{table}
+
+\item
+Read a 3-bit unsigned integer.
+These bits are reserved.
+If this value is not zero, then stop.
+This stream is not decodable according to this specification.
+\item
+Assign \bitvar{NSBS} a value according to \bitvar{PF}, as given by
+ Table~\ref{tab:nsbs-for-pf}.
+
+\begin{table}[bt]
+\begin{center}
+\begin{tabular}{cc}\toprule
+\bitvar{PF} & \bitvar{NSBS}                                     \\\midrule
+$0$         & $\begin{aligned}
+&((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)\\
+& +2*((\bitvar{FMBW}+3)//4)*((\bitvar{FMBH}+3)//4)
+\end{aligned}$                                                  \\\midrule
+$2$         & $\begin{aligned}
+&((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)\\
+& +2*((\bitvar{FMBW}+3)//4)*((\bitvar{FMBH}+1)//2)
+\end{aligned}$                                                  \\\midrule
+$3$         & $3*((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Number of Super Blocks for each Pixel Format}
+\label{tab:nsbs-for-pf}
+\end{table}
+
+\item
+Assign \bitvar{NBS} a value according to \bitvar{PF}, as given by
+ Table~\ref{tab:nbs-for-pf}.
+
+\begin{table}[tb]
+\begin{center}
+\begin{tabular}{cc}\toprule
+\bitvar{PF} & \bitvar{NBS}                     \\\midrule
+$0$         & $6*\bitvar{FMBW}*\bitvar{FMBH}$  \\\midrule
+$2$         & $8*\bitvar{FMBW}*\bitvar{FMBH}$  \\\midrule
+$3$         & $12*\bitvar{FMBW}*\bitvar{FMBH}$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Number of Blocks for each Pixel Format}
+\label{tab:nbs-for-pf}
+\end{table}
+
+\item
+Assign \bitvar{NMBS} the value $(\bitvar{FMBW}*\bitvar{FMBH})$.
+
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+VP3 does not correctly handle frame sizes that are not a multiple of 16.
+Thus, \bitvar{PICW} and \bitvar{PICH} should be set to the frame width and
+ height in pixels, respectively, and \bitvar{PICX} and \bitvar{PICY} should be
+ set to zero.
+VP3 headers do not specify a color space.
+VP3 only supports the 4:2:0 pixel format.
+
+\section{Comment Header}
+\label{sec:commentheader}
+
+The Theora comment header is the second of three header packets that begin a
+ Theora stream.
+It is meant for short text comments, not aribtrary metadata; arbitrary metadata
+ belongs in a separate logical stream that provides greater structure and
+ machine parseability.
+
+%r: I tried to morph this a little more in the direction of our 
+%   application space 
+The comment field is meant to be used much like someone jotting a quick note on
+ the label of a video.
+It should be a little information to remember the disc or tape by and explain it to
+ others; a short, to-the-point text note that can be more than a couple words,
+ but isn't going to be more than a short paragraph.
+The essentials, in other words, whatever they turn out to be, e.g.:
+
+%TODO: Example
+
+The comment header is stored as a logical list of eight-bit clean vectors; the
+ number of vectors is bounded at $2^{32}-1$ and the length of each vector is
+ limited to $2^{32}-1$ bytes.
+The vector length is encoded; the vector contents themselves are not null
+ terminated.
+In addition to the vector list, there is a single vector for a vendor name,
+ also eight-bit clean with a length encoded in 32 bits.
+%TODO: The 1.0 release of libtheora sets the vendor string to ...
+
+\subsection{Comment Length Decode}
+\label{sub:comment-len}
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | c | }
+ \hline
+ 4 byte length &
+ UTF-8 encoded string ...\\
+ \hline
+\end{tabular}
+\end{center}
+\caption{Length encoded string layout}
+\label{fig:comment-len}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LEN}  & Integer & 32 & No & A single 32-bit length value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN0} & Integer &  8 & No & The first octet of the string length. \\
+\locvar{LEN1} & Integer &  8 & No & The second octet of the string length. \\
+\locvar{LEN2} & Integer &  8 & No & The third octet of the string length. \\
+\locvar{LEN3} & Integer &  8 & No & The fourth octet of the string
+ length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A single comment vector is decoded as follows:
+
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as \locvar{LEN0}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN1}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN2}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN3}.
+\item
+Assign \bitvar{LEN} the value $(\locvar{LEN0}+(\locvar{LEN1}<<8)+
+ (\locvar{LEN2}<<16)+(\locvar{LEN3}<<24))$.
+This construction is used so that on platforms with 8-bit bytes, the memory
+ organization of the comment header is identical with that of Vorbis I,
+ allowing for common parsing code despite the different bit packing
+ conventions.
+\end{enumerate}
+
+\subsection{Comment Header Decode}
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | }
+  \hline
+  vendor string \\ \hline
+  number of comments \\ \hline
+  comment string \\ \hline
+  comment string \\ \hline
+  ... \\
+  \hline
+\end{tabular}
+\end{center}
+\caption{Comment Header Layout}
+\label{fig:commentheader}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{VENDOR}    & \multicolumn{3}{l}{String}       & The vendor string. \\
+\bitvar{NCOMMENTS} & Integer                & 32 & No & The number of user
+ comments. \\
+\bitvar{COMMENTS}  & \multicolumn{3}{l}{String Array} & A list of
+ \bitvar{NCOMMENTS} user comment values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci} & Integer & 32 & No & The index of the current user
+ comment. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The complete comment header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{81}, then stop.
+This packet is not the comment header.
+\item
+Decode the length of the vendor string using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Read \bitvar{LEN} 8-bit unsigned integers.
+\item
+Set the string \bitvar{VENDOR} to the contents of these octets.
+\item
+Decode the number of user comments using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Assign \bitvar{NCOMMENTS} the value stored in \bitvar{LEN}.
+\item
+For each consecutive value of \locvar{\ci} from $0$ to
+ $(\bitvar{NCOMMENTS}-1)$, inclusive:
+\begin{enumerate}
+\item
+Decode the length of the current user comment using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Read \bitvar{LEN} 8-bit unsigned integers.
+\item
+Set the string $\bitvar{COMMENTS}[\locvar{\ci}]$ to the contents of these
+ octets.
+\end{enumerate}
+\end{enumerate}
+
+The comment header comprises the entirety of the second header packet.
+Unlike the first header packet, it is not generally the only packet on the
+ second page and may span multiple pages.
+The length of the comment header packet is (practically) unbounded.
+The comment header packet is not optional; it must be present in the stream
+ even if it is logically empty.
+
+%TODO: \paragraph{VP3 Compatibility}
+
+\subsection{User Comment Format}
+
+The user comment vectors are structured similarly to a UNIX environment
+ variable.
+That is, comment fields consist of a field name and a corresponding value and
+ look like:
+\begin{center}
+\begin{tabular}{rcl}
+$\bitvar{COMMENTS}[0]$ & = & ``TITLE=the look of Theora" \\
+$\bitvar{COMMENTS}[1]$ & = & ``DIRECTOR=me"
+\end{tabular}
+\end{center}
+
+The field name is case-insensitive and MUST consist of ASCII characters
+ \hex{20} through \hex{7D}, \hex{3D} (`=') excluded.
+ASCII \hex{41} through \hex{5A} inclusive (characters `A'--`Z') are to be
+ considered equivalent to ASCII \hex{61} through \hex{7A} inclusive
+ (characters `a'--`z').
+An entirely empty field name---one that is zero characters long---is not
+ disallowed.
+
+The field name is immediately followed by ASCII \hex{3D} (`='); this equals
+ sign is used to terminate the field name.
+
+The data immediately after \hex{3D} until the end of the vector is the eight-bit
+ clean value of the field contents encoded as a UTF-8 string~\cite{rfc2044}.
+
+Field names MUST NOT be `internationalized'; this is a concession to
+ simplicity, not an attempt to exclude the majority of the world that doesn't
+ speak English.
+Applications MAY wish to present internationalized versions of the standard
+ field names listed below to the user, but they are not to be stored in the
+ bitstream.
+Field {\em contents}, however, use the UTF-8 character encoding to allow easy
+ representation of any language.
+
+Individual `vendors' MAY use non-standard field names within reason.
+The proper use of comment fields as human-readable notes has already been
+ explained.
+Abuse will be discouraged.
+
+There is no vendor-specific prefix to `non-standard' field names.
+Vendors SHOULD make some effort to avoid arbitrarily polluting the common
+ namespace.
+%"and other bodies"?
+%If you're going to be that vague, you might as well not say anything at all.
+Xiph.org and other bodies will generally collect and rationalize the more 
+ useful tags to help with standardization.
+
+Field names are not restricted to occur only once within a comment header.
+%TODO: Example
+
+\paragraph{Field Names}
+
+%r should this be an appendix?
+
+Below is a proposed, minimal list of standard field names with a description of
+ their intended use.
+No field names are mandatory; a comment header may contain one or more, all, or
+ none of the names in this list.
+
+\begin{description}
+\item{TITLE:} Video name.
+\item{ARTIST:} Filmmaker or other creator name.
+\item{VERSION:} Subtitle, remix info, or other text distinguishing
+ versions of a video.
+\item{DATE:} Date associated with the video. Implementations SHOULD attempt
+ to parse this field as an ISO 8601 date for machine interpretation and 
+ conversion.
+\item{LOCATION:} Location associated with the video. This is usually the
+ filming location for non-fiction works.
+\item{COPYRIGHT:} Copyright statement.
+\item{LICENSE:} Copyright and other licensing information. 
+ Implementations wishing to do automatic parsing of e.g
+ of distribution terms SHOULD look here for a URL uniquely defining
+ the license. If no instance of this field is present, or if no 
+ instance contains a parseable URL, and implementation MAY look
+ in the COPYRIGHT field for such a URL.
+\item{ORGANIZATION:} Studio name, Publisher, or other organization
+ involved in the creation of the video.
+
+\item{DIRECTOR:} Director or Filmmaker credit, similar to ARTIST.
+\item{PRODUCER:} Producer credit for the video.
+\item{COMPOSER:} Music credit for the video.
+\item{ACTOR:} Acting credit for the video.
+
+\item{TAG:} subject or category tag, keyword, or other content
+ classification labels. The value of each instance of this
+ field SHOULD be treated as a single label, with multiple
+ instances of the field for multiple tags. The value of
+ a single field SHOULD NOT be parsed into multiple tags
+ based on some internal delimeter.
+\item{DESCRIPTION:} General description, summary, or blurb.
+\end{description}
+
+\section{Setup Header}
+\label{sec:setupheader}
+
+The Theora setup header contains the limit values used to drive the loop
+ filter, the base matrices and scale values used to build the dequantization
+ tables, and the Huffman tables used to unpack the DCT tokens.
+Because the contents of this header are specific to Theora, no concessions have
+ been made to keep the fields octet-aligned for easy parsing.
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | }
+ \hline
+ common header block \\ \hline
+ loop filter table resolution \\ \hline
+ loop filter table \\ \hline
+ scale table resolution \\ \hline
+ AC scale table \\ \hline
+ DC scale table \\ \hline
+ number of base matricies \\ \hline
+ base quatization matricies \\ \hline
+ ... \\ \hline
+ quant range interpolation table \\ \hline
+ DCT token Huffman tables \\
+ \hline
+\end{tabular}
+\end{center}
+\caption{Setup Header structure}
+\label{fig:setupheader}
+\end{figure}
+
+\subsection{Loop Filter Limit Table Decode}
+\label{sub:loop-filter-limits}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS}    & \multicolumn{1}{p{40pt}}{Integer array} &
+                              7 & No & A 64-element array of loop filter limit
+ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\qi}    & Integer &  6 & No & The quantization index. \\
+\locvar{NBITS}  & Integer &  3 & No & The size of values being read in the
+ current table. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure decodes the table of loop filter limit values used to drive the
+ loop filter, which is described in Section~\ref{sub:loop-filter-limits}.
+It is decoded as follows:
+
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{NBITS}.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as $\bitvar{LFLIMS}[\locvar{\qi}]$.
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The loop filter limit values are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-loop-filter-limits}.
+
+\subsection{Quantization Parameters Decode}
+\label{sub:quant-params}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS}    & Integer & 10 & No & The number of base matrices. \\
+\bitvar{BMS}     & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}    & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS}  & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\qti}    & Integer &  1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\locvar{\qtj}    & Integer &  1 & No & A quantization type index. \\
+\locvar{\pli}    & Integer &  2 & No & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\locvar{\plj}    & Integer &  2 & No & A color plane index. \\
+\locvar{\qi}     & Integer &  6 & No & The quantization index. \\
+\locvar{\ci}     & Integer &  6 & No & The DCT coefficient index. \\
+\locvar{\bmi}    & Integer &  9 & No & The base matrix index. \\
+\locvar{\qri}    & Integer &  6 & No & The quant range index. \\
+\locvar{NBITS}   & Integer &  5 & No & The size of fields to read. \\
+\locvar{NEWQR}   & Integer &  1 & No & Flag that indicates a new set of quant
+ ranges will be defined. \\
+\locvar{RPQR}    & Integer &  1 & No & Flag that indicates the quant ranges to
+ copy will come from the same color plane. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The AC scale and DC scale values are defined in two simple tables with 64
+ values each, one for each \qi\ value.
+The same scale values are used for every quantization type and color plane.
+
+The base matrices for all quantization types and color planes are stored in a
+ single table.
+These are then referenced by index in several sets of \term{quant ranges}.
+The purpose of the quant ranges is to specify which base matrices are used for
+ which \qi\ values.
+
+A set of quant ranges is defined for each quantization type and color plane.
+To save space in the header, bit flags allow a set of quant ranges to be copied
+ from a previously defined set instead of being specified explicitly.
+Every set except the first one can be copied from the immediately preceding
+ set.
+Similarly, if the quantization type is not $0$, the set can be copied from the
+ set defined for the same color plane for the preceding quantization type.
+This formulation allows compact representation of, for example, the same 
+ set of quant ranges in both chroma channels, as is done in the original VP3,
+ or the same set of quant ranges in INTRA and INTER modes.
+
+Each quant range is defined by a size and two base matrix indices, one for each
+ end of the range.
+The base matrix for the end of one range is used as the start of the next
+ range, so that for $n$ ranges, $n+1$ base matrices are specified.
+The base matrices for the \qi\ values between the two endpoints of the range
+ are generated by linear interpolation.
+
+%TODO: figure
+
+The location of the endpoints of each range is encoded by their size.
+The \qi\ value for the left end-point is the sum of the sizes of all preceding
+ ranges, and the \qi\ value for the right end-point adds the size of the
+ current range.
+Thus the sum of the sizes of all the ranges MUST be 63, so that the last range
+ falls on the last possible \qi\ value.
+
+The complete set of quantization parameters are decoded as follows:
+
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer.
+Assign \locvar{NBITS} the value read, plus one.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as
+ $\bitvar{ACSCALE}[\locvar{\qi}]$.
+\end{enumerate}
+\item
+Read a 4-bit unsigned integer.
+Assign \locvar{NBITS} the value read, plus one.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as
+ $\bitvar{DCSCALE}[\locvar{\qi}]$.
+\end{enumerate}
+\item
+Read a 9-bit unsigned integer.
+Assign \bitvar{NBMS} the value decoded, plus one.
+\bitvar{NBMS} MUST be no greater than 384.
+\item
+For each consecutive value of \locvar{\bmi} from $0$ to $(\bitvar{NBMS}-1)$,
+ inclusive:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\ci} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as $\bitvar{BMS}[\locvar{\bmi}][\locvar{\ci}]$.
+\end{enumerate}
+\end{enumerate}
+\item
+For each consecutive value of \locvar{\qti} from $0$ to $1$, inclusive:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\pli} from $0$ to $2$, inclusive:
+\begin{enumerate}
+\item
+If $\locvar{\qti}>0$ or $\locvar{\pli}>0$, read a 1-bit unsigned integer as
+ \locvar{NEWQR}.
+\item
+Else, assign \locvar{NEWQR} the value one.
+\item
+If \locvar{NEWQR} is zero, then we are copying a previously defined set of
+ quant ranges.
+In that case:
+\begin{enumerate}
+\item
+If $\locvar{\qti}>0$, read a 1-bit unsigned integer as \locvar{RPQR}.
+\item
+Else, assign \locvar{RPQR} the value zero.
+\item
+If \locvar{RPQR} is one, assign \locvar{\qtj} the value $(\locvar{\qti}-1)$
+ and assign \locvar{\plj} the value \locvar{\pli}.
+This selects the set of quant ranges defined for the same color plane as this
+ one, but for the previous quantization type.
+\item
+Else assign \locvar{\qtj} the value $(3*\locvar{\qti}+\locvar{\pli}-1)//3$ and
+ assign \locvar{\plj} the value $(\locvar{\pli}+2)\%3$.
+This selects the most recent set of quant ranges defined.
+\item
+Assign $\bitvar{NQRS}[\locvar{\qti}][\locvar{\pli}]$ the value
+ $\bitvar{NQRS}[\locvar{\qtj}][\locvar{\plj}]$.
+\item
+Assign $\bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}]$ the values in 
+ $\bitvar{QRSIZES}[\locvar{\qtj}][\locvar{\plj}]$.
+\item
+Assign $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}]$ the values in
+ $\bitvar{QRBMIS}[\locvar{\qtj}][\locvar{\plj}]$.
+\end{enumerate}
+\item
+Else, \locvar{NEWQR} is one, which indicates that we are defining a new set of
+ quant ranges.
+In that case:
+\begin{enumerate}
+\item
+Assign $\locvar{\qri}$ the value zero.
+\item
+Assign $\locvar{\qi}$ the value zero.
+\item
+Read an $\ilog(\bitvar{NBMS}-1)$-bit unsigned integer as\\
+ $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+If this is greater than or equal to \bitvar{NBMS}, stop.
+The stream is undecodable.
+\item
+\label{step:qr-loop}
+Read an $\ilog(62-\locvar{\qi})$-bit unsigned integer.
+Assign\\ $\bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$ the value
+ read, plus one.
+\item
+Assign \locvar{\qi} the value $\locvar{\qi}+
+ \bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+\item
+Assign \locvar{\qri} the value $\locvar{\qri}+1$.
+\item
+Read an $\ilog(\bitvar{NBMS}-1)$-bit unsigned integer as\\
+ $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+\item
+If \locvar{\qi} is less than 63, go back to step~\ref{step:qr-loop}.
+\item
+If \locvar{\qi} is greater than 63, stop.
+The stream is undecodable.
+\item
+Assign $\bitvar{NQRS}[\locvar{\qti}][\locvar{\pli}]$ the value \locvar{\qri}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The quantization parameters are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-quant-params}.
+
+\subsection{Computing a Quantization Matrix}
+\label{sub:quant-mat}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{BMS}     & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}    & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS}  & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{\qti}    & Integer &  1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\bitvar{\pli}    & Integer &  2 & No & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\bitvar{\qi}     & Integer &  6 & No & The quantization index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{QMAT} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci}     & Integer &  6 & No & The DCT coefficient index. \\
+\locvar{\bmi}    & Integer &  9 & No & The base matrix index. \\
+\locvar{\bmj}    & Integer &  9 & No & The base matrix index. \\
+\locvar{\qri}    & Integer &  6 & No & The quant range index. \\
+\locvar{QISTART} & Integer &  6 & No & The left end-point of the \qi\ range. \\
+\locvar{QIEND  } & Integer &  6 & No & The right end-point of the \qi\ range. \\
+\locvar{BM}      & \multicolumn{1}{p{40pt}}{Integer array} &
+                              8 & No & A 64-element array containing the
+ interpolated base matrix. \\
+\locvar{QMIN}    & Integer & 16 & No & The minimum quantization value allowed
+ for the current coefficient. \\
+\locvar{QSCALE}  & Integer & 16 & No & The current scale value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The following procedure can be used to generate a single quantization matrix
+ for a given quantization type, color plane, and \qi\ value, given the
+ quantization parameters decoded in Section~\ref{sub:quant-params}.
+
+Note that the product of the scale value and the base matrix value is in units
+ of $100$ths of a pixel value, and thus is divided by $100$ to return it to
+ units of a single pixel value.
+This value is then scaled by four, to match the scaling of the DCT output,
+ which is also a factor of four larger than the orthonormal version of the
+ transform.
+
+\begin{enumerate}
+\item
+Assign \locvar{\qri} the index of a quant range such that
+\begin{displaymath}
+\bitvar{\qi} \ge \sum_{\qrj=0}^{\locvar{\qri}-1}
+ \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj],
+\end{displaymath}
+ and
+\begin{displaymath}
+\bitvar{\qi} \le \sum_{\qrj=0}^{\locvar{\qri}}
+ \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj],
+\end{displaymath}
+ where summation from $0$ to $-1$ is defined to be zero.
+If there is more than one such value of $\locvar{\qri}$, i.e., if \bitvar{\qi}
+ lies on the boundary between two quant ranges, then the output will be the
+ same regardless of which one is chosen.
+\item
+Assign \locvar{QISTART} the value
+\begin{displaymath}
+\sum_{\qrj=0}^{\qri-1} \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj].
+\end{displaymath}
+\item
+Assign \locvar{QIEND} the value
+\begin{displaymath}
+\sum_{\qrj=0}^{\qri} \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj].
+\end{displaymath}
+\item
+Assign \locvar{\bmi} the value
+ $\bitvar{QRBMIS}[\bitvar{\qti}][\bitvar{\pli}][\qri]$.
+\item
+Assign \locvar{\bmj} the value
+ $\bitvar{QRBMIS}[\bitvar{\qti}][\bitvar{\pli}][\qri+1]$.
+\item
+For each consecutive value of \locvar{\ci} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Assign $\locvar{BM}[\locvar{\ci}]$ the value
+\begin{displaymath}
+\begin{split}
+(&2*(\locvar{QIEND}-\bitvar{\qi})*\bitvar{BMS}[\locvar{\bmi}][\locvar{\ci}]\\
+ &+2*(\bitvar{\qi}-
+   \locvar{QISTART})*\bitvar{BMS}[\locvar{\bmj}][\locvar{\ci}]\\
+ &+\bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\locvar{\qri}])//
+ (2*\bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\locvar{\qri}])
+\end{split}
+\end{displaymath}
+\item
+Assign \locvar{QMIN} the value given by Table~\ref{tab:qmin} according to
+ \bitvar{\qti} and \locvar{\ci}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{clr}\toprule
+Coefficient      & \multicolumn{1}{c}{\bitvar{\qti}}
+                               & \locvar{QMIN} \\\midrule
+$\locvar{\ci}=0$ & $0$ (Intra) & $16$          \\
+$\locvar{\ci}>0$ & $0$ (Intra) & $8$           \\
+$\locvar{\ci}=0$ & $1$ (Inter) & $32$          \\
+$\locvar{\ci}>0$ & $1$ (Inter) & $16$          \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Minimum Quantization Values}
+\label{tab:qmin}
+\end{table}
+
+\item
+If \locvar{\ci} equals zero, assign $\locvar{QSCALE}$ the value
+ $\bitvar{DCSCALE}[\bitvar{\qi}]$.
+\item
+Else, assign $\locvar{QSCALE}$ the value
+ $\bitvar{ACSCALE}[\bitvar{\qi}]$.
+\item
+Assign $\bitvar{QMAT}[\locvar{\ci}]$ the value
+\begin{displaymath}
+\max(\locvar{QMIN},
+ \min((\locvar{QSCALE}*\locvar{BM}[\locvar{\ci}]//100)*4,4096)).
+\end{displaymath}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{DCT Token Huffman Tables}
+\label{sub:huffman-tables}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+                                     & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{HBITS}   & Bit string & 32 & No & A string of up to 32 bits. \\
+\locvar{TOKEN}   & Integer    &  5 & No & A single DCT token value. \\
+\locvar{ISLEAF}  & Integer    &  1 & No & Flag that indicates if the current
+ node of the tree being decoded is a leaf node. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The Huffman tables used to decode DCT tokens are stored in the setup header in
+ the form of a binary tree.
+This enforces the requirements that the code be full---so that any sequence of
+ bits will produce a valid sequence of tokens---and that the code be
+ prefix-free so that there is no ambiguity when decoding.
+
+One more restriction is placed on the tables that is not explicitly enforced by
+ the bitstream syntax, but nevertheless must be obeyed by compliant encoders.
+There must be no more than 32 entries in a single table.
+Note that this restriction along with the fullness requirement limit the
+ maximum size of a single Huffman code to 32 bits.
+It is probably a good idea to enforce this latter consequence explicitly when
+ implementing the decoding procedure as a recursive algorithm, so as to prevent
+ a possible stack overflow given an invalid bitstream.
+
+Although there are 32 different DCT tokens, and thus a normal table will have
+ exactly 32 entries, this is not explicitly required.
+It is allowable to use a Huffman code that omits some---but not all---of the
+ possible token values.
+It is also allowable, if not particularly useful, to specify multiple codes for
+ the same token value in a single table.
+Note also that token values may appear in the tree in any order.
+In particular, it is not safe to assume that token value zero (which ends a
+ single block), has a Huffman code of all zeros.
+
+The tree is decoded as follows:
+
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\hti} from $0$ to $79$, inclusive:
+\begin{enumerate}
+\item
+Set \locvar{HBITS} to the empty string.
+\item
+\label{step:huff-tree-loop}
+If \locvar{HBITS} is longer than 32 bits in length, stop.
+The stream is undecodable.
+\item
+Read a 1-bit unsigned integer as \locvar{ISLEAF}.
+\item
+If \locvar{ISLEAF} is one:
+\begin{enumerate}
+\item
+If the number of entries in table $\bitvar{HTS}[\locvar{\hti}]$ is already 32,
+ stop.
+The stream is undecodable.
+\item
+Read a 5-bit unsigned integer as \locvar{TOKEN}.
+\item
+Add the pair $(\locvar{HBITS},\locvar{TOKEN})$ to Huffman table
+ $\bitvar{HTS}[\locvar{\hti}]$.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Add a `0' to the end of \locvar{HBITS}.
+\item
+Decode the `0' sub-tree using this procedure, starting from
+ step~\ref{step:huff-tree-loop}.
+\item
+Remove the `0' from the end of \locvar{HBITS} and add a `1' to the end of
+ \locvar{HBITS}.
+\item
+Decode the `1' sub-tree using this procedure, starting from
+ step~\ref{step:huff-tree-loop}.
+\item
+Remove the `1' from the end of \locvar{HBITS}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The DCT token Huffman tables are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-huffman-tables}.
+
+\subsection{Setup Header Decode}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS}  & \multicolumn{1}{p{40pt}}{Integer array} &
+                              7 & No & A 64-element array of loop filter limit
+ values. \\
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS}    & Integer & 10 & No & The number of base matrices. \\
+\bitvar{BMS}     & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}    & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values will be used. \\
+\bitvar{QRBMIS}  & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values will be used. \\
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+                                     & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+The complete setup header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{82}, then stop.
+This packet is not the setup header.
+\item
+Decode the loop filter limit value table using the procedure given in
+ Section~\ref{sub:loop-filter-limits} into \bitvar{LFLIMS}.
+\item
+Decode the quantization parameters using the procedure given in
+ Section~\ref{sub:quant-params}.
+The results are stored in \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{NBMS},
+ \bitvar{BMS}, \bitvar{NQRS}, \bitvar{QRSIZES}, and \bitvar{QRBMIS}.
+\item
+Decode the DCT token Huffman tables using the procedure given in
+ Section~\ref{sub:huffman-tables} into \bitvar{HTS}.
+\end{enumerate}
+
+\chapter{Frame Decode}
+
+This section describes the complete procedure necessary to decode a single
+ frame.
+This begins with the frame header, followed by coded block flags, macro block
+ modes, motion vectors, block-level \qi\ values, and finally the DCT residual
+ tokens, which are used to reconstruct the frame.
+
+\section{Frame Header Decode}
+\label{sub:frame-header}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE}   & Integer &  1 & No & The frame type. \\
+\bitvar{NQIS}    & Integer &  2 & No & The number of \qi\ values. \\
+\bitvar{QIS}     & \multicolumn{1}{p{40pt}}{Integer array} &
+                             6 & No & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MOREQIS} & Integer &  1 & No & A flag indicating there are more
+ \qi\ values to be decoded. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The frame header selects which type of frame is being decoded, intra or inter,
+ and contains the list of \qi\ values that will be used in this frame.
+The first \qi\ value will be used for {\em all} DC coefficients in all blocks.
+This is done to ensure that DC prediction, which is done in the quantized
+ domain, works as expected.
+The AC coefficients, however, can be dequantized using any \qi\ value on the
+ list, selected on a block-by-block basis.
+
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer.
+If the value read is not zero, stop.
+This is not a data packet.
+\item
+Read a 1-bit unsigned integer as \bitvar{FTYPE}.
+This is the type of frame being decoded, as given in
+ Table~\ref{tab:frame-type}.
+If this is the first frame being decoded, this MUST be zero.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+\bitvar{FTYPE} & Frame Type  \\\midrule
+$0$            & Intra frame \\
+$1$            & Inter frame \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Frame Type Values}
+\label{tab:frame-type}
+\end{table}
+
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[0]$.
+\item
+Read a 1-bit unsigned integer as \locvar{MOREQIS}.
+\item
+If \locvar{MOREQIS} is zero, set \bitvar{NQIS} to 1.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[1]$.
+\item
+Read a 1-bit unsigned integer as \locvar{MOREQIS}.
+\item
+If \locvar{MOREQIS} is zero, set \bitvar{NQIS} to 2.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[2]$.
+\item
+Set \bitvar{NQIS} to 3.
+\end{enumerate}
+\end{enumerate}
+\item
+If \bitvar{FTYPE} is 0, read a 3-bit unsigned integer.
+These bits are reserved.
+If this value is not zero, stop.
+This frame is not decodable according to this specification.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The precise format of the frame header is substantially different in Theora
+ than in VP3.
+The original VP3 format includes a larger number of unused, reserved bits that
+ are required to be zero.
+The original VP3 frame header also can contain only a single \qi\ value,
+ because VP3 does not support block-level \qi\ values and uses the same
+ \qi\ value for all the coefficients in a frame.
+
+\section{Run-Length Encoded Bit Strings}
+
+Two variations of run-length encoding are used to store sequences of bits for
+ the block coded flags and the block-level \qi\ values.
+The procedures to decode these bit sequences are specified in the following two
+ sections.
+
+\subsection{Long-Run Bit String Decode}
+\label{sub:long-run}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBITS}   & Integer & 36 & No & The number of bits to decode. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BITS}    & Bit string &    &    & The decoded bits. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN}    & Integer & 36 & No & The number of bits decoded so far. \\
+\locvar{BIT}    & Integer &  1 & No & The value associated with the current
+ run. \\
+\locvar{RLEN}   & Integer & 13 & No & The length of the current run. \\
+\locvar{RBITS}  & Integer &  4 & No & The number of extra bits needed to
+ decode the run length. \\
+\locvar{RSTART} & Integer &  6 & No & The start of the possible run-length
+ values for a given Huffman code. \\
+\locvar{ROFFS}  & Integer & 12 & No & The offset from \locvar{RSTART} of the
+ run-length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+There is no practical limit to the number of consecutive 0's and 1's that can
+ be decoded with this procedure.
+In reality, the run length is limited by the number of blocks in a single
+ frame, because more will never be requested.
+A separate procedure described in Section~\ref{sub:short-run} is used when
+ there is a known limit on the maximum size of the runs.
+
+For the first run, a single bit value is read, and then a Huffman-coded
+ representation of a run length is decoded, and that many copies of the bit
+ value are appended to the bit string.
+For each consecutive run, the value of the bit is toggled instead of being read
+ from the bitstream.
+
+The only exception is if the length of the previous run was 4129, the maximum
+ possible length encodable by the Huffman-coded representation.
+In this case another bit value is read from the stream, to allow for
+ consecutive runs of 0's or 1's longer than this maximum.
+
+Note that in both cases---for the first run and after a run of length 4129---if
+ no more bits are needed, then no bit value is read.
+
+The complete decoding procedure is as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LEN} the value 0.
+\item
+Assign \bitvar{BITS} the empty string.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+\label{step:long-run-loop}
+Read a bit at a time until one of the Huffman codes given in
+ Table~\ref{tab:long-run} is recognized.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lrrl}\toprule
+Huffman Code & \locvar{RSTART} & \locvar{RBITS} & Run Lengths     \\\midrule
+\bin{0}      & $1$             & $0$            & $1$             \\
+\bin{10}     & $2$             & $1$            & $2\ldots 3$     \\
+\bin{110}    & $4$             & $1$            & $4\ldots 5$     \\
+\bin{1110}   & $6$             & $2$            & $6\ldots 9$     \\
+\bin{11110}  & $10$            & $3$            & $10\ldots 17$   \\
+\bin{111110} & $18$            & $4$            & $18\ldots 33$   \\
+\bin{111111} & $34$            & $12$           & $34\ldots 4129$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Long Run Lengths}
+\label{tab:long-run}
+\end{table}
+
+\item
+Assign \locvar{RSTART} and \locvar{RBITS} the values given in
+ Table~\ref{tab:long-run} according to the Huffman code read.
+\item
+Read an \locvar{RBITS}-bit unsigned integer as \locvar{ROFFS}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RSTART}+\locvar{ROFFS})$.
+\item
+Append \locvar{RLEN} copies of \locvar{BIT} to \bitvar{BITS}.
+\item
+Add \locvar{RLEN} to the value \locvar{LEN}.
+\locvar{LEN} MUST be less than or equal to \bitvar{NBITS}.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+If \locvar{RLEN} equals 4129, read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+Otherwise, assign \locvar{BIT} the value $(1-\locvar{BIT})$.
+\item
+Continue decoding runs from step~\ref{step:long-run-loop}.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+VP3 does not read a new bit value after decoding a run length of 4129.
+This limits the maximum number of consecutive 0's or 1's to 4129 in
+ VP3-compatible streams.
+For reasonable video sizes of $1920\times 1080$ or less in 4:2:0 format---the
+ only pixel format VP3 supports---this does not pose any problems because runs
+ longer than 4129 are not needed.
+
+\subsection{Short-Run Bit String Decode}
+\label{sub:short-run}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBITS}   & Integer & 36 & No & The number of bits to decode. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BITS}    & Bit string &    &    & The decoded bits. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN}    & Integer & 36 & No & The number of bits decoded so far. \\
+\locvar{BIT}    & Integer &  1 & No & The value associated with the current
+ run. \\
+\locvar{RLEN}   & Integer & 13 & No & The length of the current run. \\
+\locvar{RBITS}  & Integer &  4 & No & The number of extra bits needed to
+ decode the run length. \\
+\locvar{RSTART} & Integer &  6 & No & The start of the possible run-length
+ values for a given Huffman code. \\
+\locvar{ROFFS}  & Integer & 12 & No & The offset from \locvar{RSTART} of the
+ run-length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure is similar to the procedure outlined in
+ Section~\ref{sub:long-run}, except that the maximum number of consecutive 0's
+ or 1's is limited to 30.
+This is the maximum run length needed when encoding a bit for each of the 16
+ blocks in a super block when it is known that not all the bits in a super
+ block are the same.
+
+The complete decoding procedure is as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LEN} the value 0.
+\item
+Assign \bitvar{BITS} the empty string.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+\label{step:short-run-loop}
+Read a bit at a time until one of the Huffman codes given in
+ Table~\ref{tab:short-run} is recognized.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lrrl}\toprule
+Huffman Code & \locvar{RSTART} & \locvar{RBITS} & Run Lengths   \\\midrule
+\bin{0}      & $1$             & $1$            & $1\ldots 2$   \\
+\bin{10}     & $3$             & $1$            & $3\ldots 4$   \\
+\bin{110}    & $5$             & $1$            & $5\ldots 6$   \\
+\bin{1110}   & $7$             & $2$            & $7\ldots 10$  \\
+\bin{11110}  & $11$            & $2$            & $11\ldots 14$ \\
+\bin{11111}  & $15$            & $4$            & $15\ldots 30$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Short Run Lengths}
+\label{tab:short-run}
+\end{table}
+
+\item
+Assign \locvar{RSTART} and \locvar{RBITS} the values given in
+ Table~\ref{tab:short-run} according to the Huffman code read.
+\item
+Read an \locvar{RBITS}-bit unsigned integer as \locvar{ROFFS}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RSTART}+\locvar{ROFFS})$.
+\item
+Append \locvar{RLEN} copies of \locvar{BIT} to \bitvar{BITS}.
+\item
+Add \locvar{RLEN} to the value \locvar{LEN}.
+\locvar{LEN} MUST be less than or equal to \bitvar{NBITS}.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Assign \locvar{BIT} the value $(1-\locvar{BIT})$.
+\item
+Continue decoding runs from step~\ref{step:short-run-loop}.
+\end{enumerate}
+
+\section{Coded Block Flags Decode}
+\label{sub:coded-blocks}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE}   & Integer &  1 & No & The frame type. \\
+\bitvar{NSBS}    & Integer & 32 & No & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS}     & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NBITS}    & Integer & 36 & No & The length of a bit string to decode. \\
+\locvar{BITS}     & Bit string & &    & A decoded set of flags. \\
+\locvar{SBPCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No & An \bitvar{NSBS}-element array of flags
+ indicating whether or not each super block is partially coded. \\
+\locvar{SBFCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No & An \bitvar{NSBS}-element array of flags
+ indicating whether or not each non-partially coded super block is fully
+ coded. \\
+\locvar{\sbi}     & Integer & 32 & No & The index of the current super
+ block. \\
+\locvar{\bi}      & Integer & 36 & No & The index of the current block in coded
+ order. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure determines which blocks are coded in a given frame.
+In an intra frame, it marks all blocks coded.
+In an inter frame, however, any or all of the blocks may remain uncoded.
+The output is a list of bit flags, one for each block, marking it coded or not
+ coded.
+
+It is important to note that flags are still decoded for any blocks which lie
+ entirely outside the picture region, even though they are not displayed.
+Encoders MAY choose to code such blocks.
+Decoders MUST faithfully reconstruct such blocks, because their contents can be
+ used for predictors in future frames.
+Flags are \textit{not} decoded for portions of a super block which lie outside
+ the full frame, as there are no blocks in those regions.
+
+The complete procedure is as follows:
+
+\begin{enumerate}
+\item
+If \bitvar{FTYPE} is zero (intra frame):
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\locvar{NBS}-1)$, assign
+ $\bitvar{BCODED}[\locvar{\bi}]$ the value one.
+\end{enumerate}
+\item
+Otherwise (inter frame):
+\begin{enumerate}
+\item
+Assign \locvar{NBITS} the value \bitvar{NSBS}.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of partially coded super blocks.
+\item
+For each consecutive value of \locvar{\sbi} from 0 to $(\locvar{NSBS}-1)$,
+ remove the bit at the head of the string \locvar{BITS} and assign it to
+ $\locvar{SBPCODED}[\locvar{\sbi}]$.
+\item
+Assign \locvar{NBITS} the total number of super blocks such that \\
+ $\locvar{SBPCODED}[\locvar{\sbi}]$ equals zero.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of fully coded super blocks.
+\item
+For each consecutive value of \locvar{\sbi} from 0 to $(\locvar{NSBS}-1)$ such
+ that $\locvar{SBPCODED}[\locvar{\sbi}]$ equals zero, remove the bit at the
+ head of the string \locvar{BITS} and assign it to
+ $\locvar{SBFCODED}[\locvar{\sbi}]$.
+\item
+Assign \locvar{NBITS} the number of blocks contained in super blocks where
+ $\locvar{SBPCODED}[\locvar{\sbi}]$ equals one.
+Note that this might {\em not} be equal to 16 times the number of partially
+ coded super blocks, since super blocks which overlap the edge of the frame
+ will have fewer than 16 blocks in them.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:short-run}.
+\item
+For each block in coded order---indexed by \locvar{\bi}:
+\begin{enumerate}
+\item
+Assign \locvar{\sbi} the index of the super block containing block
+ \locvar{\bi}.
+\item
+If $\locvar{SBPCODED}[\locvar{\sbi}]$ is zero, assign
+ $\bitvar{BCODED}[\locvar{\bi}]$ the value $\locvar{SBFCODED}[\locvar{\sbi}]$.
+\item
+Otherwise, remove the bit at the head of the string \locvar{BITS} and assign it
+ to $\bitvar{BCODED}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Macro Block Coding Modes}
+\label{sub:mb-modes}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE}    & Integer &  1 & No & The frame type. \\
+\bitvar{NMBS}     & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{NBS}      & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              3 & No & An \bitvar{NMBS}-element array of coding
+ modes for each macro block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MSCHEME}   & Integer &  3 & No & The mode coding scheme. \\
+\locvar{MALPHABET} & \multicolumn{1}{p{40pt}}{Integer array}
+                             &  3 & No & The list of modes corresponding to each
+ Huffman code. \\
+\locvar{\mbi}      & Integer & 32 & No & The index of the current macro
+ block. \\
+\locvar{\bi}       & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\mi}       & Integer &  3 & No & The index of a Huffman code from
+ Table~\ref{tab:mode-codes}, starting from $0$. \\
+\bottomrule\end{tabularx}
+\medskip
+
+In an intra frame, every macro block marked as coded in INTRA mode.
+In an inter frame, however, a macro block can be coded in one of eight coding
+ modes, given in Table~\ref{tab:coding-modes}.
+All of the blocks in all color planes contained in a macro block will be
+ assigned the coding mode of that macro block.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Index & Coding Mode \\\midrule
+$0$   & INTER\_NOMV         \\
+$1$   & INTRA               \\
+$2$   & INTER\_MV           \\
+$3$   & INTER\_MV\_LAST     \\
+$4$   & INTER\_MV\_LAST2    \\
+$5$   & INTER\_GOLDEN\_NOMV \\
+$6$   & INTER\_GOLDEN\_MV   \\
+$7$   & INTER\_MV\_FOUR     \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Macro Block Coding Modes}
+\label{tab:coding-modes}
+\end{table}
+
+An important thing to note is that a coding mode is only stored in the
+ bitstream for a macro block if it has at least one {\em luma} block coded.
+A macro block that contains coded blocks in the chroma planes, but not in the
+ luma plane, MUST be coded in INTER\_NOMV mode.
+Thus, no coding mode needs to be decoded for such a macro block.
+
+Coding modes are encoded using one of eight different schemes.
+Schemes 0 through 6 use the same simple Huffman code to represent the mode
+ numbers, as given in Table~\ref{tab:mode-codes}.
+The difference in the schemes is the mode number assigned to each code.
+Scheme 0 uses an assignment specified in the bitstream, while schemes 1--6 use
+ a fixed assignment, also given in Table~\ref{tab:mode-codes}.
+Scheme 7 simply codes each mode directly in the bitstream using three bits.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lccccccc}\toprule
+Scheme        & $1$ & $2$ & $3$ & $4$ & $5$ & $6$ & $7$ \\\cmidrule{2-7}
+Huffman Code  & \multicolumn{6}{c}{Coding Mode}   & \locvar{\mi} \\\midrule
+\bin{0}       & $3$ & $3$ & $3$ & $3$ & $0$ & $0$ & $0$ \\
+\bin{10}      & $4$ & $4$ & $2$ & $2$ & $3$ & $5$ & $1$ \\
+\bin{110}     & $2$ & $0$ & $4$ & $0$ & $4$ & $3$ & $2$ \\
+\bin{1110}    & $0$ & $2$ & $0$ & $4$ & $2$ & $4$ & $3$ \\
+\bin{11110}   & $1$ & $1$ & $1$ & $1$ & $1$ & $2$ & $4$ \\
+\bin{111110}  & $5$ & $5$ & $5$ & $5$ & $5$ & $1$ & $5$ \\
+\bin{1111110} & $6$ & $6$ & $6$ & $6$ & $6$ & $6$ & $6$ \\
+\bin{1111111} & $7$ & $7$ & $7$ & $7$ & $7$ & $7$ & $7$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Macro Block Mode Schemes}
+\label{tab:mode-codes}
+\end{table}
+
+\begin{enumerate}
+\item
+If \bitvar{FTYPE} is 0 (intra frame):
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\mbi} from 0 to $(\bitvar{NMBS}-1)$,
+ inclusive, assign $\bitvar{MBMODES}[\mbi]$ the value 1 (INTRA).
+\end{enumerate}
+\item
+Otherwise (inter frame):
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{MSCHEME}.
+\item
+If \locvar{MSCHEME} is 0:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{MODE} from 0 to 7, inclusive:
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{\mi}.
+\item
+Assign $\locvar{MALPHABET}[\mi]$ the value \locvar{MODE}.
+\end{enumerate}
+\end{enumerate}
+\item
+Otherwise, if \locvar{MSCHEME} is not 7, assign the entries of
+ \locvar{MALPHABET} the values in the corresponding column of
+ Table~\ref{tab:mode-codes}.
+\item
+For each consecutive macro block in coded order (cf.
+ Section~\ref{sec:mbs})---indexed by \locvar{\mbi}:
+\begin{enumerate}
+\item
+If a block \locvar{\bi} in the luma plane of macro block \locvar{\mbi} exists
+ such that $\bitvar{BCODED}[\locvar{\bi}]$ is 1:
+\begin{enumerate}
+\item
+If \locvar{MSCHEME} is not 7, read one bit at a time until one of the Huffman
+ codes in Table~\ref{tab:mode-codes} is recognized, and assign
+ $\bitvar{MBMODES}[\locvar{\mbi}]$ the value
+ $\locvar{MALPHABET}[\locvar{\mi}]$, where \locvar{\mi} is the index of the
+ Huffman code decoded.
+\item
+Otherwise, read a 3-bit unsigned integer as $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\end{enumerate}
+\item
+Otherwise, if no luma-plane blocks in the macro block are coded, assign
+ $\bitvar{MBMODES}[\locvar{\mbi}]$ the value 0 (INTER\_NOMV).
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Motion Vectors}
+
+In an intra frame, no motion vectors are used, and so motion vector decoding is
+ skipped.
+In an inter frame, however, many of the inter coding modes require a motion
+ vector in order to specify an offset into the reference frame from which to
+ predict a block.
+These procedures assigns such a motion vector to every block.
+
+\subsection{Motion Vector Decode}
+\label{sub:mv-decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVMODE}   & Integer &  1 & No & The motion vector decoding method. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVX}      & Integer &  6 & Yes & The X component of the motion
+ vector. \\
+\bitvar{MVY}      & Integer &  6 & Yes & The Y component of the motion
+ vector. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MVSIGN}   & Integer &  1 & No & The sign of the motion vector component
+ just decoded. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The individual components of a motion vector can be coded using one of two
+ methods.
+The first uses a variable length Huffman code, given in
+ Table~\ref{tab:mv-huff-codes}.
+The second encodes the magnitude of the component directly in 5 bits, and the
+ sign in one bit.
+Note that in this case there are two representations for the value zero.
+For compatibility with VP3, a sign bit is read even if the magnitude read is
+ zero.
+One scheme is chosen and used for the entire frame.
+
+Each component can take on integer values from $-31\ldots 31$, inclusive, at
+ half-pixel resolution, i.e. $-15.5\ldots 15.5$ pixels in the luma plane.
+For each subsampled axis in the chroma planes, the corresponding motion vector
+ component is interpreted as being at quarter-pixel resolution, i.e.
+ $-7.75\ldots 7.75$ pixels.
+The precise details of how these vectors are used to compute predictors for
+ each block are described in Section~\ref{sec:predictors}.
+
+\begin{table}[ht]
+\begin{center}
+\begin{tabular}{lrlr}\toprule
+Huffman Code   & Value & Huffman Code   & Value \\\midrule
+\bin{000}      & $0$   \\
+\bin{001}      & $1$   & \bin{010}      & $-1$  \\
+\bin{0110}     & $2$   & \bin{0111}     & $-2$  \\
+\bin{1000}     & $3$   & \bin{1001}     & $-3$  \\
+\bin{101000}   & $4$   & \bin{101001}   & $-4$  \\
+\bin{101010}   & $5$   & \bin{101011}   & $-5$  \\
+\bin{101100}   & $6$   & \bin{101101}   & $-6$  \\
+\bin{101110}   & $7$   & \bin{101111}   & $-7$  \\
+\bin{1100000}  & $8$   & \bin{1100001}  & $-8$  \\
+\bin{1100010}  & $9$   & \bin{1100011}  & $-9$  \\
+\bin{1100100}  & $10$  & \bin{1100101}  & $-10$ \\
+\bin{1100110}  & $11$  & \bin{1100111}  & $-11$ \\
+\bin{1101000}  & $12$  & \bin{1101001}  & $-12$ \\
+\bin{1101010}  & $13$  & \bin{1101011}  & $-13$ \\
+\bin{1101100}  & $14$  & \bin{1101101}  & $-14$ \\
+\bin{1101110}  & $15$  & \bin{1101111}  & $-15$ \\
+\bin{11100000} & $16$  & \bin{11100001} & $-16$ \\
+\bin{11100010} & $17$  & \bin{11100011} & $-17$ \\
+\bin{11100100} & $18$  & \bin{11100101} & $-18$ \\
+\bin{11100110} & $19$  & \bin{11100111} & $-19$ \\
+\bin{11101000} & $20$  & \bin{11101001} & $-20$ \\
+\bin{11101010} & $21$  & \bin{11101011} & $-21$ \\
+\bin{11101100} & $22$  & \bin{11101101} & $-22$ \\
+\bin{11101110} & $23$  & \bin{11101111} & $-23$ \\
+\bin{11110000} & $24$  & \bin{11110001} & $-24$ \\
+\bin{11110010} & $25$  & \bin{11110011} & $-25$ \\
+\bin{11110100} & $26$  & \bin{11110101} & $-26$ \\
+\bin{11110110} & $27$  & \bin{11110111} & $-27$ \\
+\bin{11111000} & $28$  & \bin{11111001} & $-28$ \\
+\bin{11111010} & $29$  & \bin{11111011} & $-29$ \\
+\bin{11111100} & $30$  & \bin{11111101} & $-30$ \\
+\bin{11111110} & $31$  & \bin{11111111} & $-31$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Motion Vector Components}
+\label{tab:mv-huff-codes}
+\end{table}
+
+A single motion vector is decoded is follows:
+
+\begin{enumerate}
+\item
+If \bitvar{MVMODE} is 0:
+\begin{enumerate}
+\item
+Read 1 bit at a time until one of the Huffman codes in
+ Table~\ref{tab:mv-huff-codes} is recognized, and assign the value to
+ \locvar{MVX}.
+\item
+Read 1 bit at a time until one of the Huffman codes in
+ Table~\ref{tab:mv-huff-codes} is recognized, and assign the value to
+ \locvar{MVY}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read a 5-bit unsigned integer as \bitvar{MVX}.
+\item
+Read a 1-bit unsigned integer as \locvar{MVSIGN}.
+\item
+If \locvar{MVSIGN} is 1, assign \bitvar{MVX} the value $-\bitvar{MVX}$.
+\item
+Read a 5-bit unsigned integer as \bitvar{MVY}.
+\item
+Read a 1-bit unsigned integer as \locvar{MVSIGN}.
+\item
+If \locvar{MVSIGN} is 1, assign \bitvar{MVY} the value $-\bitvar{MVY}$.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Macro Block Motion Vector Decode}
+\label{sub:mb-mv-decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PF}      & Integer &  2 & No & The pixel format. \\
+\bitvar{NMBS}    & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              3 & No & An \bitvar{NMBS}-element array of coding
+ modes for each macro block. \\
+\bitvar{NBS}      & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVECTS}   & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+                               6 & Yes & An \bitvar{NBS}-element array of
+ motion vectors for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LAST1}    & \multicolumn{1}{p{50pt}}{2D Integer Vector} &
+                               6 & Yes & The last motion vector. \\
+\locvar{LAST2}    & \multicolumn{1}{p{50pt}}{2D Integer Vector} &
+                               6 & Yes & The second to last motion vector. \\
+\locvar{MVX}      & Integer &  6 & Yes & The X component of a motion vector. \\
+\locvar{MVY}      & Integer &  6 & Yes & The Y component of a motion vector. \\
+\locvar{\mbi}     & Integer & 32 &  No & The index of the current macro
+ block. \\
+\locvar{A}        & Integer & 36 &  No & The index of the lower-left luma block
+ in the macro block. \\
+\locvar{B}        & Integer & 36 &  No & The index of the lower-right luma
+ block in the macro block. \\
+\locvar{C}        & Integer & 36 &  No & The index of the upper-left luma block
+ in the macro block. \\
+\locvar{D}        & Integer & 36 &  No & The index of the upper-right luma
+ block in the macro block. \\
+\locvar{E}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{F}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{G}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{H}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{I}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{J}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{K}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{L}        & Integer & 36 &  No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\bottomrule\end{tabularx}
+\medskip
+
+Motion vectors are stored for each macro block.
+In every mode except for INTER\_MV\_FOUR, every block in all the color planes
+ are assigned the same motion vector.
+In INTER\_MV\_FOUR mode, all four blocks in the luma plane are assigned their
+ own motion vector, and motion vectors for blocks in the chroma planes are
+ computed from these, using averaging appropriate to the pixel format.
+
+For INTER\_MV and INTER\_GOLDEN\_MV modes, a single motion vector is decoded
+ and applied to each block.
+For INTER\_MV\_FOUR macro blocks, a motion vector is decoded for each coded
+ luma block.
+Uncoded luma blocks receive the default $(0,0)$ vector for the purposes of
+ computing the chroma motion vectors.
+
+None of the remaining macro block coding modes require decoding motion vectors
+ from the stream.
+INTRA mode does not use a motion-compensated predictor, and so requires no
+ motion vector, and INTER\_NOMV and INTER\_GOLDEN\_NOMV modes use the default
+ vector $(0,0)$ for each block.
+This also includes all macro blocks with no coded luma blocks, as they are
+ coded in INTER\_NOMV mode by definition.
+
+The modes INTER\_MV\_LAST and INTER\_MV\_LAST2 use the motion vector from the
+ last macro block (in coded order) and the second to last macro block,
+ respectively, that contained a motion vector pointing to the previous frame.
+Thus no explicit motion vector needs to be decoded for these modes.
+Macro blocks coded in INTRA mode or one of the GOLDEN modes are not considered
+ in this process.
+If an insufficient number of macro blocks have been coded in one of the INTER
+ modes, then the $(0,0)$ vector is used instead.
+For macro blocks coded in INTER\_MV\_FOUR mode, the vector from the upper-right
+ luma block is used, even if the upper-right block is not coded.
+
+The motion vectors are decoded from the stream as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LAST1} and \locvar{LAST2} both the value $(0,0)$.
+\item
+Read a 1-bit unsigned integer as \locvar{MVMODE}.
+Note that this value is read even if no macro blocks require a motion vector to
+ be decoded.
+\item
+For each consecutive value of \locvar{\mbi} from 0 to $(\bitvar{NMBS}-1)$:
+\begin{enumerate}
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is 7 (INTER\_MV\_FOUR):
+\begin{enumerate}
+\item
+Let \locvar{A}, \locvar{B}, \locvar{C}, and \locvar{D} be the indices in coded
+ order \locvar{\bi} of the luma blocks in macro block \locvar{\mbi}, arranged
+ into raster order.
+Thus, \locvar{A} is the index in coded order of the block in the lower left,
+ \locvar{B} the lower right, \locvar{C} the upper left, and \locvar{D} the
+ upper right. % TODO: as shown in Figure~REF.
+\item If $\bitvar{BCODED}[\locvar{A}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{A}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item Otherwise, assign $\bitvar{MVECTS}[\locvar{A}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{B}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{B}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise assign $\bitvar{MVECTS}[\locvar{B}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{C}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{C}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item Otherwise assign $\bitvar{MVECTS}[\locvar{C}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{D}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{D}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise, assign $\bitvar{MVECTS}[\locvar{D}]$ the value $(0,0)$.
+\item
+If \bitvar{PF} is 0 (4:2:0):
+\begin{enumerate}
+\item
+Let \locvar{E} and \locvar{F} be the index in coded order of the one block in
+ the macro block from the $C_b$ and $C_r$ planes, respectively.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{F}]$ the
+ value
+\begin{multline*}
+(\round\biggl(\frac{\begin{aligned}
+ \bitvar{MVECTS}[\locvar{A}]_x+\bitvar{MVECTS}[\locvar{B}]_x+\\
+ \bitvar{MVECTS}[\locvar{C}]_x+\bitvar{MVECTS}[\locvar{D}]_x
+ \end{aligned}}{4}\biggr), \\
+ \round\biggl(\frac{\begin{aligned}
+ \bitvar{MVECTS}[\locvar{A}]_y+\bitvar{MVECTS}[\locvar{B}]_y+\\
+ \bitvar{MVECTS}[\locvar{C}]_y+\bitvar{MVECTS}[\locvar{D}]_y
+ \end{aligned}}{4}\biggr))
+\end{multline*}
+\end{enumerate}
+\item
+If \bitvar{PF} is 2 (4:2:2):
+\begin{enumerate}
+\item
+Let \locvar{E} and \locvar{F} be the indices in coded order of the bottom and
+ top blocks in the macro block from the $C_b$ plane, respectively, and
+ \locvar{G} and \locvar{H} be the indices in coded order of the bottom and top
+ blocks in the $C_r$ plane, respectively. %TODO: as shown in Figure~REF.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{G}]$ the
+ value
+\begin{multline*}
+(\round\left(\frac{
+ \bitvar{MVECTS}[\locvar{A}]_x+\bitvar{MVECTS}[\locvar{B}]_x}{2}\right), \\
+ \round\left(\frac{
+ \bitvar{MVECTS}[\locvar{A}]_y+\bitvar{MVECTS}[\locvar{B}]_y}{2}\right))
+\end{multline*}
+\item
+Assign $\bitvar{MVECTS}[\locvar{F}]$ and $\bitvar{MVECTS}[\locvar{H}]$ the
+ value
+\begin{multline*}
+(\round\left(\frac{
+ \bitvar{MVECTS}[\locvar{C}]_x+\bitvar{MVECTS}[\locvar{D}]_x}{2}\right), \\
+ \round\left(\frac{
+ \bitvar{MVECTS}[\locvar{C}]_y+\bitvar{MVECTS}[\locvar{D}]_y}{2}\right))
+\end{multline*}
+\end{enumerate}
+\item
+If \bitvar{PF} is 3 (4:4:4):
+\begin{enumerate}
+\item
+Let \locvar{E}, \locvar{F}, \locvar{G}, and \locvar{H} be the indices
+ \locvar{\bi} in coded order of the $C_b$ plane blocks in macro block
+ \locvar{\mbi}, arranged into raster order, and \locvar{I}, \locvar{J},
+ \locvar{K}, and \locvar{L} be the indices \locvar{\bi} in coded order of the
+ $C_r$ plane blocks in macro block \locvar{\mbi}, arranged into raster order.
+ %TODO: as shown in Figure~REF.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{I}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{A}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{F}]$ and $\bitvar{MVECTS}[\locvar{J}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{B}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{G}]$ and $\bitvar{MVECTS}[\locvar{K}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{C}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{H}]$ and $\bitvar{MVECTS}[\locvar{L}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{D}]$.
+\end{enumerate}
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+This is the value of the motion vector decoded from the last coded luma block
+ in raster order.
+There must always be at least one, since macro blocks with no coded luma blocks
+ must use mode 0:~INTER\_NOMV.
+\end{enumerate}
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 6 (INTER\_GOLDEN\_MV),
+ decode a single motion vector into \locvar{MVX} and \locvar{MVY} using the
+ procedure described in Section~\ref{sub:mv-decode}.
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 4 (INTER\_MV\_LAST2):
+\begin{enumerate}
+\item
+Assign $(\locvar{MVX},\locvar{MVY})$ the value \locvar{LAST2}.
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 3 (INTER\_MV\_LAST), assign
+ $(\locvar{MVX},\locvar{MVY})$ the value \locvar{LAST1}.
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 2 (INTER\_MV):
+\begin{enumerate}
+\item
+Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using the
+ procedure described in Section~\ref{sub:mv-decode}.
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise ($\bitvar{MBMODES}[\locvar{\mbi}]$ is 5:~INTER\_GOLDEN\_NOMV,
+ 1:~INTRA, or 0:~INTER\_NOMV), assign \locvar{MVX} and \locvar{MVY} the value
+ zero.
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is not 7 (not INTER\_MV\_FOUR), then for
+ each coded block \locvar{\bi} in macro block \locvar{\mbi}:
+\begin{enumerate}
+\item
+Assign $\bitvar{MVECTS}[\locvar{\bi}]$ the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+Unless all four luma blocks in the macro block are coded, the VP3 encoder does
+ not select mode INTER\_MV\_FOUR.
+Theora removes this restriction by treating the motion vector for an uncoded
+ luma block as the default $(0,0)$ vector.
+This is consistent with the premise that the block has not changed since the
+ previous frame and that chroma information can be largely ignored when
+ estimating motion.
+
+No modification is required for INTER\_MV\_FOUR macro blocks in VP3 streams to
+ be decoded correctly by a Theora decoder.
+However, regardless of how many of the luma blocks are actually coded, the VP3
+ decoder always reads four motion vectors from the stream for INTER\_MV\_FOUR
+ mode.
+The motion vectors read are used to calculate the motion vectors for the chroma
+ blocks, but are otherwise ignored.
+Thus, care should be taken when creating Theora streams meant to be backwards
+ compatible with VP3 to only use INTER\_MV\_FOUR mode when all four luma
+ blocks are coded.
+
+\section{Block-Level \qi\ Decode}
+\label{sub:block-qis}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBS}      & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{NQIS}     & Integer &  2 & No & The number of \qi\ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{QIIS}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               2 & No & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NBITS}    & Integer & 36 & No & The length of a bit string to decode. \\
+\locvar{BITS}     & Bit string & &    & A decoded set of flags. \\
+\locvar{\bi}      & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\qii}     & Integer &  2 & No & The index of \qi\ value in the list of
+ \qi\ values defined for this frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure selects the \qi\ value to be used for dequantizing the AC
+ coefficients of each block.
+DC coefficients all use the same \qi\ value, so as to avoid interference with
+ the DC prediction mechanism, which occurs in the quantized domain.
+
+The value is actually represented by an index \locvar{\qii} into the list of
+ \qi\ values defined for the frame.
+The decoder makes multiple passes through the list of coded blocks, one for
+ each \qi\ value except the last one.
+In each pass, an RLE-coded bitmask is decoded to divide the blocks into two
+ groups: those that use the current \qi\ value in the list, and those that use
+ a value from later in the list.
+Each subsequent pass is restricted to the blocks in the second group.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$, assign
+ $\bitvar{QIIS}[\locvar{\bi}]$ the value zero.
+\item
+For each consecutive value of \locvar{\qii} from 0 to $(\bitvar{NQIS}-2)$:
+\begin{enumerate}
+\item
+Assign \locvar{NBITS} be the number of blocks \locvar{\bi} such that
+ $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and $\bitvar{QIIS}[\locvar{\bi}]$
+ equals $\locvar{\qii}$.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of blocks that use \qi\ value \locvar{\qii} or higher.
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$ such
+ that $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and
+ $\bitvar{QIIS}[\locvar{\bi}]$ equals $\locvar{\qii}$:
+\begin{enumerate}
+\item
+Remove the bit at the head of the string \locvar{BITS} and add its value to
+ $\bitvar{QIIS}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+For VP3 compatible streams, only one \qi\ value can be specified in the frame
+ header, so the main loop of the above procedure, which would iterate from $0$
+ to $-1$, is never executed.
+Thus, no bits are read, and each block uses the one \qi\ value defined for the
+ frame.
+
+\cleardoublepage
+
+\section{DCT Coefficients}
+\label{sec:dct-decode}
+
+The quantized DCT coefficients are decoded by making 64 passes through the list
+ of coded blocks, one for each token index in zig-zag order.
+For the DC tokens, two Huffman tables are chosen from among the first 16, one
+ for the luma plane and one for the chroma planes.
+The AC tokens, however, are divided into four different groups.
+Again, two 4-bit indices are decoded, one for the luma plane, and one for the
+ chroma planes, but these select the codebooks for {\em all four} groups.
+AC coefficients in group one use codebooks $16\ldots 31$, while group two uses
+ $32\ldots 47$, etc.
+Note that this second set of indices is decoded even if there are no non-zero
+ AC coefficients in the frame.
+
+Tokens are divided into two major types: EOB tokens, which fill the remainder
+ of one or more blocks with zeros, and coefficient tokens, which fill in one or
+ more coefficients within a single block.
+A decoding procedure for the first is given in Section~\ref{sub:eob-token}, and
+ for the second in Section~\ref{sub:coeff-token}.
+The decoding procedure for the complete set of quantized coefficients is given
+ in Section~\ref{sub:dct-coeffs}.
+
+\subsection{EOB Token Decode}
+\label{sub:eob-token}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TOKEN}    & Integer &  5 & No  & The token being decoded.
+This must be in the range $0\ldots 6$. \\
+\bitvar{NBS}      & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{TIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{NCOEFFS}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi}      & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\bitvar{\ti}      & Integer &  6 & No  & The current token index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{EOBS}     & Integer & 36 & No  & The remaining length of the current
+ EOB run. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\bj}      & Integer & 36 & No & Another index of a block in coded
+ order. \\
+\locvar{\tj}      & Integer &  6 & No & Another token index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A summary of the EOB tokens is given in Table~\ref{tab:eob-tokens}.
+An important thing to note is that token 6 does not add an offset to the
+ decoded run value, even though in general it should only be used for runs of
+ size 32 or longer.
+If a value of zero is decoded for this run, it is treated as an EOB run the
+ size of the remaining coded blocks.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{ccl}\toprule
+Token Value  & Extra Bits & EOB Run Lengths                         \\\midrule
+$0$          & $0$        & $1$                                     \\
+$1$          & $0$        & $2$                                     \\
+$2$          & $0$        & $3$                                     \\
+$3$          & $2$        & $4\ldots 7$                             \\
+$4$          & $3$        & $8\ldots 15$                            \\
+$5$          & $4$        & $16\ldots 31$                           \\
+$6$          & $12$       & $1\ldots 4095$, or all remaining blocks \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{EOB Token Summary}
+\label{tab:eob-tokens}
+\end{table}
+
+There is no restriction that one EOB token cannot be immediately followed by
+ another, so no special cases are necessary to extend the range of the maximum
+ run length as were required in Section~\ref{sub:long-run}.
+Indeed, depending on the lengths of the Huffman codes, it may even cheaper to
+ encode, by way of example, an EOB run of length 31 followed by an EOB run of
+ length 1 than to encode an EOB run of length 32 directly.
+There is also no restriction that an EOB run stop at the end of a color plane
+ or a token index.
+The run MUST, however, end at or before the end of the frame.
+
+\begin{enumerate}
+\item
+If \bitvar{TOKEN} is 0, assign \bitvar{EOBS} the value 1.
+\item
+Otherwise, if \bitvar{TOKEN} is 1, assign \bitvar{EOBS} the value 2.
+\item
+Otherwise, if \bitvar{TOKEN} is 2, assign \bitvar{EOBS} the value 3.
+\item
+Otherwise, if \bitvar{TOKEN} is 3:
+\begin{enumerate}
+\item
+Read a 2-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+4)$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 4:
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+8)$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 5:
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+16)$.
+\end{enumerate}
+\item
+Otherwise, \bitvar{TOKEN} is 6:
+\begin{enumerate}
+\item
+Read a 12-bit unsigned integer as \bitvar{EOBS}.
+\item
+If \bitvar{EOBS} is zero, assign \bitvar{EOBS} to be the number of coded blocks
+ \locvar{\bj} such that $\bitvar{TIS}[\locvar{\bj}]$ is less than 64.
+\end{enumerate}
+\item
+For each value of \locvar{\tj} from $\bitvar{\ti}$ to 63, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value 64.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}-1)$.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The VP3 encoder does not use the special interpretation of a zero-length EOB
+ run, though its decoder {\em does} support it.
+That may be due more to a happy accident in the way the decoder was written
+ than intentional design, however, and other VP3 implementations might not
+ reproduce it faithfully.
+For backwards compatibility, it may be wise to avoid it, especially as for most
+ frame sizes there are fewer than 4095 blocks, making it unnecessary.
+
+\subsection{Coefficient Token Decode}
+\label{sub:coeff-token}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TOKEN}    & Integer &  5 & No  & The token being decoded.
+This must be in the range $7\ldots 31$. \\
+\bitvar{NBS}      & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{TIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi}      & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\bitvar{\ti}      & Integer &  6 & No  & The current token index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{NCOEFFS}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{SIGN}     & Integer &  1 & No & A flag indicating the sign of the
+ current coefficient. \\
+\locvar{MAG}      & Integer & 10 & No & The magnitude of the current
+ coefficient. \\
+\locvar{RLEN}     & Integer &  6 & No & The length of the current zero run. \\
+\locvar{\tj}      & Integer &  6 & No & Another token index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+Each of these tokens decodes one or more coefficients in the current block.
+A summary of the meanings of the token values is presented in
+ Table~\ref{tab:coeff-tokens}.
+There are often several different ways to tokenize a given coefficient list.
+Which one is optimal depends on the exact lengths of the Huffman codes used to
+ represent each token.
+Note that we do not update the coefficient count for the block if we decode a
+ pure zero run.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabularx}{\textwidth}{cclX}\toprule
+Token Value  & Extra Bits & \multicolumn{1}{p{55pt}}{Number of Coefficients}
+                                    & Description                    \\\midrule
+$7$          & $3$  & $1\ldots 8$   & Short zero run.                \\
+$8$          & $6$  & $1\ldots 64$  & Zero run.                      \\
+$9$          & $0$  & $1$           & $1$.                           \\
+$10$         & $0$  & $1$           & $-1$.                          \\
+$11$         & $0$  & $1$           & $2$.                           \\
+$12$         & $0$  & $1$           & $-2$.                          \\
+$13$         & $1$  & $1$           & $\pm 3$.                       \\
+$14$         & $1$  & $1$           & $\pm 4$.                       \\
+$15$         & $1$  & $1$           & $\pm 5$.                       \\
+$16$         & $1$  & $1$           & $\pm 6$.                       \\
+$17$         & $2$  & $1$           & $\pm 7\ldots 8$.               \\
+$18$         & $3$  & $1$           & $\pm 9\ldots 12$.              \\
+$19$         & $4$  & $1$           & $\pm 13\ldots 20$.             \\
+$20$         & $5$  & $1$           & $\pm 21\ldots 36$.             \\
+$21$         & $6$  & $1$           & $\pm 37\ldots 68$.             \\
+$22$         & $10$ & $1$           & $\pm 69\ldots 580$.            \\
+$23$         & $1$  & $2$           & One zero followed by $\pm 1$.  \\
+$24$         & $1$  & $3$           & Two zeros followed by $\pm 1$. \\
+$25$         & $1$  & $4$           & Three zeros followed by
+ $\pm 1$. \\
+$26$         & $1$  & $5$           & Four zeros followed by
+ $\pm 1$. \\
+$27$         & $1$  & $6$           & Five zeros followed by
+ $\pm 1$. \\
+$28$         & $3$  & $7\ldots 10$  & $6\ldots 9$ zeros followed by
+ $\pm 1$.  \\
+$29$         & $4$  & $11\ldots 18$ & $10\ldots 17$ zeros followed by
+ $\pm 1$.\\
+$30$         & $2$  & $2$           & One zero followed by
+ $\pm 2\ldots 3$. \\
+$31$         & $3$  & $3\ldots 4$   & $2\ldots 3$ zeros followed by
+ $\pm 2\ldots 3$. \\
+\bottomrule\end{tabularx}
+\end{center}
+\caption{Coefficient Token Summary}
+\label{tab:coeff-tokens}
+\end{table}
+
+For tokens which represent more than one coefficient, they MUST NOT bring the
+ total number of coefficients in the block to more than 64.
+Care should be taken in a decoder to check for this, as otherwise it may permit
+ buffer overflows from invalidly formed packets.
+\begin{verse}
+{\bf Note:} One way to achieve this efficiently is to combine the inverse
+ zig-zag mapping (described later in Section~\ref{sub:dequant}) with
+ coefficient decode, and use a table look-up to map zig-zag indices greater
+ than 63 to a safe location.
+\end{verse}
+
+\begin{enumerate}
+\item
+If \bitvar{TOKEN} is 7:
+\begin{enumerate}
+\item
+Read in a 3-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+1)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+  $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 8:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+1)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+  $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 9:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 10:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 11:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $2$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 12:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-2$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 13:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $3$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-3$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 14:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $4$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-4$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 15:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $5$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-5$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 16:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $6$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-6$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 17:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+7)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 18:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 2-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+9)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 19:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 3-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+13)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 20:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 4-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+21)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 21:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 5-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+37)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 22:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 9-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+69)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 23:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+2$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 24:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+2]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+2]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+3$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 25:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+2)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+3]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+3]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+4$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 26:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+3)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+4]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+4]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+5$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 27:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+4)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+5]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+5]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+6$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 28:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 2-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+6)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 29:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 3-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+10)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 30:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\ti}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+2)$.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+2$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 31:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+2)$.
+\item
+Read a 1-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+2)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value
+ $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{DCT Coefficient Decode}
+\label{sub:dct-coeffs}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBS}      & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{NMBS}     & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+                                     & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{NCOEFFS}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No  & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NLBS}     & Integer & 34 & No & The number of blocks in the luma
+ plane. \\
+\locvar{TIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\locvar{EOBS}     & Integer & 36 & No & The remaining length of the current
+ EOB run. \\
+\locvar{TOKEN}    & Integer &  5 & No & The current token being decoded. \\
+\locvar{HG}       & Integer &  3 & No & The current Huffman table group. \\
+\locvar{\cbi}     & Integer & 36 & No & The index of the current block in the
+ coded block list. \\
+\locvar{\bi}      & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\bj}      & Integer & 36 & No & Another index of a block in coded
+ order. \\
+\locvar{\ti}      & Integer &  6 & No & The current token index. \\
+\locvar{\tj}      & Integer &  6 & No & Another token index. \\
+\locvar{\hti_L}   & Integer &  4 & No & The index of the current Huffman table
+ to use for the luma plane within a group. \\
+\locvar{\hti_C}   & Integer &  4 & No & The index of the current Huffman table
+ to use for the chroma planes within a group. \\
+\locvar{\hti}     & Integer &  7 & No & The index of the current Huffman table
+ to use. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure puts the above two procedures to work to decode the entire set
+ of DCT coefficients for the frame.
+At the end of this procedure, \locvar{EOBS} MUST be zero, and
+ $\locvar{TIS}[\locvar{\bi}]$ MUST be 64 for every coded \locvar{\bi}.
+
+Note that we update the coefficient count of every block before continuing an
+ EOB run or decoding a token, despite the fact that it is already up to date
+ unless the previous token was a pure zero run.
+This is done intentionally to mimic the VP3 accounting rules.
+Thus the only time the coefficient count does not include the coefficients in a
+ pure zero run is when when that run reaches all the way to coefficient 63.
+Note, however, that regardless of the coefficient count, any additional
+ coefficients are still set to zero.
+The only use of the count is in determining if a special case of the inverse
+ DCT can be used in Section~\ref{sub:2d-idct}.
+
+\begin{enumerate}
+\item
+Assign \locvar{NLBS} the value $(\bitvar{NMBS}*4)$.
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$,
+ assign $\locvar{TIS}[\locvar{\bi}]$ the value zero.
+\item
+Assign \locvar{EOBS} the value 0.
+\item
+For each consecutive value of \locvar{\ti} from 0 to 63:
+\begin{enumerate}
+\item
+If \locvar{\ti} is $0$ or $1$:
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer as \locvar{\hti_L}.
+\item
+Read a 4-bit unsigned integer as \locvar{\hti_C}.
+\end{enumerate}
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$ for
+ which $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and
+ $\locvar{TIS}[\locvar{\bi}]$ equals \locvar{\ti}:
+\begin{enumerate}
+\item
+Assign $\bitvar{NCOEFFS}[\locvar{\bi}]$ the value \locvar{\ti}.
+\item
+If \locvar{EOBS} is greater than zero:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from $\locvar{\ti}$ to 63, assign
+ $\bitvar{COEFFS}[\locvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\locvar{TIS}[\locvar{\bi}]$ the value 64.
+\item
+Assign \locvar{EOBS} the value $(\locvar{EOBS}-1)$.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{HG} a value based on \locvar{\ti} from
+ Table~\ref{tab:huff-groups}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lc}\toprule
+\locvar{\ti}  & \locvar{HG} \\\midrule
+$0$           & $0$ \\
+$1\ldots 5$   & $1$ \\
+$6\ldots 14$  & $2$ \\
+$15\ldots 27$ & $3$ \\
+$28\ldots 63$ & $4$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Table Groups}
+\label{tab:huff-groups}
+\end{table}
+
+\item
+If \locvar{\bi} is less than \locvar{NLBS}, assign \locvar{\hti} the value
+ $(16*\locvar{HG}+\locvar{\hti_L})$.
+\item
+Otherwise, assign \locvar{\hti} the value
+ $(16*\locvar{HG}+\locvar{\hti_C})$.
+\item
+Read one bit at a time until one of the codes in $\bitvar{HTS}[\locvar{\hti}]$
+ is recognized, and assign the value to \locvar{TOKEN}.
+\item
+If \locvar{TOKEN} is less than 7, expand an EOB token using the procedure given
+ in Section~\ref{sub:eob-token} to update $\locvar{TIS}[\locvar{\bi}]$,
+ $\bitvar{COEFFS}[\locvar{\bi}]$, and \locvar{EOBS}.
+\item
+Otherwise, expand a coefficient token using the procedure given in
+ Section~\ref{sub:coeff-token} to update $\locvar{TIS}[\locvar{\bi}]$,
+ $\bitvar{COEFFS}[\locvar{\bi}]$, and $\bitvar{NCOEFFS}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Undoing DC Prediction}
+
+The actual value of a DC coefficient decoded by Section~\ref{sec:dct-decode} is
+ the residual from a predicted value computed by the encoder.
+This prediction is only applied to DC coefficients.
+Quantized AC coefficients are encoded directly.
+
+This section describes how to undo this prediction to recover the original
+ DC coefficients.
+The predicted DC value for a block is computed from the DC values of its
+ immediate neighbors which precede the block in raster order.
+Thus, reversing this prediction must procede in raster order, instead of coded
+ order.
+
+Note that this step comes before dequantizing the coefficients.
+For this reason, DC coefficients are all quantized with the same \qi\ value,
+ regardless of the block-level \qi\ values decoded in
+ Section~\ref{sub:block-qis}.
+Those \qi\ values are applied only to the AC coefficients.
+
+\subsection{Computing the DC Predictor}
+\label{sub:dc-pred}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No  & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{MBMODES}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               3 & No  & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{LASTDC}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & A 3-element array containing the
+ most recently decoded DC value, one for inter mode and for each reference
+ frame. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi}      & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DCPRED} & Integer & 16 & Yes & The predicted DC value for the current
+ block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{P}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No  & A 4-element array indicating which
+ neighbors can be used for DC prediction. \\
+\locvar{PBI}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              36 & No  & A 4-element array containing the
+ coded-order block index of the current block's neighbors. \\
+\locvar{W}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               7 & Yes & A 4-element array of the weights to
+ apply to each neighboring DC value. \\
+\locvar{PDIV}     & Integer &  8 & No  & The valud to divide the weighted sum
+ by. \\
+\locvar{\bj}      & Integer & 36 & No  & The index of a neighboring block in
+ coded order. \\
+\locvar{\mbi}     & Integer & 32 & No  & The index of the macro block
+ containing block \locvar{\bi}. \\
+\locvar{\mbi}     & Integer & 32 & No  & The index of the macro block
+ containing block \locvar{\bj}. \\
+\locvar{\rfi}     & Integer &  2 & No  & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure outlines how a predictor is formed for a single block.
+
+The predictor is computed as a weighted sum of the neighboring DC values from
+ coded blocks which use the same reference frame.
+This latter condition is determined only by checking the coding mode for the
+ block.
+Even if the golden frame and the previous frame are in fact the same, e.g. for
+ the first inter frame after an intra frame, they are still treated as being
+ different for the purposes of DC prediction.
+The weighted sum is divided by a power of two, with truncation towards zero,
+ and the result is checked for outranging if necessary.
+
+If there are no neighboring coded blocks which use the same reference frame as
+ the current block, then the most recent DC value of any block that used that
+ reference frame is used instead.
+If no such block exists, then the predictor is set to zero.
+
+\begin{enumerate}
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \bitvar{\bi}.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+
+\begin{table}[htpb]
+\begin{center}
+\begin{tabular}{ll}\toprule
+Coding Mode               & Reference Frame Index \\\midrule
+$0$ (INTER\_NOMV)         & $1$ (Previous)        \\
+$1$ (INTRA)               & $0$ (None)            \\
+$2$ (INTER\_MV)           & $1$ (Previous)        \\
+$3$ (INTER\_MV\_LAST)     & $1$ (Previous)        \\
+$4$ (INTER\_MV\_LAST2)    & $1$ (Previous)        \\
+$5$ (INTER\_GOLDEN\_NOMV) & $2$ (Golden)          \\
+$6$ (INTER\_GOLDEN\_MV)   & $2$ (Golden)          \\
+$7$ (INTER\_MV\_FOUR)     & $1$ (Previous)        \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reference Frames for Each Coding Mode}
+\label{tab:cm-refs}
+\end{table}
+
+\item
+If block \locvar{\bi} is not along the left edge of the coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \locvar{\bi}'s left
+ neighbor, i.e., in the same row but one column to the left.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[0]$ the value $1$.
+\item
+Assign $\locvar{PBI}[0]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+
+\item
+If block \locvar{\bi} is not along the left edge nor the bottom edge of the
+ coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \locvar{\bi}'s lower-left
+ neighbor, i.e., one row down and one column to the left.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[1]$ the value $1$.
+\item
+Assign $\locvar{PBI}[1]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+
+\item
+If block \locvar{\bi} is not along the the bottom edge of the coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \locvar{\bi}'s lower
+ neighbor, i.e., in the same column but one row down.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[2]$ the value $1$.
+\item
+Assign $\locvar{PBI}[2]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+
+\item
+If block \locvar{\bi} is not along the right edge nor the bottom edge of the
+ coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \locvar{\bi}'s lower-right
+ neighbor, i.e., one row down and one column to the right.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[3]$ the value $1$.
+\item
+Assign $\locvar{PBI}[3]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+
+\item
+If none of the values $\locvar{P}[0]$, $\locvar{P}[1]$, $\locvar{P}[2]$, nor
+ $\locvar{P}[3]$ are non-zero, then assign \bitvar{DCPRED} the value
+ $\bitvar{LASTDC}[\locvar{\rfi}]$.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign the array \locvar{W} and the variable \locvar{PDIV} the values from the
+ row of Table~\ref{tab:dc-weights} corresonding to the values of each
+ $\locvar{P}[\idx{i}]$.
+
+\begin{table}[htb]
+\begin{center}
+\begin{tabular}{ccccrrrrr}\toprule
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[0]$ (L)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[1]$ (DL)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[2]$ (D)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[3]$ (DR)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[3]$ (L)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[1]$ (DL)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[2]$ (D)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[3]$ (DR)} &
+\locvar{PDIV} \\\midrule
+$1$ & $0$ & $0$ & $0$ &  $1$ &   $0$ &  $0$ &  $0$ &   $1$ \\
+$0$ & $1$ & $0$ & $0$ &  $0$ &   $1$ &  $0$ &  $0$ &   $1$ \\
+$1$ & $1$ & $0$ & $0$ &  $1$ &   $0$ &  $0$ &  $0$ &   $1$ \\
+$0$ & $0$ & $1$ & $0$ &  $0$ &   $0$ &  $1$ &  $0$ &   $1$ \\
+$1$ & $0$ & $1$ & $0$ &  $1$ &   $0$ &  $1$ &  $0$ &   $2$ \\
+$0$ & $1$ & $1$ & $0$ &  $0$ &   $0$ &  $1$ &  $0$ &   $1$ \\
+$1$ & $1$ & $1$ & $0$ & $29$ & $-26$ & $29$ &  $0$ &  $32$ \\
+$0$ & $0$ & $0$ & $1$ &  $0$ &   $0$ &  $0$ &  $1$ &   $1$ \\
+$1$ & $0$ & $0$ & $1$ & $75$ &   $0$ &  $0$ & $53$ & $128$ \\
+$0$ & $1$ & $0$ & $1$ &  $0$ &   $1$ &  $0$ &  $1$ &   $2$ \\
+$1$ & $1$ & $0$ & $1$ & $75$ &   $0$ &  $0$ & $53$ & $128$ \\
+$0$ & $0$ & $1$ & $1$ &  $0$ &   $0$ &  $1$ &  $0$ &   $1$ \\
+$1$ & $0$ & $1$ & $1$ & $75$ &   $0$ &  $0$ & $53$ & $128$ \\
+$0$ & $1$ & $1$ & $1$ &  $0$ &   $3$ & $10$ &  $3$ &  $16$ \\
+$1$ & $1$ & $1$ & $1$ & $29$ & $-26$ & $29$ &  $0$ &  $32$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Weights and Divisors for Each Set of Available DC Predictors}
+\label{tab:dc-weights}
+\end{table}
+
+\item
+Assign \bitvar{DCPRED} the value zero.
+\item
+If $\locvar{P}[0]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[0]*\bitvar{COEFFS}[\locvar{PBI}[0]][0])$.
+\item
+If $\locvar{P}[1]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[1]*\bitvar{COEFFS}[\locvar{PBI}[1]][0])$.
+\item
+If $\locvar{P}[2]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[2]*\bitvar{COEFFS}[\locvar{PBI}[2]][0])$.
+\item
+If $\locvar{P}[3]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[3]*\bitvar{COEFFS}[\locvar{PBI}[3]][0])$.
+\item
+Assign \bitvar{DCPRED} the value $(\bitvar{DCPRED}//\locvar{PDIV})$.
+\item
+If $\locvar{P}[0]$, $\locvar{P}[1]$, and $\locvar{P}[2]$ are all non-zero:
+\begin{enumerate}
+\item
+If $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[2]][0]|$ is greater than
+ $128$, assign \bitvar{DCPRED} the value $\bitvar{COEFFS}[\locvar{PBI}[2]][0]$.
+\item
+Otherwise, if $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[0]][0]|$ is
+ greater than $128$, assign \bitvar{DCPRED} the value
+ $\bitvar{COEFFS}[\locvar{PBI}[0]][0]$.
+\item
+Otherwise, if $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[1]][0]|$ is
+ greater than $128$, assign \bitvar{DCPRED} the value
+ $\bitvar{COEFFS}[\locvar{PBI}[1]][0]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Inverting the DC Prediction Process}
+\label{sub:dc-pred-undo}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               1 & No  & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{MBMODES}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                               3 & No  & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. The DC 
+ value of each block will be updated. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LASTDC}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & A 3-element array containing the
+ most recently decoded DC value, one for inter mode and for each reference
+ frame. \\
+\locvar{DCPRED}   & Integer & 11 & Yes & The predicted DC value for the current
+ block. \\
+\locvar{DC}       & Integer & 17 & Yes & The actual DC value for the current
+ block. \\
+\locvar{\bi}      & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\locvar{\mbi}     & Integer & 32 & No  & The index of the macro block
+ containing block \locvar{\bi}. \\
+\locvar{\rfi}     & Integer &  2 & No  & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\locvar{\pli}     & Integer &  2 & No  & A color plane index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure describes the complete process of undoing the DC prediction to
+ recover the original DC values.
+Because it is possible to add a value as large as $580$ to the predicted DC
+ coefficient value at every block, which will then be used to increase the
+ predictor for the next block, the reconstructed DC value could overflow a
+ 16-bit integer.
+This is handled by truncating the result to a 16-bit signed representation,
+ simply throwing away any higher bits in the two's complement representation of
+ the number.
+
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\pli} from $0$ to $2$:
+\begin{enumerate}
+\item
+Assign $\locvar{LASTDC}[0]$ the value zero.
+\item
+Assign $\locvar{LASTDC}[1]$ the value zero.
+\item
+Assign $\locvar{LASTDC}[2]$ the value zero.
+\item
+For each block of color plane \locvar{\pli} in {\em raster} order, with
+ coded-order index \locvar{\bi}:
+\begin{enumerate}
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Compute the value \locvar{DCPRED} using the procedure outlined in
+ Section~\ref{sub:dc-pred}.
+\item
+Assign \locvar{DC} the value
+ $(\bitvar{COEFFS}[\locvar{\bi}][0]+\locvar{DCPRED})$.
+\item
+Truncate \locvar{DC} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{COEFFS}[\locvar{\bi}][0]$ the value \locvar{DC}.
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \locvar{\bi}.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\item
+Assign $\locvar{LASTDC}[\rfi]$ the value $\locvar{DC}$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Reconstruction}
+
+At this stage, the complete contents of the data packet have been decoded.
+All that remains is to reconstruct the contents of the new frame.
+This is applied on a block by block basis, and as each block is independent,
+ the order they are processed in does not matter.
+
+\subsection{Predictors}
+\label{sec:predictors}
+
+For each block, a predictor is formed based on its coding mode and motion
+ vector.
+There are three basic types of predictors: the intra predictor, the whole-pixel
+ predictor, and the half-pixel predictor.
+The former is used for all blocks coded in INTRA mode, while all other blocks
+ use one of the latter two.
+The whole-pixel predictor is used if the fractional part of both motion vector
+ components is zero, otherwise the half-pixel predictor is used.
+
+\subsubsection{The Intra Predictor}
+\label{sub:predintra}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & An $8\times 8$ array of predictor
+ values to use for INTRA coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}}  & Integer &  3 & No  & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}}  & Integer &  3 & No  & The vertical pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The intra predictor is nothing more than the constant value $128$.
+This is applied for the sole purpose of centering the range of possible DC
+ values for INTRA blocks around zero.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value $128$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The Whole-Pixel Predictor}
+\label{sub:predfullpel}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RPW}   & Integer   & 20 & No  & The width of the current plane of the
+ reference frame in pixels. \\
+\bitvar{RPH}   & Integer   & 20 & No  & The height of the current plane of the
+ reference frame in pixels. \\
+\bitvar{REFP}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reference frame. \\
+\bitvar{BX}    & Integer   & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{BY}    & Integer   & 20 & No  & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{MVX}   & Integer   &  5 & No  & The horizontal component of the block
+ motion vector.
+This is always a whole-pixel value. \\
+\bitvar{MVY}   & Integer   &  5 & No  & The vertical component of the block
+ motion vector.
+This is always a whole-pixel value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & An $8\times 8$ array of predictor
+ values to use for INTER coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}} & Integer &  3 & Yes & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer &  3 & Yes & The vertical pixel index in the
+ block. \\
+\locvar{\idx{rx}} & Integer & 20 & No  & The horizontal pixel index in the
+ reference frame. \\
+\locvar{\idx{ry}} & Integer & 20 & No  & The vertical pixel index in the
+ reference frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The whole pixel predictor simply copies verbatim the contents of the reference
+ frame pointed to by the block's motion vector.
+If the vector points outside the reference frame, then the closest value on the
+ edge of the reference frame is used instead.
+In practice, this is usually implemented by expanding the size of the reference
+ frame by $8$ or $16$ pixels on each side---depending on whether or not the
+ corresponding axis is subsampled in the current plane---and copying the border
+ pixels into this region.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{ry}} the value
+ $(\bitvar{BY}+\bitvar{MVY}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry}} is less than zero, assign \locvar{\idx{ry}} the value
+ zero.
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{rx}} the value
+ $(\bitvar{BX}+\bitvar{MVX}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx}} is less than zero, assign \locvar{\idx{rx}} the value
+ zero.
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value
+ $\bitvar{REFP}[\locvar{\idx{ry}}][\locvar{\idx{rx}}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The Half-Pixel Predictor}
+\label{sub:predhalfpel}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RPW}   & Integer   & 20 & No  & The width of the current plane of the
+ reference frame in pixels. \\
+\bitvar{RPH}   & Integer   & 20 & No  & The height of the current plane of the
+ reference frame in pixels. \\
+\bitvar{REFP}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reference frame. \\
+\bitvar{BX}    & Integer   & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{BY}    & Integer   & 20 & No  & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{MVX}   & Integer   &  5 & No  & The horizontal component of the first
+ whole-pixel motion vector. \\
+\bitvar{MVY}   & Integer   &  5 & No  & The vertical component of the first
+ whole-pixel motion vector. \\
+\bitvar{MVX2}  & Integer   &  5 & No  & The horizontal component of the second
+ whole-pixel motion vector. \\
+\bitvar{MVY2}  & Integer   &  5 & No  & The vertical component of the second
+ whole-pixel motion vector. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & An $8\times 8$ array of predictor
+ values to use for INTER coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}} & Integer &  3 & Yes & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer &  3 & Yes & The vertical pixel index in the
+ block. \\
+\locvar{\idx{rx1}} & Integer & 20 & No  & The first horizontal pixel index in
+ the reference frame. \\
+\locvar{\idx{ry1}} & Integer & 20 & No  & The first vertical pixel index in the
+ reference frame. \\
+\locvar{\idx{rx2}} & Integer & 20 & No  & The second horizontal pixel index in
+ the reference frame. \\
+\locvar{\idx{ry2}} & Integer & 20 & No  & The second vertical pixel index in
+ the reference frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+If one or both of the components of the block motion vector is not a
+ whole-pixel value, then the half-pixel predictor is used.
+The half-pixel predictor converts the fractional motion vector into two
+ whole-pixel motion vectors.
+The first is formed by truncating the values of each component towards zero,
+ and the second is formed by truncating them away from zero.
+The contributions from the reference frame at the locations pointed to by each
+ vector are averaged, truncating towards negative infinity.
+
+Only two samples from the reference frame contribute to each predictor value,
+ even if both components of the motion vector have non-zero fractional
+ components.
+Motion vector components with quarter-pixel accuracy in the chroma planes are
+ treated exactly the same as those with half-pixel accuracy.
+Any non-zero fractional part gets rounded one way in the first vector, and the
+ other way in the second.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{ry1}} the value
+ $(\bitvar{BY}+\bitvar{MVY1}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry1}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry1}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry1}} is less than zero, assign \locvar{\idx{ry1}} the value
+ zero.
+\item
+Assign \locvar{\idx{ry2}} the value
+ $(\bitvar{BY}+\bitvar{MVY2}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry2}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry2}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry2}} is less than zero, assign \locvar{\idx{ry2}} the value
+ zero.
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{rx1}} the value
+ $(\bitvar{BX}+\bitvar{MVX1}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx1}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx1}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx1}} is less than zero, assign \locvar{\idx{rx1}} the value
+ zero.
+\item
+Assign \locvar{\idx{rx2}} the value
+ $(\bitvar{BX}+\bitvar{MVX2}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx2}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx2}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx2}} is less than zero, assign \locvar{\idx{rx2}} the value
+ zero.
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value
+\begin{equation*}
+ (\bitvar{REFP}[\locvar{\idx{ry1}}][\locvar{\idx{rx1}}]+
+ \bitvar{REFP}[\locvar{\idx{ry2}}][\locvar{\idx{rx2}}])>>1.
+\end{equation*}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Dequantization}
+\label{sub:dequant}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                             16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No  & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No  & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{BMS}     & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              8 & No  & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}    & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                              6 & No  & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              6 & No  & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS}  & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                              9 & No  & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{\qti}    & Integer &  1 & No  & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\bitvar{\pli}    & Integer &  2 & No  & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\bitvar{\idx{qi0}} & Integer &  6 & No  & The quantization index of the DC
+ coefficient. \\
+\bitvar{\qi}     & Integer &  6 & No  & The quantization index of the AC
+ coefficients. \\
+\bitvar{\bi}     & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DQC}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              14 & Yes & A $64$-element array of dequantized
+ DCT coefficients in natural order (cf. Section~\ref{sec:dct-coeffs}). \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{QMAT}    & \multicolumn{1}{p{40pt}}{Integer array} &
+                             16 & No  & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\locvar{\ci}     & Integer &  6 & No  & The DCT coefficient index in natural
+ order. \\
+\locvar{\zzi}    & Integer &  6 & No  & The DCT coefficient index in zig-zag
+ order. \\
+\locvar{C}       & Integer & 29 & Yes & A single dequantized coefficient. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure takes the quantized DCT coefficient values in zig-zag order for
+ a single block---after DC prediction has been undone---and returns the
+ dequantized values in natural order.
+If large coefficient values are decoded for coarsely quantized coefficients,
+ the resulting dequantized value can be significantly larger than 16 bits.
+Such a coefficient is truncated to a signed 16-bit representation by discarding
+ the higher-order bits of its twos-complement representation.
+
+Although this procedure recomputes the quantization matrices from the
+ parameters in the setup header for each block, there are at most six different
+ ones used for each color plane.
+An efficient implementation could compute them once in advance.
+
+\begin{enumerate}
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{\qti}, \bitvar{\pli}, and
+ \bitvar{\idx{qi0}}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the DC quantization matrix \locvar{QMAT}.
+\item
+Assign \locvar{C} the value
+ $\bitvar{COEFFS}[\bitvar{\bi}][0]*\locvar{QMAT}[0]$.
+\item
+Truncate \locvar{C} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{DQC}[0]$ the value \locvar{C}.
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{\qti}, \bitvar{\pli}, and
+ \bitvar{\qi}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the AC quantization matrix \locvar{QMAT}.
+\item
+For each value of \locvar{\ci} from 1 to 63, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\zzi} the index in zig-zag order corresponding to \locvar{\ci}.
+E.g., the value at row $(\locvar{\ci}//8)$ and column $(\locvar{\ci}\%8)$ in
+ Figure~\ref{tab:zig-zag}
+\item
+Assign \locvar{C} the value
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\zzi}]*\locvar{QMAT}[\locvar{\ci}]$.
+\item
+Truncate \locvar{C} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{DQC}[\locvar{\ci}]$ the value \locvar{C}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{The Inverse DCT}
+
+The 2D inverse DCT is separated into two applications of the 1D inverse DCT.
+The transform is first applied to each row, and then applied to each column of
+ the result.
+
+Each application of the 1D inverse DCT scales the values by a factor of two
+ relative to the orthonormal version of the transform, for a total scale factor
+ of four for the 2D transform.
+It is assumed that a similar scale factor is applied during the forward DCT
+ used in the encoder, so that a division by 16 is required after the transform
+ has been applied in both directions.
+The inclusion of this scale factor allows the integerized transform to operate
+ with increased precision.
+All divisions throughout the transform are implemented with right shifts.
+Only the final division by $16$ is rounded, with ties rounded towards positive
+ infinity.
+
+All intermediate values are truncated to a 32-bit signed representation by
+ discarding any higher-order bits in their two's complement representation.
+The final output of each 1D transform is truncated to a 16-bit signed value in
+ the same manner.
+In practice, if the high word of a $16\times 16$ bit multiplication can be
+ obtained directly, 16 bits is sufficient for every calculation except scaling
+ by $C4$.
+Thus we truncate to 16 bits before that multiplication to allow an
+ implementation entirely in 16-bit registers.
+Implementations using larger registers must sign-extend the 16-bit value to
+ maintain compatibility.
+
+Note that if 16-bit register are used, overflow in the additions and
+ subtractions should be handled using \textit{unsaturated} arithmetic.
+That is, the high-order bits should be discarded and the low-order bits
+ retained, instead of clamping the result to the maximum or minimum value.
+This allows the maximum flexibility in re-ordering these instructions without
+ deviating from this specification.
+
+The 1D transform can only overflow if input coefficients larger than $\pm 6201$
+ are present.
+However, the result of applying the 2D forward transform on pixel values in the
+ range $-255\ldots 255$ can be as large as $\pm 8157$ due to the scale factor
+ of four that is applied, and quantization errors could make this even larger.
+Therefore, the coefficients cannot simply be clamped into a valid range before
+ the transform.
+
+\subsubsection{The 1D Inverse DCT}
+\label{sub:1d-idct}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{Y}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & An 8-element array of DCT
+ coefficients. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{X}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & An 8-element array of output values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{T}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              32 & Yes & An 8-element array containing the
+ current value of each signal line. \\
+\locvar{R}        & Integer & 32 & Yes & A temporary value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A compliant decoder MUST use the exact implementation of the inverse DCT
+ defined in this specification.
+Some operations may be re-ordered, but the result must be precisely equivalent.
+This is a design decision that limits some avenues of decoder optimization, but
+ prevents any drift in the prediction loop.
+Theora uses a 16-bit integerized approximation of of the 8-point 1D inverse DCT
+ based on the Chen factorization \cite{CSF77}.
+It requires 16 multiplications and 26 additions and subtractions.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{idct}
+\end{center}
+\caption{Signal Flow Graph for the 1D Inverse DCT}
+\label{fig:idct}
+\end{figure}
+
+A signal flow graph of the transformation is presented in
+ Figure~\ref{fig:idct}.
+This graph provides a good visualization of which parts of the transform are
+ parallelizable.
+Time increases from left to right.
+
+Each signal line is involved in an operation where the line is marked with a
+ dot $\cdot$ or a circled plus sign $\oplus$.
+The constants $\locvar{C}i$ and $\locvar{S}j$ are the 16-bit integer
+ approximations of $\cos(\frac{i\pi}{16})$ and $\sin(\frac{j\pi}{16})$ listed
+ in Table~\ref{tab:dct-consts}.
+When they appear next to a signal line, the value on that line is scaled by the
+ given constant.
+A circled minus sign $\ominus$ next to a signal line indicates that the value
+ on that line is negated.
+
+Operations on a single signal path through the graph cannot be reordered, but
+ operations on different paths may be, or may be executed in parallel.
+Different graphs may be obtainable using the associative, commutative, and
+ distributive properties of unsaturated arithmetic.
+The column of numbers on the left represents an initial permutation of the
+ input DCT coefficients.
+The column on the right represents the unpermuted output.
+One can be obtained by bit-reversing the 3-bit binary representation of the
+ other.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{llr}\toprule
+$\locvar{C}i$  & $\locvar{S}j$ & Value   \\\midrule
+$\locvar{C1}$  & $\locvar{S7}$ & $64277$ \\
+$\locvar{C2}$  & $\locvar{S6}$ & $60547$ \\
+$\locvar{C3}$  & $\locvar{S5}$ & $54491$ \\
+$\locvar{C4}$  & $\locvar{S4}$ & $46341$ \\
+$\locvar{C5}$  & $\locvar{S3}$ & $36410$ \\
+$\locvar{C6}$  & $\locvar{S2}$ & $25080$ \\
+$\locvar{C7}$  & $\locvar{S1}$ & $12785$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{16-bit Approximations of Sines and Cosines}
+\label{tab:dct-consts}
+\end{table}
+
+\begin{enumerate}
+\item
+Assign $\locvar{T}[0]$ the value $\bitvar{Y}[0]+\bitvar{Y}[4]$.
+\item
+Truncate $\locvar{T}[0]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[0]$ the value
+ $\locvar{C4}*\locvar{T}[0]>>16$.
+\item
+Assign $\locvar{T}[1]$ the value $\bitvar{Y}[0]-\bitvar{Y}[4]$.
+\item
+Truncate $\locvar{T}[1]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[1]$ the value $\locvar{C4}*\locvar{T}[1]>>16$.
+\item
+Assign $\locvar{T}[2]$ the value $(\locvar{C6}*\bitvar{Y}[2]>>16)-
+ (\locvar{S6}*\bitvar{Y}[6]>>16)$.
+\item
+Assign $\locvar{T}[3]$ the value $(\locvar{S6}*\bitvar{Y}[2]>>16)+
+ (\locvar{C6}*\bitvar{Y}[6]>>16)$.
+\item
+Assign $\locvar{T}[4]$ the value $(\locvar{C7}*\bitvar{Y}[1]>>16)-
+ (\locvar{S7}*\bitvar{Y}[7]>>16)$.
+\item
+Assign $\locvar{T}[5]$ the value $(\locvar{C3}*\bitvar{Y}[5]>>16)-
+ (\locvar{S3}*\bitvar{Y}[3]>>16)$.
+\item
+Assign $\locvar{T}[6]$ the value $(\locvar{S3}*\bitvar{Y}[5]>>16)+
+ (\locvar{C3}*\bitvar{Y}[3]>>16)$.
+\item
+Assign $\locvar{T}[7]$ the value $(\locvar{S7}*\bitvar{Y}[1]>>16)+
+ (\locvar{C7}*\bitvar{Y}[7]>>16)$.
+\item
+Assign \locvar{R} the value $\locvar{T}[4]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[4]-\locvar{T}[5]$.
+\item
+Truncate $\locvar{T}[5]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{C4}*\locvar{T}[5]>>16$.
+\item
+Assign $\locvar{T}[4]$ the value $\locvar{R}$.
+\item
+Assign \locvar{R} the value $\locvar{T}[7]+\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{T}[7]-\locvar{T}[6]$.
+\item
+Truncate $\locvar{T}[6]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{C4}*\locvar{T}[6]>>16$.
+\item
+Assign $\locvar{T}[7]$ the value $\locvar{R}$.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[3]$ the value $\locvar{T}[0]-\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[2]$
+\item
+Assign $\locvar{T}[2]$ the value $\locvar{T}[1]-\locvar{T}[2]$
+\item
+Assign $\locvar{T}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[6]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[6]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[7]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[6]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[2]+\locvar{T}[5]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[2]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[3]+\locvar{T}[4]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[3]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[3]-\locvar{T}[4]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[4]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[2]-\locvar{T}[5]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[5]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]-\locvar{T}[6]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[6]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]-\locvar{T}[7]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[7]$ the value \locvar{R}.
+\end{enumerate}
+
+\subsubsection{The 2D Inverse DCT}
+\label{sub:2d-idct}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DQC}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              14 & Yes & A $64$-element array of dequantized
+ DCT coefficients in natural order (cf. Section~\ref{sec:dct-coeffs}). \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RES}   & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                              16 & Yes & An $8\times 8$ array containing the
+ decoded residual for the current block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci}     & Integer &  3 & No  & The column index. \\
+\locvar{\ri}     & Integer &  3 & No  & The row index. \\
+\locvar{Y}       & \multicolumn{1}{p{40pt}}{Integer Array} &
+                             16 & Yes & An 8-element array of 1D iDCT input
+ values. \\
+\locvar{X}       & \multicolumn{1}{p{40pt}}{Integer Array} &
+                             16 & Yes & An 8-element array of 1D iDCT output
+ values. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies the 1D inverse DCT transform 16 times to a block of
+ dequantized coefficients: once for each of the 8 rows, and once for each of
+ the 8 columns of the result.
+Note that the coordinate system used for the columns is the same right-handed
+ coordinate system used by the rest of Theora.
+Thus, the column is indexed from bottom to top, not top to bottom.
+The final values are divided by sixteen, rounding with ties rounded towards
+ postive infinity.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+For each value of \locvar{\ci} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\locvar{Y}[\locvar{\ci}]$ the value
+ $\bitvar{DQC}[\locvar{\ri}*8+\locvar{\ci}]$.
+\end{enumerate}
+\item
+Compute \locvar{X}, the 1D inverse DCT of \locvar{Y} using the procedure
+ described in Section~\ref{sub:1d-idct}.
+\item
+For each value of $\locvar{\ci}$ from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$ the value
+ $\locvar{X}[\locvar{\ci}]$.
+\end{enumerate}
+\end{enumerate}
+\item
+For each value of \locvar{\ci} from 0 to 7:
+\begin{enumerate}
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\locvar{Y}[\locvar{\ri}]$ the value
+ $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$.
+\end{enumerate}
+\item
+Compute \locvar{X}, the 1D inverse DCT of \locvar{Y} using the procedure
+ described in Section~\ref{sub:1d-idct}.
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$ the value
+ $(\locvar{X}[\locvar{\ri}]+8)>>4$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The 1D Forward DCT (Non-Normative)}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{X}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              14 & Yes & An 8-element array of input values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{Y}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & An 8-element array of DCT
+ coefficients. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{T}        & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              16 & Yes & An 8-element array containing the
+ current value of each signal line. \\
+\locvar{R}        & Integer & 16 & Yes & A temporary value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The forward transform used in the encoder is not mandated by this standard as
+ the inverse one is.
+Precise equivalence in the inverse transform alone is all that is required to
+ guarantee that there is no mismatch in the prediction loop between encoder and
+ any compliant decoder implementation.
+However, a forward transform is provided here as a convenience for implementing
+ an encoder.
+This is the version of the transform used by Xiph.org's Theora encoder, which
+ is the same as that used by VP3.
+Like the inverse DCT, it is first applied to each row, and then applied to each
+ column of the result.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{fdct}
+\end{center}
+\caption{Signal Flow Graph for the 1D Forward DCT}
+\label{fig:fdct}
+\end{figure}
+
+The signal flow graph for the forward transform is given in
+ Figure~\ref{fig:fdct}.
+It is largely the reverse of the flow graph given for the inverse DCT.
+It is important to note that the signs on the constants in the rotations have
+ changed, and the \locvar{C4} scale factors on one of the lower butterflies now
+ appear on the opposite side.
+The column of numbers on the left represents the unpermuted input, and the
+ column on the right the permuted output DCT coefficients.
+
+A proper division by $2^{16}$ is done after the multiplications instead of a
+ shift in the forward transform.
+This can be implemented quickly by adding an offset of $\hex{FFFF}$ if the
+ number is negative, and then shifting as before.
+This slightly increases the computational complexity of the transform.
+Unlike the inverse DCT, 16-bit registers and a $16\times16\rightarrow32$ bit
+ multiply are sufficient to avoid any overflow, so long as the input is in the
+ range $-6270\ldots 6270$, which is larger than required.
+
+\begin{enumerate}
+\item
+Assign $\locvar{T}[0]$ the value $\bitvar{X}[0]+\bitvar{X}[7]$.
+\item
+Assign $\locvar{T}[1]$ the value $\bitvar{X}[1]+\bitvar{X}[6]$.
+\item
+Assign $\locvar{T}[2]$ the value $\bitvar{X}[2]+\bitvar{X}[5]$.
+\item
+Assign $\locvar{T}[3]$ the value $\bitvar{X}[3]+\bitvar{X}[4]$.
+\item
+Assign $\locvar{T}[4]$ the value $\bitvar{X}[3]-\bitvar{X}[4]$.
+\item
+Assign $\locvar{T}[5]$ the value $\bitvar{X}[2]-\bitvar{X}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value $\bitvar{X}[1]-\bitvar{X}[6]$.
+\item
+Assign $\locvar{T}[7]$ the value $\bitvar{X}[0]-\bitvar{X}[7]$.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[3]$ the value $\locvar{T}[0]-\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[2]$.
+\item
+Assign $\locvar{T}[2]$ the value $\locvar{T}[1]-\locvar{T}[2]$.
+\item
+Assign $\locvar{T}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[6]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value
+ $(\locvar{C4}*(\locvar{T}[6]+\locvar{T}[5]))//16$.
+\item
+Assign $\locvar{T}[5]$ the value $(\locvar{C4}*\locvar{R})//16$.
+\item
+Assign \locvar{R} the value $\locvar{T}[4]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[4]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[4]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[7]+\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{T}[7]-\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[7]$ the value \locvar{R}.
+\item
+Assign $\bitvar{Y}[0]$ the value
+ $(\locvar{C4}*(\locvar{T}[0]+\locvar{T}[1]))//16$.
+\item
+Assign $\bitvar{Y}[4]$ the value
+ $(\locvar{C4}*(\locvar{T}[0]-\locvar{T}[1]))//16$.
+\item
+Assign $\bitvar{Y}[2]$ the value
+ $((\locvar{S6}*\locvar{T}[3])//16)+
+ ((\locvar{C6}*\locvar{T}[2])//16)$.
+\item
+Assign $\bitvar{Y}[6]$ the value
+ $((\locvar{C6}*\locvar{T}[3])//16)-
+ ((\locvar{S6}*\locvar{T}[2])//16)$.
+\item
+Assign $\bitvar{Y}[1]$ the value
+ $((\locvar{S7}*\locvar{T}[7])//16)+
+ ((\locvar{C7}*\locvar{T}[4])//16)$.
+\item
+Assign $\bitvar{Y}[5]$ the value
+ $((\locvar{S3}*\locvar{T}[6])//16)+
+ ((\locvar{C3}*\locvar{T}[5])//16)$.
+\item
+Assign $\bitvar{Y}[3]$ the value
+ $((\locvar{C3}*\locvar{T}[6])//16)-
+ ((\locvar{S3}*\locvar{T}[5])//16)$.
+\item
+Assign $\bitvar{Y}[7]$ the value
+ $((\locvar{C7}*\locvar{T}[7])//16)-
+ ((\locvar{S7}*\locvar{T}[4])//16)$.
+\end{enumerate}
+
+\subsection{The Complete Reconstruction Algorithm}
+\label{sub:recon}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE}   & \multicolumn{1}{p{40pt}}{Integer array} &
+                               16 & No  & A 64-element array of scale values
+ for AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE}   & \multicolumn{1}{p{40pt}}{Integer array} &
+                               16 & No  & A 64-element array of scale values
+ for the DC coefficient for each \qi\ value. \\
+\bitvar{BMS}       & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                                8 & No  & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}      & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                                6 & No  & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES}   & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                                6 & No  & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS}    & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                                9 & No  & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{RPYW}      & Integer & 20 & No  & The width of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPYH}      & Integer & 20 & No  & The height of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPCW}      & Integer & 20 & No  & The width of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{RPCH}      & Integer & 20 & No  & The height of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{GOLDREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bitvar{NBS}       & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}    & \multicolumn{1}{p{40pt}}{Integer Array} &
+                                1 & No  & An \bitvar{NBS}-element array of
+ flags indicating which blocks are coded. \\
+\bitvar{MBMODES}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                                3 & No  & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{MVECTS}    & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+                                6 & Yes & An \bitvar{NBS}-element array of
+ motion vectors for each block. \\
+\bitvar{COEFFS}    & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{NCOEFFS}   & \multicolumn{1}{p{40pt}}{Integer Array} &
+                                7 & No  & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{QIS}       & \multicolumn{1}{p{40pt}}{Integer array} &
+                                6 & No  & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bitvar{QIIS}      & \multicolumn{1}{p{40pt}}{Integer Array} &
+                                2 & No  & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{RPW}       & Integer & 20 & No  & The width of the current plane of the
+ current reference frame in pixels. \\
+\locvar{RPH}       & Integer & 20 & No  & The height of the current plane of
+ the current reference frame in pixels. \\
+\locvar{REFP}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the current reference
+ frame. \\
+\locvar{BX}        & Integer & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\locvar{BY}        & Integer & 20 & No  & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\locvar{MVX}       & Integer &  5 & No  & The horizontal component of the first
+ whole-pixel motion vector. \\
+\locvar{MVY}       & Integer &  5 & No  & The vertical component of the first
+ whole-pixel motion vector. \\
+\locvar{MVX2}      & Integer &  5 & No  & The horizontal component of the second
+ whole-pixel motion vector. \\
+\locvar{MVY2}      & Integer &  5 & No  & The vertical component of the second
+ whole-pixel motion vector. \\
+\locvar{PRED}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & An $8\times 8$ array of predictor
+ values to use for the current block. \\
+\locvar{RES}       & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               16 & Yes & An $8\times 8$ array containing the
+ decoded residual for the current block. \\
+\locvar{QMAT}      & \multicolumn{1}{p{40pt}}{Integer array} &
+                               16 & No  & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\locvar{DC}        & Integer & 29 & Yes & The dequantized DC coefficient of a
+ block. \\
+\locvar{P}         & Integer & 17 & Yes & A reconstructed pixel value. \\
+\locvar{\bi}       & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\locvar{\mbi}      & Integer & 32 & No  & The index of the macro block
+ containing block \locvar{\bi}. \\
+\locvar{\pli}      & Integer &  2 & No  & The color plane index of the current
+ block. \\
+\locvar{\rfi}      & Integer &  2 & No  & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\locvar{\idx{bx}}  & Integer &  3 & No  & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}}  & Integer &  3 & No  & The vertical pixel index in the
+ block. \\
+\locvar{\qti}      & Integer &  1 & No  & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\locvar{\idx{qi0}} & Integer &  6 & No  & The quantization index of the DC
+ coefficient. \\
+\locvar{\qi}       & Integer &  6 & No  & The quantization index of the AC
+ coefficients. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This section takes the decoded packet data and uses the previously defined
+ procedures to reconstruct each block of the current frame.
+For coded blocks, a predictor is formed using the coding mode and, if
+ applicable, the motion vector, and then the residual is computed from the
+ quantized DCT coefficients.
+For uncoded blocks, the contents of the co-located block are copied from the
+ previous frame and the residual is cleared to zero.
+Then the predictor and residual are added, and the result clamped to the range
+ $0\ldots 255$ and stored in the current frame.
+
+In the special case that a block contains only a DC coefficient, the
+ dequantization and inverse DCT transform is skipped.
+Instead the constant pixel value for the entire block is computed in one step.
+Note that the truncation of intermediate operations is omitted and the final
+ rounding is slightly different in this case.
+The check for whether or not the block contains only a DC coefficient is based
+ on the coefficient count returned from the token decode procedure of
+ Section~\ref{sec:dct-decode}, and not by checking to see if the remaining
+ coefficient values are zero.
+Also note that even when the coefficient count indicates the block contains
+ zero coefficients, the DC coefficient is still processed, as undoing DC
+ prediction might have made it non-zero.
+
+After this procedure, the frame is completely reconstructed, but before it can
+ be used as a reference frame, a loop filter must be run over it to help reduce
+ blocking artifacts.
+This is detailed in Section~\ref{sec:loopfilter}.
+
+\begin{enumerate}
+\item
+Assign \locvar{\idx{qi0}} the value $\bitvar{QIS}[0]$.
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$:
+\begin{enumerate}
+\item
+Assign \locvar{\pli} the index of the color plane block \locvar{\bi} belongs
+ to.
+\item
+Assign \locvar{BX} the horizontal pixel index of the lower-left corner of block
+ \locvar{\bi}.
+\item
+Assign \locvar{BY} the vertical pixel index of the lower-left corner of block
+ \locvar{\bi}.
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \locvar{\bi}.
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is 1 (INTRA), assign \locvar{\qti} the
+ value $0$.
+\item
+Otherwise, assign \locvar{\qti} the value $1$.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\item
+If \locvar{\rfi} is zero, compute \locvar{PRED} using the procedure given in
+ Section~\ref{sub:predintra}.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{REFP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:refp} corresponding to current value of \locvar{\rfi} and
+ \locvar{\pli}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cclll}\toprule
+\locvar{\rfi} & \locvar{\pli} &
+\locvar{REFP} & \locvar{RPW} & \locvar{RPH} \\\midrule
+$1$ & $0$ & \bitvar{PREVREFY}  & \bitvar{RPYW} & \bitvar{RPYH} \\
+$1$ & $1$ & \bitvar{PREVREFCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$1$ & $2$ & \bitvar{PREVREFCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$ & $0$ & \bitvar{GOLDREFY}  & \bitvar{RPYW} & \bitvar{RPYH} \\
+$2$ & $1$ & \bitvar{GOLDREFCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$ & $2$ & \bitvar{GOLDREFCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reference Planes and Sizes for Each \locvar{\rfi} and \locvar{\pli}}
+\label{tab:refp}
+\end{table}
+
+\item
+Assign \locvar{MVX} the value
+\begin{equation*}
+ \left\lfloor\lvert\bitvar{MVECTS}[\locvar{\bi}]_x\rvert\right\rfloor*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_x).
+\end{equation*}
+\item
+Assign \locvar{MVY} the value
+\begin{equation*}
+ \left\lfloor\lvert\bitvar{MVECTS}[\locvar{\bi}]_y\rvert\right\rfloor*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_y).
+\end{equation*}
+\item
+Assign \locvar{MVX2} the value
+\begin{equation*}
+ \left\lceil\lvert\bitvar{MVECTS}[\locvar{\bi}]_x\rvert\right\rceil*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_x).
+\end{equation*}
+\item
+Assign \locvar{MVY2} the value
+\begin{equation*}
+ \left\lceil\lvert\bitvar{MVECTS}[\locvar{\bi}]_y\rvert\right\rceil*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_y).
+\end{equation*}
+\item
+If \locvar{MVX} equals \locvar{MVX2} and \locvar{MVY} equals \locvar{MVY2},
+ use the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH}, \locvar{BX},
+ \locvar{BY}, \locvar{MVX}, and \locvar{MVY}, compute \locvar{PRED} using the
+ procedure given in Section~\ref{sub:predfullpel}.
+\item
+Otherwise, use the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH},
+ \locvar{BX}, \locvar{BY}, \locvar{MVX}, \locvar{MVY}, \locvar{MVX2}, and
+ \locvar{MVY2} to compute \locvar{PRED} using the procedure given in
+ Section~\ref{sub:predhalfpel}.
+\end{enumerate}
+\item
+If $\bitvar{NCOEFFS}[\locvar{\bi}]$ is less than 2:
+\begin{enumerate}
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS}, \\
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \locvar{\qti}, \locvar{\pli}, and
+ \locvar{\idx{qi0}}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the DC quantization matrix \locvar{QMAT}.
+\item
+Assign \locvar{DC} the value
+\begin{equation*}
+ (\bitvar{COEFFS}[\bitvar{\bi}][0]*\locvar{QMAT}[0]+15)>>5.
+\end{equation*}
+\item
+Truncate \locvar{DC} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7, assign
+ $\locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value \locvar{DC}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{\qi} the value $\bitvar{QIS}[\bitvar{QIIS}[\locvar{\bi}]]$.
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS}, \\
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \locvar{\qti}, \locvar{\pli},
+ \locvar{\idx{qi0}}, and \locvar{\qi}, compute \locvar{DQC} using the procedure
+ given in Section~\ref{sub:dequant}.
+\item
+Using \locvar{DQC}, compute \locvar{RES} using the procedure given in
+ Section~\ref{sub:2d-idct}.
+\end{enumerate}
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{\rfi} the value 1.
+\item
+Assign \locvar{REFP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:refp} corresponding to current value of \locvar{\rfi} and
+ \locvar{\pli}.
+\item
+Assign \locvar{MVX} the value 0.
+\item
+Assign \locvar{MVY} the value 0.
+\item
+Using the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH}, \locvar{BX},
+ \locvar{BY}, \locvar{MVX}, and \locvar{MVY}, compute \locvar{PRED} using the
+ procedure given in Section~\ref{sub:predfullpel}.
+This is simply a copy of the co-located block in the previous reference frame.
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7, assign
+ $\locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value 0.
+\end{enumerate}
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7:
+\begin{enumerate}
+\item
+Assign \locvar{P} the value
+ $(\locvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]+
+ \locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}])$.
+\item
+If \locvar{P} is greater than $255$, assign \locvar{P} the value $255$.
+\item
+If \locvar{P} is less than $0$, assign \locvar{P} the value $0$.
+\item
+If \locvar{\pli} equals 0, assign
+ $\bitvar{RECY}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\item
+Otherwise, if \locvar{\pli} equals 1, assign
+ $\bitvar{RECB}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\item
+Otherwise, \locvar{\pli} equals 2, so assign
+ $\bitvar{RECR}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Loop Filtering}
+\label{sec:loopfilter}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{lflim}
+\end{center}
+\caption{The loop filter response function.}
+\label{fig:lflim}
+\end{figure}
+
+The loop filter is a simple deblocking filter that is based on running a small
+ edge detecting filter over the coded block edges and adjusting the pixel
+ values by a tapered response.
+The filter response is modulated by the following non-linear function:
+\begin{align*}
+\lflim(\locvar{R},\bitvar{L})&=\left\{\begin{array}{ll}
+0,                        & \locvar{R}\le-2*\bitvar{L} \\
+-\locvar{R}-2*\bitvar{L}, & -2*\bitvar{L}<\locvar{R}\le-\bitvar{L} \\
+\locvar{R},               & -\bitvar{L}<\locvar{R}<\bitvar{L} \\
+-\locvar{R}+2*\bitvar{L}, & \bitvar{L}\le\locvar{R}<2*\bitvar{L} \\
+0,                        & 2*\bitvar{L}\le\locvar{R}
+\end{array}\right.
+\end{align*}
+Here \bitvar{L} is a limiting value equal to $\bitvar{LFLIMS}[\idx{qi0}]$.
+It defines the peaks of the function, illustrated in Figure~\ref{fig:lflim}.
+\bitvar{LFLIMS} is an array of values specified in the setup header and is
+ indexed by \idx{qi0}, the first quantization index for the frame, the one used
+ for all the DC coefficients.
+Larger values of \bitvar{L} indicate a stronger filter.
+
+\subsection{Horizontal Filter}
+\label{sub:filth}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                   8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bitvar{FX}        & Integer   & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{FY}        & Integer   & 20 & No  & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{L}         & Integer   &  7 & No  & The loop filter limit value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{R}         & Integer &  9 & Yes & The edge detector response. \\
+\locvar{P}         & Integer &  9 & Yes & A filtered pixel value. \\
+\locvar{\idx{by}}  & Integer & 20 & No  & The vertical pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies a $4$-tap horizontal filter to each row of a vertical
+ block edge.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$:
+\begin{enumerate}
+\item
+Assign \locvar{R} the value
+\begin{multline*}
+(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}]-
+ 3*\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]+\\
+ 3*\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]-
+ \bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+3]+4)>>3
+\end{multline*}
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]+
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value
+ \locvar{P}.
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]-
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value
+ \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Vertical Filter}
+\label{sub:filtv}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                   8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bitvar{FX}        & Integer   & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{FY}        & Integer   & 20 & No  & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{L}         & Integer   &  7 & No  & The loop filter limit value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{R}         & Integer &  9 & Yes & The edge detector response. \\
+\locvar{P}         & Integer &  9 & Yes & A filtered pixel value. \\
+\locvar{\idx{bx}}  & Integer & 20 & No  & The horizontal pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies a $4$-tap vertical filter to each column of a horizontal
+ block edge.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$:
+\begin{enumerate}
+\item
+Assign \locvar{R} the value
+\begin{multline*}
+(\bitvar{RECP}[\bitvar{FY}][\bitvar{FX}+\locvar{\idx{bx}}]-
+ 3*\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]+\\
+ 3*\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]-
+ \bitvar{RECP}[\bitvar{FY}+3][\bitvar{FX}+\locvar{\idx{bx}}]+4)>>3
+\end{multline*}
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]+
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value
+ \locvar{P}.
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]-
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value
+ \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Complete Loop Filter}
+\label{sub:loop-filt}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS}    & \multicolumn{1}{p{40pt}}{Integer array} &
+                              7 & No & A 64-element array of loop filter limit
+ values. \\
+\bitvar{RPYW}      & Integer & 20 & No  & The width of the $Y'$ plane of the
+ reconstruced frame in pixels. \\
+\bitvar{RPYH}      & Integer & 20 & No  & The height of the $Y'$ plane of the
+ reconstruced frame in pixels. \\
+\bitvar{RPCW}      & Integer & 20 & No  & The width of the $C_b$ and $C_r$
+ planes of the reconstruced frame in pixels. \\
+\bitvar{RPCH}      & Integer & 20 & No  & The height of the $C_b$ and $C_r$
+ planes of the reconstruced frame in pixels. \\
+\bitvar{NBS}       & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED}    & \multicolumn{1}{p{40pt}}{Integer Array} &
+                                1 & No  & An \bitvar{NBS}-element array of
+ flags indicating which blocks are coded. \\
+\bitvar{QIS}       & \multicolumn{1}{p{40pt}}{Integer array} &
+                                6 & No  & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bitvar{RECY}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB}     & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR}     & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                               8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{RPW}       & Integer & 20 & No  & The width of the current plane of the
+ reconstructed frame in pixels. \\
+\locvar{RPH}       & Integer & 20 & No  & The height of the current plane of
+ the reconstructed frame in pixels. \\
+\locvar{RECP}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reconstruced
+ frame. \\
+\locvar{BX}        & Integer & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\locvar{BY}        & Integer & 20 & No  & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\locvar{FX}        & Integer & 20 & No  & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\locvar{FY}        & Integer & 20 & No  & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\locvar{L}         & Integer &  7 & No  & The loop filter limit value. \\
+\locvar{\bi}       & Integer & 36 & No  & The index of the current block in
+ coded order. \\
+\locvar{\bj}       & Integer & 36 & No  & The index of a neighboring block in
+ coded order. \\
+\locvar{\pli}      & Integer &  2 & No  & The color plane index of the current
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure defines the order that the various block edges are filtered.
+Because each application of one of the two filters above destructively modifies
+ the contents of the reconstructed image, the precise output obtained differs
+ depending on the order that horizontal and vertical filters are applied to the
+ edges of a single block.
+The order defined here conforms to that used by VP3.
+
+\begin{enumerate}
+\item
+Assign \locvar{L} the value $\bitvar{LFLIMS}[\bitvar{QIS}[0]]$.
+\item
+For each block in {\em raster} order, with coded-order index \locvar{\bi}:
+\begin{enumerate}
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Assign \locvar{\pli} the index of the color plane block \locvar{\bi} belongs
+ to.
+\item
+Assign \locvar{RECP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:recp} corresponding to the value of \locvar{\pli}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{clll}\toprule
+\locvar{\pli} & \locvar{RECP}  & \locvar{RPW}  & \locvar{RPH}  \\\midrule
+$0$           & \bitvar{RECY}  & \bitvar{RPYW} & \bitvar{RPYH} \\
+$1$           & \bitvar{RECCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$           & \bitvar{RECCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reconstructed Planes and Sizes for Each \locvar{\pli}}
+\label{tab:recp}
+\end{table}
+
+\item
+Assign \locvar{BX} the horizontal pixel index of the lower-left corner of the
+ block \locvar{\bi}.
+\item
+Assign \locvar{BY} the vertical pixel index of the lower-left corner of the
+ block \locvar{\bi}.
+\item
+If \locvar{BX} is greater than zero:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value $(\locvar{BX}-2)$.
+\item
+Assign \locvar{FY} the value \locvar{BY}.
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ horizontal block filter to the left edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filth}.
+\end{enumerate}
+\item
+If \locvar{BY} is greater than zero:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value \locvar{BX}.
+\item
+Assign \locvar{FY} the value $(\locvar{BY}-2)$
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ vertical block filter to the bottom edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filtv}.
+\end{enumerate}
+\item
+If $(\locvar{BX}+8)$ is less than \locvar{RPW} and
+ $\bitvar{BCODED}[\locvar{\bj}]$ is zero, where \locvar{\bj} is the coded-order
+ index of the block adjacent to \locvar{\bi} on the right:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value $(\locvar{BX}+6)$.
+\item
+Assign \locvar{FY} the value \locvar{BY}.
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ horizontal block filter to the right edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filth}.
+\end{enumerate}
+\item
+If $(\locvar{BY}+8)$ is less than \locvar{RPH} and
+ $\bitvar{BCODED}[\locvar{\bj}]$ is zero, where \locvar{\bj} is the coded-order
+ index of the block adjacent to \locvar{\bi} above:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value \locvar{BX}.
+\item
+Assign \locvar{FY} the value $(\locvar{BY}+6)$
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ vertical block filter to the top edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filtv}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The original VP3 decoder implemented unrestricted motion vectors by enlarging
+ the reconstructed frame buffers and repeating the pixels on its edges into the
+ padding region.
+However, for the previous reference frame this padding ocurred before the loop
+ filter was applied, but for the golden reference frame it occurred afterwards.
+
+This means that for the previous reference frame, the padding values were
+ required to be stored separately from the main image values.
+Furthermore, even if the previous and golden reference frames were in fact the
+ same frame, they could have different padding values.
+Finally, the encoder did not apply the loop filter at all, which resulted in
+ artifacts, particularly in near-static scenes, due to prediction-loop
+ mismatch.
+This last can only be considered a bug in the VP3 encoder.
+
+Given all these things, Theora now uniformly applies the loop filter before
+ the reference frames are padded.
+This means it is possible to use the same buffer for the previous and golden
+ reference frames when they do indeed refer to the same frame.
+It also means that on architectures where memory bandwidth is limited, it is
+ possible to avoid storing padding values, and simply clamp the motion vectors
+ applied to each pixel as described in Sections~\ref{sub:predfullpel}
+ and~\ref{sub:predhalfpel}.
+This means that the predicted pixel values along the edges of the frame might
+ differ slightly between VP3 and Theora, but since the VP3 encoder did not
+ apply the loop filter in the first place, this is not likely to impose any
+ serious compatibility issues.
+
+\section{Complete Frame Decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FMBW}      & Integer & 16 & No  & The width of the frame in macro
+ blocks. \\
+\bitvar{FMBH}      & Integer & 16 & No  & The height of the frame in macro
+ blocks. \\
+\bitvar{NSBS}      & Integer & 32 & No  & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS}       & Integer & 36 & No  & The total number of blocks in a
+ frame. \\
+\bitvar{NMBS}      & Integer & 32 & No  & The total number of macro blocks in a
+ frame. \\
+\bitvar{FRN}       & Integer & 32 & No  & The frame-rate numerator. \\
+\bitvar{FRD}       & Integer & 32 & No  & The frame-rate denominator. \\
+\bitvar{PARN}      & Integer & 24 & No  & The pixel aspect-ratio numerator. \\
+\bitvar{PARD}      & Integer & 24 & No  & The pixel aspect-ratio
+ denominator. \\
+\bitvar{CS}        & Integer &  8 & No  & The color space. \\
+\bitvar{PF}        & Integer &  2 & No  & The pixel format. \\
+\bitvar{NOMBR}     & Integer & 24 & No  & The nominal bitrate of the stream, in
+ bits per second. \\
+\bitvar{QUAL}      & Integer &  6 & No  & The quality hint. \\
+\bitvar{KFGSHIFT}  & Integer &  5 & No  & The amount to shift the key frame
+ number by in the granule position. \\
+\bitvar{LFLIMS}    & \multicolumn{1}{p{40pt}}{Integer array} &
+                                7 & No  & A 64-element array of loop filter
+ limit values. \\
+\bitvar{ACSCALE}   & \multicolumn{1}{p{40pt}}{Integer array} &
+                               16 & No  & A 64-element array of scale values
+ for AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE}   & \multicolumn{1}{p{40pt}}{Integer array} &
+                               16 & No  & A 64-element array of scale values
+ for the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS}      & Integer & 10 & No  & The number of base matrices. \\
+\bitvar{BMS}       & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                                8 & No  & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS}      & \multicolumn{1}{p{50pt}}{2D Integer array} &
+                                6 & No  & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES}   & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                                6 & No  & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values will be used. \\
+\bitvar{QRBMIS}    & \multicolumn{1}{p{50pt}}{3D Integer array} &
+                                9 & No  & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values will be used. \\
+\bitvar{HTS}       & \multicolumn{3}{l}{Huffman table array}
+                                        & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bitvar{GOLDREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY}      & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB}     & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed
+ frame. \\
+\bitvar{RECCR}     & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed
+ frame. \\
+\bitvar{GOLDREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                                8 & No  & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{FTYPE}   & Integer &  1 & No  & The frame type. \\
+\locvar{NQIS}    & Integer &  2 & No  & The number of \qi\ values. \\
+\locvar{QIS}     & \multicolumn{1}{p{40pt}}{Integer array} &
+                              6 & No  & An \locvar{NQIS}-element array of
+ \qi\ values. \\
+\locvar{BCODED}  & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              1 & No  & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\locvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              3 & No  & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\locvar{MVECTS}  & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+                              6 & Yes & An \bitvar{NBS}-element array of motion
+ vectors for each block. \\
+\locvar{QIIS}    & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              2 & No  & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\locvar{COEFFS}  & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+                             16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\locvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+                              7 & No  & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{RPYW}    & Integer & 20 & No  & The width of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPYH}    & Integer & 20 & No  & The height of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPCW}    & Integer & 20 & No  & The width of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{RPCH}    & Integer & 20 & No  & The height of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\locvar{\bi}     & Integer & 36 & No  & The index of the current block in coded
+ order. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure uses all the procedures defined in the previous section of this
+ chapter to decode and reconstruct a complete frame.
+It takes as input values decoded from the headers, as well as the current
+ reference frames.
+As output, it gives the uncropped, reconstructed frame.
+This should be cropped to picture region before display.
+As a special case, a 0-byte packet is treated exactly like an inter frame with
+ no coded blocks.
+
+\begin{enumerate}
+\item
+If the size of the data packet is non-zero:
+\begin{enumerate}
+\item
+Decode the frame header values \locvar{FTYPE}, \locvar{NQIS}, and \locvar{QIS}
+ using the procedure given in Section~\ref{sub:frame-header}.
+\item
+Using \locvar{FTYPE}, \bitvar{NSBS}, and \bitvar{NBS}, decode the list of coded
+ block flags into \locvar{BCODED} using the procedure given in
+ Section~\ref{sub:coded-blocks}.
+\item
+Using \locvar{FTYPE}, \bitvar{NMBS}, \bitvar{NBS}, and \bitvar{BCODED}, decode
+ the macro block coding modes into \locvar{MBMODES} using the procedure given
+ in Section~\ref{sub:mb-modes}.
+\item
+If \locvar{FTYPE} is non-zero (inter frame), using \bitvar{PF}, \bitvar{NMBS},
+ \locvar{MBMODES}, \bitvar{NBS}, and \locvar{BCODED}, decode the motion vectors
+ into \locvar{MVECTS} using the procedure given in Section~\ref{sub:mv-decode}.
+\item
+Using \bitvar{NBS}, \locvar{BCODED}, and \locvar{NQIS}, decode the block-level
+ \qi\ values into \locvar{QIIS} using the procedure given in
+ Section~\ref{sub:block-qis}.
+\item
+Using \bitvar{NBS}, \bitvar{NMBS}, \locvar{BCODED}, and \bitvar{HTS}, decode
+ the DCT coefficients into \locvar{NCOEFFS} and \locvar{NCOEFFS} using the
+ procedure given in Section~\ref{sub:dct-coeffs}.
+\item
+Using \locvar{BCODED} and \locvar{MBMODES}, undo the DC prediction on the DC
+ coefficients stored in \locvar{COEFFS} using the procedure given in
+ Section~\ref{sub:dc-pred-undo}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{FTYPE} the value 1 (inter frame).
+\item
+Assign \locvar{NQIS} the value 1.
+\item
+Assign $\locvar{QIS}[0]$ the value 63.
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$, assign
+ $\locvar{BCODED}[\locvar{\bi}]$ the value zero.
+\end{enumerate}
+\item
+Assign \locvar{RPYW} and \locvar{RPYH} the values $(16*\bitvar{FMBW})$ and
+ $(16*\bitvar{FMBH})$, respectively.
+\item
+Assign \locvar{RPCW} and \locvar{RPCH} the values from the row of
+ Table~\ref{tab:rpcwh-for-pf} corresponding to \bitvar{PF}.
+
+\begin{table}[tb]
+\begin{center}
+\begin{tabular}{crr}\toprule
+\bitvar{PF} & \multicolumn{1}{c}{\locvar{RPCW}}
+                                 & \multicolumn{1}{c}{\locvar{RPCH}} \\\midrule
+$0$         &  $8*\bitvar{FMBW}$ &  $8*\bitvar{FMBH}$ \\
+$2$         &  $8*\bitvar{FMBW}$ & $16*\bitvar{FMBH}$ \\
+$3$         & $16*\bitvar{FMBW}$ & $16*\bitvar{FMBH}$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Width and Height of Chroma Planes for each Pixel Format}
+\label{tab:rpcwh-for-pf}
+\end{table}
+
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{NBS}, \locvar{BCODED},
+ \locvar{MBMODES}, \locvar{MVECTS}, \locvar{COEFFS}, \locvar{NCOEFFS},
+ \locvar{QIS}, \locvar{QIIS}, \locvar{RPYW}, \locvar{RPYH}, \locvar{RPCW},
+ \locvar{RPCH}, \bitvar{GOLDREFY}, \bitvar{GOLDREFCB}, \bitvar{GOLDREFCR},
+ \bitvar{PREVREFY}, \bitvar{PREVREFCB}, and \bitvar{PREVREFCR}, reconstruct the
+ complete frame into \bitvar{RECY}, \bitvar{RECCB}, and \bitvar{RECCR} using
+ the procedure given in Section~\ref{sub:recon}.
+\item
+Using \bitvar{LFLIMS}, \locvar{RPYW}, \locvar{RPYH}, \locvar{RPCW},
+ \locvar{RPCH}, \bitvar{NBS}, \locvar{BCODED}, and \locvar{QIS}, apply the loop
+ filter to the reconstructed frame in \bitvar{RECY}, \bitvar{RECCB}, and
+ \bitvar{RECCR} using the procedure given in Section~\ref{sub:loop-filt}.
+\item
+If \locvar{FTYPE} is zero (intra frame), assign \bitvar{GOLDREFY},
+ \bitvar{GOLDREFCB}, and \bitvar{GOLDREFCR} the values \bitvar{RECY},
+ \bitvar{RECCB}, and \bitvar{RECCR}, respectively.
+\item
+Assign \bitvar{PREVREFY}, \bitvar{PREVREFCB}, and \bitvar{PREVREFCR} the values
+ \bitvar{RECY}, \bitvar{RECCB}, and \bitvar{RECCR}, respectively.
+\end{enumerate}
+
+%\backmatter
+\appendix
+
+\chapter{Ogg Bitstream Encapsulation}
+\label{app:oggencapsulation}
+
+\section{Overview}
+
+This document specifies the embedding or encapsulation of Theora packets
+ in an Ogg transport stream.
+
+Ogg is a stream oriented wrapper for coded, linear time-based data.
+It provides syncronization, multiplexing, framing, error detection and
+ seeking landmarks for the decoder and complements the raw packet format
+ used by the Theora codec.
+
+This document assumes familiarity with the details of the Ogg standard.
+The Xiph.org documentation provides an overview of the Ogg transport stream
+ format at \url{http://www.xiph.org/ogg/doc/oggstream.html} and a detailed
+ description at \url{http://www.xiph.org/ogg/doc/framing.html}.
+The format is also defined in RFC~3533 \cite{rfc3533}.
+While Theora packets can be embedded in a wide variety of media
+ containers and streaming mechanisms, the Xiph.org Foundation
+ recommends Ogg as the native format for Theora video in file-oriented
+ storage and transmission contexts.
+
+\subsection{MIME type}
+
+The generic MIME type of any Ogg file is {\tt application/ogg}.
+The specific MIME type for the Ogg Theora profile documented here
+is {\tt video/ogg}. This is the MIME type recommended for files
+conforming to this appendix. The recommended filename extension
+is {\tt .ogv}.
+
+Outside of an encapsulation, the mime type {\tt video/theora} may
+ be used to refer specifically to the Theora compressed video stream.
+
+\section{Embedding in a logical bitstream}
+
+Ogg separates the concept of a {\em logical bitstream} consisting of the 
+ framing of a particular sequence of packets and complete within itself 
+ from the {\em physical bitstream} which may consist either of a single
+ logical bitstream or a number of logical bitstreams multiplexed
+ together.
+This section specifies the embedding of Theora packets in a logical Ogg
+ bitstream.
+The mapping of Ogg Theora logical bitstreams into a multiplexed physical Ogg
+ stream is described in the next section.
+
+\subsection{Headers}
+
+The initial identification header packet appears by itself in a 
+ single Ogg page.
+This page defines the start of the logical stream and MUST have
+ the `beginning of stream' flag set.
+
+The second and third header packets (comment metadata and decoder
+ setup data) can together span one or more Ogg pages.
+If there are additional non-normative header packets, they MUST be
+ included in this sequence of pages as well.
+The comment header packet MUST begin the second Ogg page in the logical
+ bitstream, and there MUST be a page break between the last header
+ packet and the first frame data packet.
+
+These two page break requirements facilitate stream identification and
+ simplify header acquisition for seeking and live streaming applications.
+
+All header pages MUST have their granule position field set to zero.
+
+\subsection{Frame data}
+
+The first frame data packet in a logical bitstream MUST begin a new Ogg 
+ page.
+All other data packets are placed one at a time into Ogg pages
+ until the end of the stream.
+Packets can span pages and multiple packets can be placed within any
+ one page.
+The last page in the logical bitstream SHOULD have its 
+ 'end of stream' flag set to indicate complete transmission
+ of the available video.
+
+Frame data pages MUST be marked with a granule position corresponding to
+ the end of the display interval of the last frame/packet that finishes 
+ in that page. See the next section for details.
+
+\subsection{Granule position}
+
+Data packets are marked by a granulepos derived from the count of decodable
+frames after that packet is processed. The field itself is divided into two
+sections, the width of the less significant section being given by the KFGSHIFT
+parameter decoded from the identification header 
+(Section~\ref{sec:idheader}).
+The more significant portion of the field gives the count of coded 
+frames after the coding of the last keyframe in stream, and the less 
+significant portion gives the count of frames since the last keyframe.
+Thus a stream would begin with a split granulepos of $1|0$ (a keyframe),
+followed by $1|1$, $1|2$, $1|3$, etc. Around a  keyframe in the 
+middle of the stream the granulepos sequence might be $1234|35$, 
+$1234|36$, $1234|37$, $1271|0$ (for the keyframe), $1271|1$, and so
+on. In this way the granulepos field increased monotonically as required 
+by the Ogg format, but contains information necessary to efficiently 
+find the previous keyframe to continue decoding after a seek.
+
+Prior to bitstream version 3.2.1, data packets were marked by a 
+granulepos derived from the index of the frame being decoded,
+rather than the count. That is they marked the beginning of the
+display interval of a frame rather than the end. Such streams
+have the VREV field of the identification header set to `0' 
+instead of `1'. They can be interpreted according to the description
+above by adding 1 to the more signification field of the split 
+granulepos when VREV is less than 1.
+
+\section{Multiplexed stream mapping}
+
+Applications supporting Ogg Theora must support Theora bitstreams
+ multiplexed with compressed audio data in the Vorbis I and Speex
+ formats, and should support Ogg-encapsulated MNG graphics for overlays.
+
+Multiple audio and video bitstreams may be multiplexed together.
+How playback of multiple/alternate streams is handled is up to the
+ application.
+Some conventions based on included metadata aide interoperability
+ in this respect.
+%TODO: describe multiple vs. alternate streams, language mapping
+% and reference metadata descriptions.
+
+\subsection{Chained streams}
+
+Ogg Theora decoders and playback applications MUST support both grouped
+ streams (multiplexed concurrent logical streams) and chained streams
+ (sequential concatenation of independent physical bitstreams).
+
+The number and codec data types of multiplexed streams and the decoder
+ parameters for those stream types that re-occur can all change at a
+ chaining boundary.
+A playback application MUST be prepared to handle such changes and
+ SHOULD do so smoothly with the minimum possible visible disruption.
+The specification of grouped streams below applies independently to each
+ segment of a chained bitstream.
+
+\subsection{Grouped streams}
+
+At the beginning of a multiplexed stream, the `beginning of stream'
+ pages for each logical bitstream will be grouped together.
+Within these, the first page to occur MUST be the Theora page.
+This facilitates identification of Ogg Theora files among other
+ Ogg-encapsulated content.
+A playback application must nevertheless handle streams where this
+ arrangement is not correct.
+%TBT: Then what's the point of requiring it in the spec?
+
+If there is more than one Theora logical stream, the first page should
+ be from the primary stream.
+That is, the best choice for the stream a generic player should begin
+ displaying without special user direction.
+If there is more than one audio stream, or of any other stream
+ type, the identification page of the primary stream of that type
+ should be placed before the others.
+%TBT: That's all pretty vague.
+
+After the `beginning of stream' pages, the header pages of each of
+ the logical streams MUST be grouped together before any data pages
+ occur.
+
+After all the header pages have been placed,
+ the data pages are multiplexed together.
+They should be placed in the stream in increasing order by the 
+ time equivalents of their granule position fields.
+This facilitates seeking while limiting the buffering requirements of the
+ playback demultiplexer.
+%TODO: A lot of this language is encoder-oriented.
+%TODO: We define a decoder-oriented specification.
+%TODO: The language should be changed to match.
+
+\cleardoublepage
+\chapter{VP3}
+
+\section{VP3 Compatibility}
+\label{app:vp3-compat}
+This section lists all of the encoder and decoder issues that may affect VP3
+ compatibly.
+Each is described in more detail in the text itself.
+This list is provided merely for reference.
+
+\begin{itemize}
+\item
+Bitstream headers (Section~\ref{sec:headers}).
+\begin{itemize}
+\item
+Identification header (Section~\ref{sec:idheader}).
+\begin{itemize}
+\item
+Non-multiple of 16 picture sizes.
+\item
+Standardized color spaces.
+\item
+Support for $4:4:4$ and $4:2:2$ pixel formats.
+\end{itemize}
+\item
+Setup header
+\begin{itemize}
+\item
+Loop filter limit values (Section~\ref{sub:loop-filter-limits}).
+\item
+Quantization parameters (Section~\ref{sub:quant-params}).
+\item
+Huffman tables (Section~\ref{sub:huffman-tables}).
+\end{itemize}
+\end{itemize}
+\item
+Frame header format (Section~\ref{sub:frame-header}).
+\item
+Extended long-run bit strings (Section~\ref{sub:long-run}).
+\item
+INTER\_MV\_FOUR handling of uncoded blocks (Section~\ref{sub:mb-mv-decode}).
+\item
+Block-level \qi\ values (Section~\ref{sub:block-qis}).
+\item
+Zero-length EOB runs (Section~\ref{sub:eob-token}).
+\item
+Unrestricted motion vector padding and the loop filter
+ (Section~\ref{sub:loop-filt}).
+\end{itemize}
+
+\section{Loop Filter Limit Values}
+\label{app:vp3-loop-filter-limits}
+
+The hard-coded loop filter limit values used in VP3 are defined as follows:
+\begin{align*}
+\bitvar{LFLIMS} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 30, & 25, & 20, & 20, & 15, & 15, & 14, & 14,   &      \\
+   & 13, & 13, & 12, & 12, & 11, & 11, & 10, & 10,   &      \\
+   &  9, &  9, &  8, &  8, &  7, &  7, &  7, &  7,   &      \\
+   &  6, &  6, &  6, &  6, &  5, &  5, &  5, &  5,   &      \\
+   &  4, &  4, &  4, &  4, &  3, &  3, &  3, &  3,   &      \\
+   &  2, &  2, &  2, &  2, &  2, &  2, &  2, &  2,   &      \\
+   &  0, &  0, &  0, &  0, &  0, &  0, &  0, &  0,   &      \\
+   &  0, &  0, &  0, &  0, &  0, &  0, &  0, &  0\;\ & \!\} \\
+\end{array}
+\end{align*}
+
+\section{Quantization Parameters}
+\label{app:vp3-quant-params}
+
+The hard-coded quantization parameters used by VP3 are defined as follows:
+
+\begin{align*}
+\bitvar{ACSCALE} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 500, & 450, & 400, & 370, & 340, & 310, & 285, & 265,   &      \\
+   & 245, & 225, & 210, & 195, & 185, & 180, & 170, & 160,   &      \\
+   & 150, & 145, & 135, & 130, & 125, & 115, & 110, & 107,   &      \\
+   & 100, &  96, &  93, &  89, &  85, &  82, &  75, &  74,   &      \\
+   &  70, &  68, &  64, &  60, &  57, &  56, &  52, &  50,   &      \\
+   &  49, &  45, &  44, &  43, &  40, &  38, &  37, &  35,   &      \\
+   &  33, &  32, &  30, &  29, &  28, &  25, &  24, &  22,   &      \\
+   &  21, &  19, &  18, &  17, &  15, &  13, &  12, &  10\;\ & \!\} \\
+\end{array} \\
+\bitvar{DCSCALE} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 220, & 200, & 190, & 180, & 170, & 170, & 160, & 160,   &      \\
+   & 150, & 150, & 140, & 140, & 130, & 130, & 120, & 120,   &      \\
+   & 110, & 110, & 100, & 100, &  90, &  90, &  90, &  80,   &      \\
+   &  80, &  80, &  70, &  70, &  70, &  60, &  60, &  60,   &      \\
+   &  60, &  50, &  50, &  50, &  50, &  40, &  40, &  40,   &      \\
+   &  40, &  40, &  30, &  30, &  30, &  30, &  30, &  30,   &      \\
+   &  30, &  20, &  20, &  20, &  20, &  20, &  20, &  20,   &      \\
+   &  20, &  10, &  10, &  10, &  10, &  10, &  10, &  10\;\ & \!\} \\
+\end{array}
+\end{align*}
+
+VP3 defines only a single quantization range for each quantization type and
+ color plane, and the base matrix used is constant throughout the range.
+There are three base matrices defined.
+The first is used for the $Y'$ channel of INTRA mode blocks, and the second for
+ both the $C_b$ and $C_r$ channels of INTRA mode blocks.
+The last is used for INTER mode blocks of all channels.
+
+\begin{align*}
+\bitvar{BMS} = \{ & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 16, & 11, & 10, & 16, &  24, &  40, &  51, &  61,   &       \\
+   & 12, & 12, & 14, & 19, &  26, &  58, &  60, &  55,   &       \\
+   & 14, & 13, & 16, & 24, &  40, &  57, &  69, &  56,   &       \\
+   & 14, & 17, & 22, & 29, &  51, &  87, &  80, &  62,   &       \\
+   & 18, & 22, & 37, & 58, &  68, & 109, & 103, &  77,   &       \\
+   & 24, & 35, & 55, & 64, &  81, & 104, & 113, &  92,   &       \\
+   & 49, & 64, & 78, & 87, & 103, & 121, & 120, & 101,   &       \\
+   & 72, & 92, & 95, & 98, & 112, & 100, & 103, &  99\;\ & \!\}, \\
+%\end{array} \\
+%& \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 17, & 18, & 24, & 47, & 99, & 99, & 99, & 99,   &       \\
+   & 18, & 21, & 26, & 66, & 99, & 99, & 99, & 99,   &       \\
+   & 24, & 26, & 56, & 99, & 99, & 99, & 99, & 99,   &       \\
+   & 47, & 66, & 99, & 99, & 99, & 99, & 99, & 99,   &       \\
+   & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99,   &       \\
+   & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99,   &       \\
+   & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99,   &       \\
+   & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99\;\ & \!\}, \\
+%\end{array} \\
+%& \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 16, & 16, & 16, & 20, & 24, & 28, &  32, &  40,   &            \\
+   & 16, & 16, & 20, & 24, & 28, & 32, &  40, &  48,   &            \\
+   & 16, & 20, & 24, & 28, & 32, & 40, &  48, &  64,   &            \\
+   & 20, & 24, & 28, & 32, & 40, & 48, &  64, &  64,   &            \\
+   & 24, & 28, & 32, & 40, & 48, & 64, &  64, &  64,   &            \\
+   & 28, & 32, & 40, & 48, & 64, & 64, &  64, &  96,   &            \\
+   & 32, & 40, & 48, & 64, & 64, & 64, &  96, & 128,   &            \\
+   & 40, & 48, & 64, & 64, & 64, & 96, & 128, & 128\;\ & \!\}\;\;\} \\
+\end{array}
+\end{align*}
+
+The remaining parameters simply assign these matrices to the proper quant
+ ranges.
+
+\begin{align*}
+\bitvar{NQRS}    = & \{ \{1, 1, 1\}, \{1, 1, 1\} \} \\
+\bitvar{QRSIZES} = &
+ \{ \{ \{1\}, \{1\}, \{1\} \}, \{ \{1\}, \{1\}, \{1\} \} \} \\
+\bitvar{QRBMIS}  = &
+ \{ \{ \{0, 0\}, \{1, 1\}, \{1, 1\} \}, \{ \{2, 2\}, \{2, 2\}, \{2, 2\} \} \} \\
+\end{align*}
+
+\section{Huffman Tables}
+\label{app:vp3-huffman-tables}
+
+The following tables contain the hard-coded Huffman codes used by VP3.
+There are 80 tables in all, each with a Huffman code for all 32 token values.
+The tokens are sorted by the most significant bits of their Huffman code.
+This is the same order in which they will be decoded from the setup header.
+
+\include{vp3huff}
+
+\cleardoublepage
+\chapter{Colophon}
+
+Ogg is a \href{http://www.xiph.org}{Xiph.org Foundation} effort to protect
+ essential tenets of Internet multimedia from corporate hostage-taking; Open
+ Source is the net's greatest tool to keep everyone honest.
+See \href{http://www.xiph.org/about.html}{About the Xiph.org Foundation} for
+ details.
+
+Ogg Theora is the first Ogg video codec.
+Anyone may freely use and distribute the Ogg and Theora specifications, whether
+ in private, public, or corporate capacity.
+However, the Xiph.org Foundation and the Ogg project reserve the right to set
+ the Ogg Theora specification and certify specification compliance.
+
+Xiph.org's Theora software codec implementation is distributed under a BSD-like
+ license.
+This does not restrict third parties from distributing independent
+ implementations of Theora software under other licenses.
+
+\begin{wrapfigure}{l}{0pt}
+\includegraphics[width=2.5cm]{xifish}
+\end{wrapfigure}
+
+These pages are Copyright \textcopyright{} 2004-2007 Xiph.org Foundation.
+All rights reserved.
+Ogg, Theora, Vorbis, Xiph.org Foundation and their logos are trademarks
+ (\texttrademark) of the \href{http://www.xiph.org}{Xiph.org Foundation}.
+
+This document is set in \LaTeX.
+
+
+
+\cleardoublepage
+\bibliography{spec}
+
+\end{document}