mirror of
https://github.com/etlegacy/etlegacy-libs.git
synced 2025-02-24 12:11:11 +00:00
8172 lines
320 KiB
TeX
8172 lines
320 KiB
TeX
|
\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}
|