diff options
Diffstat (limited to 'Libraries/libtheora-1.1.1/doc/spec/spec.tex')
| -rw-r--r-- | Libraries/libtheora-1.1.1/doc/spec/spec.tex | 8171 |
1 files changed, 0 insertions, 8171 deletions
diff --git a/Libraries/libtheora-1.1.1/doc/spec/spec.tex b/Libraries/libtheora-1.1.1/doc/spec/spec.tex deleted file mode 100644 index b29d4ef5..00000000 --- a/Libraries/libtheora-1.1.1/doc/spec/spec.tex +++ /dev/null @@ -1,8171 +0,0 @@ -\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} |