new trunk
authorj <j@xiph.org>
Thu, 12 Apr 2007 17:26:20 +0000 (17:26 +0000)
committerj <j@xiph.org>
Thu, 12 Apr 2007 17:26:20 +0000 (17:26 +0000)
svn path=/trunk/theora/; revision=12854

194 files changed:
AUTHORS [new file with mode: 0644]
CHANGES [new file with mode: 0644]
COPYING [new file with mode: 0644]
LICENSE [new file with mode: 0644]
Makefile.am [new file with mode: 0644]
README [new file with mode: 0644]
SConstruct [new file with mode: 0644]
autogen.sh [new file with mode: 0755]
configure.ac [new file with mode: 0644]
debian/changelog [new file with mode: 0644]
debian/control [new file with mode: 0644]
debian/copyright [new file with mode: 0644]
debian/libtheora-dev.install [new file with mode: 0644]
debian/libtheora0.install [new file with mode: 0644]
debian/rules [new file with mode: 0755]
debian/watch [new file with mode: 0644]
doc/Doxyfile.in [new file with mode: 0644]
doc/Makefile.am [new file with mode: 0644]
doc/color.html [new file with mode: 0644]
doc/draft-ietf-avt-rtp-theora-00.txt [new file with mode: 0644]
doc/draft-ietf-avt-rtp-theora-00.xml [new file with mode: 0644]
doc/draft-kerr-avt-theora-rtp-00.txt [new file with mode: 0644]
doc/draft-kerr-avt-theora-rtp-00.xml [new file with mode: 0644]
doc/python/Makefile.am [new file with mode: 0644]
doc/python/spec.txt [new file with mode: 0644]
doc/python/spec2html.py [new file with mode: 0755]
doc/python/specout.raw [new file with mode: 0644]
doc/python/testspec.ogg [new file with mode: 0644]
doc/python/testspec.orig.yuv [new file with mode: 0644]
doc/python/testspec.raw [new file with mode: 0644]
doc/python/testspec2.ogg [new file with mode: 0644]
doc/python/testspec2.orig.yuv [new file with mode: 0644]
doc/python/testspec2.raw [new file with mode: 0644]
doc/python/txt2html.py [new file with mode: 0644]
doc/python/txt2py.py [new file with mode: 0644]
doc/spec/Makefile [new file with mode: 0644]
doc/spec/fdct.fig [new file with mode: 0644]
doc/spec/hilbert-block.fig [new file with mode: 0644]
doc/spec/hilbert-mb.fig [new file with mode: 0644]
doc/spec/idct.fig [new file with mode: 0644]
doc/spec/ltablex.sty [new file with mode: 0644]
doc/spec/macroblock.fig [new file with mode: 0644]
doc/spec/pic-frame.fig [new file with mode: 0644]
doc/spec/pic_even.fig [new file with mode: 0644]
doc/spec/pic_even_odd.fig [new file with mode: 0644]
doc/spec/pic_odd.fig [new file with mode: 0644]
doc/spec/pic_odd_even.fig [new file with mode: 0644]
doc/spec/pixel420.fig [new file with mode: 0644]
doc/spec/pixel422.fig [new file with mode: 0644]
doc/spec/pixel444.fig [new file with mode: 0644]
doc/spec/raster-block.fig [new file with mode: 0644]
doc/spec/reference-frames.fig [new file with mode: 0644]
doc/spec/spec.bib [new file with mode: 0644]
doc/spec/spec.tex [new file with mode: 0644]
doc/spec/superblock.fig [new file with mode: 0644]
doc/spec/vp3huff.c [new file with mode: 0644]
doc/spec/xifish.fig [new file with mode: 0644]
doc/vp3-format.txt [new file with mode: 0644]
examples/Makefile.am [new file with mode: 0644]
examples/README_SPLAYER [new file with mode: 0644]
examples/dump_video.c [new file with mode: 0644]
examples/encoder_example.c [new file with mode: 0644]
examples/getopt.c [new file with mode: 0644]
examples/getopt.h [new file with mode: 0644]
examples/getopt1.c [new file with mode: 0644]
examples/player_example.c [new file with mode: 0644]
examples/splayer.c [new file with mode: 0644]
include/Makefile.am [new file with mode: 0644]
include/theora/Makefile.am [new file with mode: 0644]
include/theora/codec.h [new file with mode: 0644]
include/theora/theora.h [new file with mode: 0644]
include/theora/theoradec.h [new file with mode: 0644]
lib/Makefile.am [new file with mode: 0644]
lib/Version_script.in [new file with mode: 0644]
lib/cpu.c [new file with mode: 0644]
lib/cpu.h [new file with mode: 0644]
lib/dec/apiwrapper.c [new file with mode: 0644]
lib/dec/dct.h [new file with mode: 0644]
lib/dec/decinfo.c [new file with mode: 0644]
lib/dec/decint.h [new file with mode: 0644]
lib/dec/decode.c [new file with mode: 0644]
lib/dec/dequant.c [new file with mode: 0644]
lib/dec/dequant.h [new file with mode: 0644]
lib/dec/enquant.h [new file with mode: 0644]
lib/dec/fragment.c [new file with mode: 0644]
lib/dec/huffdec.c [new file with mode: 0644]
lib/dec/huffdec.h [new file with mode: 0644]
lib/dec/huffman.h [new file with mode: 0644]
lib/dec/idct.c [new file with mode: 0644]
lib/dec/idct.h [new file with mode: 0644]
lib/dec/info.c [new file with mode: 0644]
lib/dec/internal.c [new file with mode: 0644]
lib/dec/ocintrin.h [new file with mode: 0644]
lib/dec/quant.c [new file with mode: 0644]
lib/dec/quant.h [new file with mode: 0644]
lib/dec/state.c [new file with mode: 0644]
lib/dec/x86/mmxfrag.c [new file with mode: 0644]
lib/dec/x86/mmxidct.c [new file with mode: 0644]
lib/dec/x86/mmxstate.c [new file with mode: 0644]
lib/dec/x86/x86int.h [new file with mode: 0644]
lib/dec/x86/x86state.c [new file with mode: 0644]
lib/enc/block_inline.h [new file with mode: 0644]
lib/enc/blockmap.c [new file with mode: 0644]
lib/enc/codec_internal.h [new file with mode: 0644]
lib/enc/common.c [new file with mode: 0644]
lib/enc/dct.c [new file with mode: 0644]
lib/enc/dct_decode.c [new file with mode: 0644]
lib/enc/dct_encode.c [new file with mode: 0644]
lib/enc/dsp.c [new file with mode: 0644]
lib/enc/dsp.h [new file with mode: 0644]
lib/enc/encode.c [new file with mode: 0644]
lib/enc/encoder_disabled.c [new file with mode: 0644]
lib/enc/encoder_huffman.c [new file with mode: 0644]
lib/enc/encoder_huffman.h [new file with mode: 0644]
lib/enc/encoder_idct.c [new file with mode: 0644]
lib/enc/encoder_lookup.h [new file with mode: 0644]
lib/enc/encoder_quant.c [new file with mode: 0644]
lib/enc/encoder_toplevel.c [new file with mode: 0644]
lib/enc/frarray.c [new file with mode: 0644]
lib/enc/frinit.c [new file with mode: 0644]
lib/enc/hufftables.h [new file with mode: 0644]
lib/enc/mcomp.c [new file with mode: 0644]
lib/enc/misc_common.c [new file with mode: 0644]
lib/enc/pb.c [new file with mode: 0644]
lib/enc/pp.c [new file with mode: 0644]
lib/enc/pp.h [new file with mode: 0644]
lib/enc/quant_lookup.h [new file with mode: 0644]
lib/enc/reconstruct.c [new file with mode: 0644]
lib/enc/scan.c [new file with mode: 0644]
lib/enc/toplevel_lookup.h [new file with mode: 0644]
lib/enc/x86_32/dct_decode_mmx.c [new file with mode: 0644]
lib/enc/x86_32/dsp_mmx.c [new file with mode: 0644]
lib/enc/x86_32/dsp_mmxext.c [new file with mode: 0644]
lib/enc/x86_32/fdct_mmx.c [new file with mode: 0644]
lib/enc/x86_32/idct_mmx.c [new file with mode: 0644]
lib/enc/x86_32/recon_mmx.c [new file with mode: 0644]
lib/enc/x86_32_vs/dsp_mmx.c [new file with mode: 0644]
lib/enc/x86_32_vs/fdct_mmx.c [new file with mode: 0644]
lib/enc/x86_32_vs/recon_mmx.c [new file with mode: 0644]
lib/enc/x86_64/dct_decode_mmx.c [new file with mode: 0644]
lib/enc/x86_64/dsp_mmx.c [new file with mode: 0644]
lib/enc/x86_64/dsp_mmxext.c [new file with mode: 0644]
lib/enc/x86_64/fdct_mmx.c [new file with mode: 0644]
lib/enc/x86_64/idct_mmx.c [new file with mode: 0644]
lib/enc/x86_64/recon_mmx.c [new file with mode: 0644]
lib/internal.h [new file with mode: 0644]
libtheora.spec.in [new file with mode: 0644]
m4/Makefile.am [new file with mode: 0644]
m4/as-ac-expand.m4 [new file with mode: 0644]
m4/ogg.m4 [new file with mode: 0644]
m4/pkg.m4 [new file with mode: 0644]
m4/sdl.m4 [new file with mode: 0644]
m4/vorbis.m4 [new file with mode: 0644]
macosx/English.lproj/InfoPlist.strings [new file with mode: 0644]
macosx/Info.plist [new file with mode: 0644]
macosx/Theora.xcodeproj/project.pbxproj [new file with mode: 0644]
macosx/Theora_Prefix.pch [new file with mode: 0644]
symbian/bld.inf [new file with mode: 0644]
symbian/config.h [new file with mode: 0644]
symbian/theora.mmp [new file with mode: 0644]
tests/Makefile.am [new file with mode: 0644]
tests/comment-test.c [new file with mode: 0644]
tests/commentexp-test.c [new file with mode: 0644]
tests/noop.c [new file with mode: 0644]
tests/tests.h [new file with mode: 0644]
theora-uninstalled.pc.in [new file with mode: 0644]
theora.pc.in [new file with mode: 0644]
win32/VS2003/libtheora/libtheora.vcproj [new file with mode: 0644]
win32/VS2005/dump_video/dump_video.vcproj [new file with mode: 0644]
win32/VS2005/encoder_example/encoder_example.vcproj [new file with mode: 0644]
win32/VS2005/libtheora/libtheora.vcproj [new file with mode: 0644]
win32/build_theora_static.bat [new file with mode: 0755]
win32/build_theora_static_debug.bat [new file with mode: 0755]
win32/experimental/dumpvid/dumpvid.dsp [new file with mode: 0644]
win32/experimental/encoderwin/ReadMe.txt [new file with mode: 0644]
win32/experimental/encoderwin/encoderwin.dsp [new file with mode: 0644]
win32/experimental/transcoder/avi2vp3/avi2vp3.c [new file with mode: 0644]
win32/experimental/transcoder/avi2vp3/avilib.c [new file with mode: 0644]
win32/experimental/transcoder/avi2vp3/avilib.h [new file with mode: 0644]
win32/experimental/transcoder/avi2vp3/outfile.vp3 [new file with mode: 0644]
win32/experimental/transcoder/avi2vp3/vp31.avi [new file with mode: 0644]
win32/experimental/transcoder/readme.txt [new file with mode: 0644]
win32/experimental/transcoder/transcoder.dsp [new file with mode: 0644]
win32/experimental/transcoder/transcoder_example.c [new file with mode: 0644]
win32/experimental/wincompat/README.txt [new file with mode: 0644]
win32/experimental/wincompat/getopt.c [new file with mode: 0644]
win32/experimental/wincompat/getopt.h [new file with mode: 0644]
win32/experimental/wincompat/getopt_long.c [new file with mode: 0644]
win32/experimental/wincompat/unistd.h [new file with mode: 0644]
win32/getopt.c [new file with mode: 0644]
win32/getopt1.c [new file with mode: 0644]
win32/getopt_win.h [new file with mode: 0644]
win32/libtheora.def [new file with mode: 0644]
win32/theora_static.dsp [new file with mode: 0644]

diff --git a/AUTHORS b/AUTHORS
new file mode 100644 (file)
index 0000000..a144e07
--- /dev/null
+++ b/AUTHORS
@@ -0,0 +1,44 @@
+Monty <monty@xiph.org>
+       - Original VP3 port
+
+Ralph Giles
+Timothy B. Terriberry 
+       - Ongoing development
+       
+Dan B. Miller
+       - Pre alpha3 development
+       
+Wim Tayman
+Dan Lenski
+       - MMX optimized functions
+       
+Aaron Colwell
+Thomas Vander Stichele
+Jan Gerber
+Conrad Parker
+       - Bug fixes, enhancements, build systems.
+       
+Mauricio Piacentini
+       - Original win32 projects and example ports
+       - VP3->Theora transcoder
+
+Arc Riley
+       - libogg2 porting.
+
+Silvia Pfeiffer
+       - Figures for the spec
+
+Michael Smith
+Andre Pang
+calc
+ccheney
+brendan
+Edward Hervey
+Adam Moss
+Colin Ward
+Jeremy C. Reed
+Rodolphe Ortalo
+       - Bug fixes
+
+
+and other xiph.org contributors
diff --git a/CHANGES b/CHANGES
new file mode 100644 (file)
index 0000000..df6a2c9
--- /dev/null
+++ b/CHANGES
@@ -0,0 +1,99 @@
+libtheora 1.0alpha8 (unreleased)
+
+ - no changes yet -
+
+libtheora 1.0alpha7 (2006 June 20)
+
+ - Enable mmx assembly by default
+ - Avoid some relocations that caused problems on SELinux
+ - Other build fixes
+ - time testing mode (-f) for the dump_video example
+
+libtheora 1.0alpha6 (2006 May 30)
+
+ * Merge theora-mmx simd acceleration (x86_32 and x86_64)
+ * Major RTP payload specification update
+ * Minor format specification updates
+ * Fix some spurious calls to free() instead of _ogg_free()
+ * Fix invalid array indexing in PixelLineSearch()
+ * Improve robustness against invalid input
+ * General warning cleanup
+ * The offset_y member now means what every application thought it meant
+   (offset from the top). This will mean some old files (those with a 
+   non-centered image created with a buggy encoder) will display differently.
+
+libtheora 1.0alpha5 (2005 August 20)
+
+ * Fixed bitrate management bugs that caused popping and encode
+   errors
+ * Fixed a crash problem with the theora_state internals not
+   being intialized properly.
+ * new utility function:
+   - theora_granule_shift()
+ * dump_video example now makes YUV4MPEG files by default, so
+   the results can be fed back to encoder_example and similar
+   tools. The old behavior is restored through the '-r' switch.
+ * ./configure now prints a summary
+ * simple unit test of the comment api under 'make check'
+ * misc code cleanup, warning and leak fixes
+
+libtheora 1.0alpha4 (2004 December 15)
+
+ * first draft of the Theora I Format Specification
+ * API documentation generated from theora.h with Doxygen
+ * fix a double-update bug in the motion analysis
+ * apply the loop filter before filling motion vector border 
+   in the reference frame
+ * new utility functions:
+   - theora_packet_isheader(),
+   - theora_packet_iskeyframe()
+   - theora_granule_frame()
+ * optional support for building without floating point
+ * optional support for building without encode support 
+ * various build and packaging fixes
+ * pkg-config support
+ * SymbianOS build support
+
+libtheora 1.0alpha3 (2004 March 20)
+
+ UPDATE: on 2004 July 1 the Theora I bitstream format was frozen. Files
+ produced by the libtheora 1.0alpha3 reference encoder will always be
+ decodable by the Theora I spec.
+
+ * Bitstream info header FORMAT CHANGES:
+   - move the granulepos shift field to maintain byte alignment longer.
+   - reserve 5 additional bits for subsampling and interlace flags.
+ * Bitstream setup header FORMAT CHANGES:
+   - support for a range of interpolated quant matricies.
+   - include the in-loop block filter coeff.
+ * Bitsteam data packet FORMAT CHANGES:
+   - Reserve a bit for per-block Q index selection.
+   - Flip the coded image orientation for compatibility with VP3.
+     This allows lossless transcoding of VP3 content, but files
+     encoded with earlier theora releases would play upside down.
+ * example VP3 lossless transcoder
+ * optional support for libogg2
+ * timing improvements in the example player
+ * packaging and build system updates and fixes
+
+libtheora 1.0alpha2 (2003 June 9)
+
+ * bitstream FORMAT CHANGES:
+   - store the quant tables in a third setup header for
+     future encoder flexibility
+   - store the huffman tables in the third setup header
+   - add a field for marking the colorspace to the info header
+   - add crop parameters for non-multiple-of-16 frame sizes
+   - add a second vorbiscomment-style metadata header
+ * API changes to handle multiple headers with a single 
+   theora_decode_header() call, like libvorbis
+ * code cleanup and minor fixes
+ * new dump_video code example/utility
+ * experimental win32 code examples
+
+libtheora 1.0alpha1 (2002 September 25)
+
+ * First release of the theora reference implementation
+ * Port of the newly opened VP3 code to the Ogg container
+ * Rewrite of the code for portability and to use the libogg bitpacker
+
diff --git a/COPYING b/COPYING
new file mode 100644 (file)
index 0000000..3cef013
--- /dev/null
+++ b/COPYING
@@ -0,0 +1,28 @@
+Copyright (C) 2002-2005 Xiph.org Foundation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+- Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+- Neither the name of the Xiph.org Foundation nor the names of its
+contributors may be used to endorse or promote products derived from
+this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION
+OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/LICENSE b/LICENSE
new file mode 100644 (file)
index 0000000..5e5ec08
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,18 @@
+Please see the file COPYING for the copyright license for this software.
+
+In addition to and irrespective of the copyright license associated
+with this software, On2 Technologies, Inc. makes the following statement
+regarding technology used in this software:
+
+  On2 represents and warrants that it shall not assert any rights 
+  relating to infringement of On2's registered patents, nor initiate
+  any litigation asserting such rights, against any person who, or
+  entity which utilizes the On2 VP3 Codec Software, including any 
+  use, distribution, and sale of said Software; which make changes, 
+  modifications, and improvements in said Software; and to use,
+  distribute, and sell said changes as well as applications for other 
+  fields of use.
+
+This reference implementation is originally derived from the On2 VP3
+Codec Software, and the Theora video format is essentially compatible
+with the VP3 video format, consisting of a backward-compatible superset.
diff --git a/Makefile.am b/Makefile.am
new file mode 100644 (file)
index 0000000..150210b
--- /dev/null
@@ -0,0 +1,33 @@
+## Process this file with automake to produce Makefile.in
+
+AUTOMAKE_OPTIONS = foreign 1.6 dist-zip dist-bzip2
+
+SUBDIRS = lib include doc examples tests m4
+
+# we include the whole debian/ dir in EXTRA_DIST because there's a problem
+# with autotools and HFS+ MacOSX file systems that caused debian/Makefile.am
+# to pick up on the lowercase changelog file and add ChangeLog to DIST_COMMON
+# because of it, breaking make dist.  This works just as well.
+EXTRA_DIST = \
+       README CHANGES COPYING LICENSE \
+       autogen.sh win32 symbian SConstruct \
+       libtheora.spec libtheora.spec.in \
+       theora-uninstalled.pc.in
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = theora.pc
+
+dist-hook:
+       for item in $(EXTRA_DIST); do \
+         if test -d $$item; then \
+           echo -n "cleaning $$item dir for distribution..."; \
+           rm -rf `find $(distdir)/$$item -name .svn`; \
+           echo "OK"; \
+         fi; \
+       done
+
+debug:
+       $(MAKE) all CFLAGS="@DEBUG@"
+
+profile:
+       $(MAKE) all CFLAGS="@PROFILE@"
diff --git a/README b/README
new file mode 100644 (file)
index 0000000..1d257e6
--- /dev/null
+++ b/README
@@ -0,0 +1,147 @@
+-------------------------------------------------------------------------
+          The Xiph.org Foundation's libtheora 1.0alpha7 release
+-------------------------------------------------------------------------
+
+*** What is Theora?
+
+Theora is Xiph.Org's first publicly released video codec, intended
+for use within the Foundation's Ogg multimedia streaming system.
+Theora is derived directly from On2's VP3 codec; Currently the two are
+nearly identical, varying only in encapsulating decoder tables in the 
+bitstream headers, but Theora will make use of this extra freedom 
+in the future to improve over what is possible with VP3.
+
+*** Where is Theora?
+
+Theora's main site is www.theora.org.  Theora and related libraries
+can be gotten from www.theora.org or the main Xiph.Org site at
+www.xiph.org.  Development source is kept in an open subversion 
+repository, see http://theora.org/svn.html for instructions.
+
+*** What is the goal of this alpha release?
+
+The Theora bitstream format was frozen after the alpha3 release. This
+means that files produced by the alpha3 encoder will always be playable
+according to the Theora I specification.
+
+Traditionally alpha mean proof of concept, not a production-ready 
+release. However the code is very robust, ready for and indeed
+in general use. 
+
+The purpose of this release is to provide an updated testing base for 
+those interested in theora and to dissiminate more widely the changes
+we've made since the last alpha release. These include some helper
+utility functions, a draft format specification and api documentation 
+located in the doc directory.
+
+-------------------------------------------------------------------------
+Getting started with the code
+-------------------------------------------------------------------------
+
+*** What do I need to build the source?
+
+Requirements summary:
+
+  For libtheora:  
+         
+      libogg 1.1 or newer.
+      (there is optional support for libogg2, unreleased at this time)
+
+  For example encoder:
+
+      as above
+
+      libvorbis and libvorbisenc 1.0.1 or newer.
+
+  For the player only:
+
+      as above, 
+
+      SDL (Simple Direct media Layer) libraries and headers
+      OSS audio driver and development headers
+
+The provided build system is the GNU automake/autoconf system, and
+the main library, libtheora, should already build smoothly on any
+system.  Failure of libtheora to build on a GNU-enabled system is
+considered a bug; please report problems to theora-dev@xiph.org.
+
+Some windows build support is included in the win32 directory.
+
+*** How do I use the sample encoder?
+
+The sample encoder takes raw video in YUV4MPEG2 format, as used by
+lavtools, mjpeg-tools and other packages.  Snatch and MPlayer version
+0.90 and later can also export in YUV4MPEG format (more on this
+later).  The encoder take audio as WAV files.  encoder_example -h
+lists options accepted by the encoder.
+
+An easy way to get raw video and audio files is to use MPlayer as an
+export utility.  The options " -ao pcm -vo yuv4mpeg " will export a
+wav file named audiodump.wav and a YUV video file in the correct
+format for encoder_example as stream.yuv.  Be careful when exporting
+video alone; MPlayer may drop frames to 'keep up' with the audio
+timer.  The example encoder can't properly synchronize input audio and
+video file that aren't in sync to begin with.  
+
+The encoder will also take video or audio on stdin if '-' is specified
+as the input file name.
+
+*** How do I use the sample player?
+
+The sample player takes an Ogg file on standard in; the file may be
+audio alone, video alone or video with audio.  
+
+*** What other tools are available?
+
+If you're wanting to just use theora, consider the programs linked
+from http://www.theora.org/. There is playback support in a number
+of common free players, and Jan Gerber's ffmpeg2theora is an excellent
+encoding front end.
+
+-------------------------------------------------------------------------
+Troubleshooting the build process
+-------------------------------------------------------------------------
+
+*** Compile error, such as:
+
+encoder_internal.h:664: parse error before `ogg_uint16_t'
+
+This means you have version of libogg prior to 1.1. A *complete* new Ogg 
+install, libs and headers, from a new release or CVS is needed.  Don't 
+forget to re-reun autogen.sh so that autoconf sucks in the new type 
+declarations.
+
+Also be sure that there aren't multiple copies of Ogg installed in
+/usr and /usr/local; an older one might be first on the search path
+for libs and headers.
+
+*** Link error, such as:
+
+undefined reference to `oggpackB_stream'
+
+See above; you need libogg 1.1 or later.
+
+*** Link error, such as:
+
+undefined reference to `vorbis_granule_time'
+
+You need libvorbis and libvorbisenc from the 1.0.1 release or later.
+
+*** Link error, such as:
+
+/usr/lib/libSDL.a(SDL_esdaudio.lo): In function `ESD_OpenAudio':
+SDL_esdaudio.lo(.text+0x25d): undefined reference to `esd_play_stream'
+
+Be sure to use an SDL that's built to work with OSS.  If you use an
+SDL that is also built with ESD and/or ALSA support, it will try to
+suck in all those extra libraries at link time too.  That will only
+work if the extra libraries are also installed.
+
+*** Link warning, such as:
+
+libtool: link: warning: library `/usr/lib/libogg.la' was moved.
+libtool: link: warning: library `/usr/lib/libogg.la' was moved.
+
+Re-run theora/autogen.sh after an Ogg or Vorbis rebuild/reinstall
+
diff --git a/SConstruct b/SConstruct
new file mode 100644 (file)
index 0000000..59dcd16
--- /dev/null
@@ -0,0 +1,156 @@
+# SCons build specification
+# see http://www.scons.org if you do not have this tool
+from os.path import join
+import SCons
+
+# TODO: should use lamda and map to work on python 1.5
+def path(prefix, list): return [join(prefix, x) for x in list]
+
+libtheora_Sources = Split("""
+  dct_encode.c encode.c encoder_toplevel.c
+  blockmap.c
+  comment.c
+  cpu.c
+  dct.c
+  dct_decode.c
+  decode.c
+  dsp.c
+  frarray.c
+  frinit.c
+  huffman.c
+  idct.c
+  mcomp.c
+  misc_common.c
+  pb.c
+  pp.c
+  quant.c
+  reconstruct.c
+  scan.c
+  toplevel.c
+""")
+
+env = Environment()
+if env['CC'] == 'gcc':
+  env.Append(CCFLAGS=["-g", "-O2", "-Wall"])
+#  env.Append(CCFLAGS=["-g", "-Wall"])
+
+def CheckPKGConfig(context, version): 
+  context.Message( 'Checking for pkg-config... ' ) 
+  ret = context.TryAction('pkg-config --atleast-pkgconfig-version=%s' % version)[0] 
+  context.Result( ret ) 
+  return ret 
+
+def CheckPKG(context, name): 
+  context.Message( 'Checking for %s... ' % name )
+  ret = context.TryAction('pkg-config --exists %s' % name)[0]
+  context.Result( ret ) 
+  return ret
+     
+def CheckSDL(context):
+  name = "sdl-config"
+  context.Message( 'Checking for %s... ' % name )
+  ret = SCons.Util.WhereIs('sdl-config')
+  context.Result( ret ) 
+  return ret
+
+# check for appropriate inline asm support
+host_x86_32_test = """
+    int main(int argc, char **argv) {
+#if !defined(__i386__)
+  #error __i386__ not defined
+#endif
+  return 0;
+    }
+    """
+def CheckHost_x86_32(context):
+  context.Message('Checking for an x86_32 host...')
+  result = context.TryCompile(host_x86_32_test, '.c')
+  context.Result(result)
+  return result
+
+host_x86_64_test = """
+    int main(int argc, char **argv) {
+#if !defined(__x86_64__)
+  #error __x86_64__ not defined
+#endif
+  return 0;
+    }
+    """
+def CheckHost_x86_64(context):
+  context.Message('Checking for an x86_64 host...')
+  result = context.TryCompile(host_x86_64_test, '.c')
+  context.Result(result)
+  return result
+
+conf = Configure(env, custom_tests = {
+  'CheckPKGConfig' : CheckPKGConfig,
+  'CheckPKG' : CheckPKG,
+  'CheckSDL' : CheckSDL,
+  'CheckHost_x86_32' : CheckHost_x86_32,
+  'CheckHost_x86_64' : CheckHost_x86_64,
+  })
+  
+if not conf.CheckPKGConfig('0.15.0'): 
+   print 'pkg-config >= 0.15.0 not found.' 
+   Exit(1)
+
+if not conf.CheckPKG('ogg'): 
+  print 'libogg not found.' 
+  Exit(1) 
+
+if conf.CheckPKG('vorbis vorbisenc'):
+  have_vorbis=True
+else:
+  have_vorbis=False
+  
+build_player_example=True
+if not conf.CheckHeader('sys/soundcard.h'):
+  build_player_example=False
+if build_player_example and not conf.CheckSDL():
+  build_player_example=False
+
+if conf.CheckHost_x86_32():
+  libtheora_Sources += Split("""
+    x86_32/dsp_mmx.c
+    x86_32/dsp_mmxext.c
+    x86_32/recon_mmx.c
+    x86_32/fdct_mmx.c
+  """)
+elif conf.CheckHost_x86_64():
+  libtheora_Sources += Split("""
+    x86_64/dsp_mmx.c
+    x86_64/dsp_mmxext.c
+    x86_64/recon_mmx.c
+    x86_64/fdct_mmx.c
+  """)
+env = conf.Finish()
+
+env.Append(CPPPATH=['lib', 'include'])
+env.ParseConfig('pkg-config --cflags --libs ogg')
+
+libtheora_a = env.Library('lib/theora', path('lib', libtheora_Sources))
+libtheora_so = env.SharedLibrary('lib/theora', path('lib', libtheora_Sources))
+
+#installing
+prefix='/usr'
+lib_dir = prefix + '/lib'
+env.Alias('install', prefix)
+env.Install(lib_dir, [libtheora_a, libtheora_so])
+
+# example programs
+dump_video = env.Copy()
+dump_video.Append(LIBS=['theora'], LIBPATH=['./lib'])
+dump_video_Sources = Split("""dump_video.c""")
+dump_video.Program('examples/dump_video', path('examples', dump_video_Sources))
+
+if have_vorbis:
+  encex = dump_video.Copy()
+  encex.ParseConfig('pkg-config --cflags --libs vorbisenc vorbis')
+  encex_Sources = Split("""encoder_example.c""")
+  encex.Program('examples/encoder_example', path('examples', encex_Sources))
+
+  if build_player_example:
+    plyex = encex.Copy()
+    plyex_Sources = Split("""player_example.c""")
+    plyex.ParseConfig('sdl-config --cflags --libs')
+    plyex.Program('examples/player_example', path('examples', plyex_Sources))
diff --git a/autogen.sh b/autogen.sh
new file mode 100755 (executable)
index 0000000..597723f
--- /dev/null
@@ -0,0 +1,124 @@
+#!/bin/sh
+# Run this to set up the build system: configure, makefiles, etc.
+# (based on the version in enlightenment's cvs)
+
+package="theora"
+
+olddir=`pwd`
+srcdir=`dirname $0`
+test -z "$srcdir" && srcdir=.
+
+cd "$srcdir"
+DIE=0
+
+echo "checking for autoconf... "
+(autoconf --version) < /dev/null > /dev/null 2>&1 || {
+        echo
+        echo "You must have autoconf installed to compile $package."
+        echo "Download the appropriate package for your distribution,"
+        echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
+        DIE=1
+}
+
+VERSIONGREP="sed -e s/.*[^0-9\.]\([0-9]\.[0-9]\).*/\1/"
+VERSIONMKINT="sed -e s/[^0-9]//"
+
+ACLOCAL_FLAGS="-I m4"
+                                                                                
+# do we need automake?
+if test -r Makefile.am; then
+  AM_OPTIONS=`fgrep AUTOMAKE_OPTIONS Makefile.am`
+  AM_NEEDED=`echo $AM_OPTIONS | $VERSIONGREP`
+  if test x"$AM_NEEDED" = "x$AM_OPTIONS"; then
+    AM_NEEDED=""
+  fi
+  if test -z $AM_NEEDED; then
+    echo -n "checking for automake... "
+    AUTOMAKE=automake
+    ACLOCAL=aclocal
+    if ($AUTOMAKE --version < /dev/null > /dev/null 2>&1); then
+      echo "yes"
+    else
+      echo "no"
+      AUTOMAKE=
+    fi
+  else
+    echo -n "checking for automake $AM_NEEDED or later... "
+    for am in automake-$AM_NEEDED automake$AM_NEEDED \
+       automake automake-1.7 automake-1.8 automake-1.9; do
+      ($am --version < /dev/null > /dev/null 2>&1) || continue
+      ver=`$am --version < /dev/null | head -n 1 | $VERSIONGREP | $VERSIONMKINT`
+      verneeded=`echo $AM_NEEDED | $VERSIONMKINT`
+      if test $ver -ge $verneeded; then
+        AUTOMAKE=$am
+        echo $AUTOMAKE
+        break
+      fi
+    done
+    test -z $AUTOMAKE &&  echo "no"
+    echo -n "checking for aclocal $AM_NEEDED or later... "
+    for ac in aclocal-$AM_NEEDED aclocal$AM_NEEDED \
+       aclocal aclocal-1.7 aclocal-1.8 aclocal-1.9; do
+      ($ac --version < /dev/null > /dev/null 2>&1) || continue
+      ver=`$ac --version < /dev/null | head -n 1 | $VERSIONGREP | $VERSIONMKINT`
+      verneeded=`echo $AM_NEEDED | $VERSIONMKINT`
+      if test $ver -ge $verneeded; then
+        ACLOCAL=$ac
+        echo $ACLOCAL
+        break
+      fi
+    done
+    test -z $ACLOCAL && echo "no"
+  fi
+  test -z $AUTOMAKE || test -z $ACLOCAL && {
+        echo
+        echo "You must have automake installed to compile $package."
+        echo "Download the appropriate package for your distribution,"
+        echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
+        exit 1
+  }
+fi
+
+echo -n "checking for libtool... "
+for LIBTOOLIZE in libtoolize glibtoolize nope; do
+  ($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 && break
+done
+if test x$LIBTOOLIZE = xnope; then
+  echo "nope."
+  LIBTOOLIZE=libtoolize
+else
+  echo $LIBTOOLIZE
+fi
+($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 || {
+       echo
+       echo "You must have libtool installed to compile $package."
+       echo "Download the appropriate package for your system,"
+       echo "or get the source from one of the GNU ftp sites"
+       echo "listed in http://www.gnu.org/order/ftp.html"
+       DIE=1
+}
+
+if test "$DIE" -eq 1; then
+        exit 1
+fi
+
+if test -z "$*"; then
+        echo "I am going to run ./configure with no arguments - if you wish "
+        echo "to pass any to it, please specify them on the $0 command line."
+fi
+
+echo "Generating configuration files for $package, please wait...."
+
+echo "  $ACLOCAL $ACLOCAL_FLAGS"
+$ACLOCAL $ACLOCAL_FLAGS || exit 1
+echo "  $LIBTOOLIZE --automake"
+$LIBTOOLIZE --automake || exit 1
+echo "  autoheader"
+autoheader || exit 1
+echo "  $AUTOMAKE --add-missing $AUTOMAKE_FLAGS"
+$AUTOMAKE --add-missing $AUTOMAKE_FLAGS || exit 1
+echo "  autoconf"
+autoconf || exit 1
+
+cd $olddir
+$srcdir/configure --enable-maintainer-mode "$@" && echo
diff --git a/configure.ac b/configure.ac
new file mode 100644 (file)
index 0000000..90a29b0
--- /dev/null
@@ -0,0 +1,356 @@
+dnl Process this file with autoconf to produce a configure script
+
+dnl ------------------------------------------------
+dnl Initialization and Versioning
+dnl ------------------------------------------------
+
+AC_INIT(libtheora,[1.0alpha8-svn])
+
+AC_CANONICAL_HOST
+AC_CANONICAL_TARGET
+
+AM_CONFIG_HEADER([config.h])
+AC_CONFIG_SRCDIR([lib/enc/dct.c])
+AM_INIT_AUTOMAKE
+AM_MAINTAINER_MODE
+
+dnl Library versioning
+
+V_LIB_CURRENT=2
+V_LIB_REVISION=0
+V_LIB_AGE=2
+AC_SUBST(V_LIB_CURRENT)
+AC_SUBST(V_LIB_REVISION)
+AC_SUBST(V_LIB_AGE)
+
+dnl Extra linker options (for version script)
+THEORA_LDFLAGS=""
+
+dnl --------------------------------------------------  
+dnl Check for programs
+dnl --------------------------------------------------  
+
+dnl save $CFLAGS since AC_PROG_CC likes to insert "-g -O2"
+dnl if $CFLAGS is blank
+cflags_save="$CFLAGS"
+AC_PROG_CC
+AC_PROG_CPP
+CFLAGS="$cflags_save"
+
+AM_PROG_LIBTOOL
+
+dnl Add parameters for aclocal
+AC_SUBST(ACLOCAL_AMFLAGS, "-I m4")
+
+dnl Check for doxygen
+AC_CHECK_PROG(HAVE_DOXYGEN, doxygen, true, false)
+AM_CONDITIONAL(HAVE_DOXYGEN,$HAVE_DOXYGEN)
+if test $HAVE_DOXYGEN = "false"; then
+        AC_MSG_WARN([*** doxygen not found, API documentation will not be built])
+fi
+
+dnl Check for python
+AC_CHECK_PROG(HAVE_PYTHON, python, true, false)
+AM_CONDITIONAL(HAVE_PYTHON,$HAVE_PYTHON)
+
+dnl Check for valgrind
+VALGRIND_ENVIRONMENT=""
+ac_enable_valgrind=no
+AC_ARG_ENABLE(valgrind-testing,
+     [  --enable-valgrind-testing     enable running of tests inside Valgrind ],     [ ac_enable_valgrind=yes ], [ ac_enable_valgrind=no] )
+
+if test "x${ac_enable_valgrind}" = xyes ; then
+  if test "x${enable_shared}" = xyes ; then
+    VALGRIND_ENVIRONMENT="libtool --mode=execute "
+  fi
+
+  AC_CHECK_PROG(HAVE_VALGRIND, valgrind, yes, no)
+  if test "x$HAVE_VALGRIND" = xyes ; then
+    VALGRIND_ENVIRONMENT="$VALGRIND_ENVIRONMENT valgrind -q --leak-check=yes --show-reachable=yes --num-callers=100"
+    AC_SUBST(VALGRIND_ENVIRONMENT)
+    TESTS_INFO="Type 'make check' to run test suite. Tests will be run under:
+  ${VALGRIND_ENVIRONMENT}"
+  else
+    TESTS_INFO="Type 'make check' to run test suite (Valgrind not found)"
+  fi
+else
+  TESTS_INFO="Type 'make check' to run test suite (Valgrind testing not enabled)"
+fi
+
+dnl --------------------------------------------------
+dnl Set build flags based on environment
+dnl --------------------------------------------------
+
+dnl Set some target options
+
+cflags_save="$CFLAGS"
+if test -z "$GCC"; then
+        case $host in 
+        *)
+                DEBUG="-g -DDEBUG"
+                CFLAGS="-O"
+                PROFILE="-g -p -DDEBUG" ;;
+        esac
+else
+
+        case $host in 
+        *)
+                DEBUG="-g -Wall -DDEBUG -D__NO_MATH_INLINES"
+                CFLAGS="-Wall -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loops"
+                PROFILE="-Wall -pg -g -O3 -fno-inline-functions -DDEBUG";;
+        esac
+fi
+CFLAGS="$CFLAGS $cflags_save"
+
+cpu_x86_64=no
+cpu_x86_32=no
+AC_ARG_ENABLE(asm,
+    [  --disable-asm           disable assembly optimizations ],
+    [ ac_enable_asm=$enableval ], [ ac_enable_asm=yes] )
+
+if test "x${ac_enable_asm}" = xyes; then
+  cpu_optimization="no optimization for your platform, please send a patch"
+  case $target_cpu in
+  i[[3456]]86)
+    cpu_x86_32=yes 
+    cpu_optimization="32 bit x86"
+    AC_DEFINE([USE_ASM], [],  [make use of asm optimization])
+    if test "x$target_vendor" = "xapple"; then
+      THEORA_LDFLAGS="$THEORA_LDFLAGS  -Wl,-read_only_relocs,suppress"
+    fi
+    
+    AC_DEFINE([OC_X86ASM], [], [enable x86 assambler optimization])
+    AM_CONDITIONAL(OC_X86ASM,true)
+      ;;
+  x86_64)
+    cpu_x86_64=yes
+    cpu_optimization="64 bit x86"
+    AC_DEFINE([USE_ASM], [],  [make use of asm optimization])  
+    AC_DEFINE([OC_X86ASM], [], [enable x86 assambler optimization])
+    AM_CONDITIONAL(OC_X86ASM,true)
+    ;;
+  esac
+else
+  cpu_optimization="disabled"
+fi
+AM_CONDITIONAL([CPU_x86_64], [test x$cpu_x86_64 = xyes])
+AM_CONDITIONAL([CPU_x86_32], [test x$cpu_x86_32 = xyes])
+
+# Test whenever ld supports -version-script
+AC_PROG_LD
+AC_PROG_LD_GNU
+if test "x$lt_cv_prog_gnu_ld" = "xyes"; then
+   SHLIB_VERSION_ARG="Wl,--version-script=Version_script"
+
+   dnl Set extra linker options
+   case "$target_os" in
+  linux* | solaris* )
+    SHLIB_VERSION_ARG="-Wl,--version-script=Version_script"
+    ;;
+  *)
+    ;;
+   esac
+   THEORA_LDFLAGS="$THEORA_LDFLAGS SHLIB_VERSION_ARG"
+fi
+
+AC_SUBST(THEORA_LDFLAGS)
+
+dnl --------------------------------------------------
+dnl Checks for support libraries and headers
+dnl --------------------------------------------------
+
+dnl check for Ogg
+HAVE_OGG=no
+
+dnl first check through pkg-config since it's more flexible
+
+dnl check for pkg-config itself so we don't try the m4 macro without pkg-config
+AC_CHECK_PROG(HAVE_PKG_CONFIG, pkg-config, yes)
+if test "x$HAVE_PKG_CONFIG" = "xyes"
+then
+  PKG_CHECK_MODULES(OGG, ogg >= 1.1, HAVE_OGG=yes, HAVE_OGG=no)
+fi
+if test "x$HAVE_OGG" = "xno"
+then
+  dnl fall back to the old school test
+  XIPH_PATH_OGG(, AC_MSG_ERROR([
+    libogg is required to build this package!
+    please see http://www.xiph.org/ for how to
+    obtain a copy.
+  ]))
+  cflags_save=$CFLAGS
+  libs_save=$LIBS
+  CFLAGS="$CFLAGS $OGG_CFLAGS"
+  LIBS="$LIBS $OGG_LIBS"
+  AC_CHECK_FUNC(oggpackB_read, , [
+    AC_MSG_ERROR([newer libogg version (1.1 or later) required])
+  ])
+  CFLAGS=$cflags_save
+  LIBS=$libs_save
+fi
+
+
+dnl check for Vorbis
+HAVE_VORBIS=no
+
+dnl first check through pkg-config since it's more flexible
+
+if test "x$HAVE_PKG_CONFIG" = "xyes"
+then
+  PKG_CHECK_MODULES(VORBIS, vorbis >= 1.0.1, HAVE_VORBIS=yes, HAVE_VORBIS=no)
+  dnl also set VORBISENC_LIBS since an examples needs it
+  dnl the old .m4 sets this to a value to use on top of VORBIS_LIBS,
+  dnl so we do the same here.
+  VORBISENC_LIBS="-lvorbisenc"
+  AC_SUBST(VORBISENC_LIBS)
+fi
+if test "x$HAVE_VORBIS" = "xno"
+then
+  dnl fall back to the old school test
+  XIPH_PATH_VORBIS(HAVE_VORBIS=yes, HAVE_VORBIS=no)
+fi
+
+dnl check for SDL
+HAVE_SDL=no
+
+AM_PATH_SDL(,[
+  HAVE_SDL=yes
+  SDL_LIBS=`$SDL_CONFIG --libs`
+],AC_MSG_WARN([*** Unable to find SDL -- Not compiling example players ***]))
+
+dnl check for OSS
+HAVE_OSS=no
+
+AC_CHECK_HEADERS([sys/soundcard.h soundcard.h machine/soundcard.h],[
+  HAVE_OSS=yes
+  break
+])
+if test x$HAVE_OSS != xyes; then
+  AC_MSG_WARN([OSS audio support not found -- not compiling player_example])
+fi
+
+dnl --------------------------------------------------
+dnl Overall build configuration options
+dnl --------------------------------------------------
+
+dnl Configuration option for building of floating point code.
+
+ac_enable_float=yes
+AC_ARG_ENABLE(float,
+     [  --disable-float         disable use of floating point code ],
+     [ ac_enable_float=$enableval ], [ ac_enable_float=yes] )
+
+if test "x${ac_enable_float}" != xyes ; then
+    AC_DEFINE([THEORA_DISABLE_FLOAT], [], 
+  [Define to exclude floating point code from the build])
+fi
+AM_CONDITIONAL(THEORA_DISABLE_FLOAT, [test "x${ac_enable_float}" != xyes])
+
+dnl Configuration option for building of encoding support.
+
+ac_enable_encode=yes
+AC_ARG_ENABLE(encode,
+     [  --disable-encode        disable encoding support ],
+     [ ac_enable_encode=$enableval ], [ ac_enable_encode=yes] )
+
+if test "x${ac_enable_encode}" != xyes ; then
+    AC_DEFINE([THEORA_DISABLE_ENCODE], [],
+  [Define to exclude encode support from the build])
+else
+    if test x$HAVE_VORBIS = xyes; then
+      BUILDABLE_EXAMPLES="$BUILDABLE_EXAMPLES encoder_example\$(EXEEXT)"
+    else
+      AC_MSG_NOTICE([Vorbis missing, cannot build example encoder])
+    fi
+fi
+AM_CONDITIONAL(THEORA_DISABLE_ENCODE, [test "x${ac_enable_encode}" != xyes])
+
+dnl --------------------------------------------------
+dnl Check for headers
+dnl --------------------------------------------------
+
+dnl none here
+
+dnl --------------------------------------------------
+dnl Check for typedefs, structures, etc
+dnl --------------------------------------------------
+
+dnl none
+
+dnl --------------------------------------------------
+dnl Check for library functions
+dnl --------------------------------------------------
+
+dnl substitute the included getopt if the system doesn't support long options
+AC_CHECK_FUNC(getopt_long,
+              [GETOPT_OBJS=''],
+              [GETOPT_OBJS='getopt.$(OBJEXT) getopt1.$(OBJEXT)'])
+AC_SUBST(GETOPT_OBJS)
+
+if test x$HAVE_SDL = xyes -a x$HAVE_OSS = xyes -a x$HAVE_VORBIS = xyes; then
+  BUILDABLE_EXAMPLES="$BUILDABLE_EXAMPLES player_example"
+fi
+AC_SUBST(BUILDABLE_EXAMPLES)
+
+dnl --------------------------------------------------
+dnl Do substitutions
+dnl --------------------------------------------------
+
+AC_SUBST(DEBUG)
+AC_SUBST(PROFILE)
+
+AC_OUTPUT([
+  Makefile 
+  lib/Makefile
+  include/Makefile include/theora/Makefile
+  examples/Makefile
+  doc/Makefile doc/Doxyfile
+  tests/Makefile
+  lib/Version_script
+  m4/Makefile
+  libtheora.spec
+  theora.pc
+  theora-uninstalled.pc
+])
+
+AS_AC_EXPAND(LIBDIR, ${libdir})
+AS_AC_EXPAND(INCLUDEDIR, ${includedir})
+AS_AC_EXPAND(BINDIR, ${bindir})
+AS_AC_EXPAND(DOCDIR, ${datadir}/doc)
+
+if test $HAVE_DOXYGEN = "false"; then
+  doc_build="no"
+else
+  doc_build="yes"
+fi
+dnl need to handle spec build?
+
+AC_MSG_RESULT([
+------------------------------------------------------------------------
+  $PACKAGE $VERSION:  Automatic configuration OK.
+
+  General configuration:
+
+    Encoding support: ........... ${ac_enable_encode}
+    Floating point support: ..... ${ac_enable_float}
+    Assembly optimization: ...... ${cpu_optimization}
+    API Documentation: .......... ${doc_build}
+
+  Installation paths:
+
+    libtheora: ................... ${LIBDIR}
+    C header files: .............. ${INCLUDEDIR}/theora
+    Documentation: ............... ${DOCDIR}/$PACKAGE
+
+  Building:
+
+    Type 'make' to compile $PACKAGE.
+
+    Type 'make install' to install $PACKAGE.
+
+    ${TESTS_INFO}
+
+  Example programs will be built but not installed.
+------------------------------------------------------------------------
+])
+
diff --git a/debian/changelog b/debian/changelog
new file mode 100644 (file)
index 0000000..4227d24
--- /dev/null
@@ -0,0 +1,15 @@
+libtheora (0.0.0.alpha3-1) unstable; urgency=low
+
+  * Initial upload to Debian.
+
+ -- Christopher L Cheney <ccheney@debian.org>  Tue, 29 Jun 2004 22:00:00 -0500
+
+libtheora (0.0.0-0) unstable; urgency=low
+
+  * Initial Release.
+
+ -- Christopher L Cheney <ccheney@debian.org>  Wed, 25 Sep 2002 21:00:00 -0500
+
+Local variables:
+mode: debian-changelog
+End:
diff --git a/debian/control b/debian/control
new file mode 100644 (file)
index 0000000..801e756
--- /dev/null
@@ -0,0 +1,24 @@
+Source: libtheora
+Section: libs
+Priority: optional
+Maintainer: Christopher L Cheney <ccheney@debian.org>
+Build-Depends: cdbs, autotools-dev, debhelper (>> 4.0.0), devscripts, libogg-dev (>= 1.1.0), libvorbis-dev, python
+Standards-Version: 3.6.1.0
+
+Package: libtheora0
+Architecture: any
+Section: libs
+Depends: ${shlibs:Depends}
+Description: The Theora Video Compression Codec
+ Ogg Theora
+
+Package: libtheora-dev
+Architecture: any
+Section: libdevel
+Depends: libtheora0 (= ${Source-Version}), libogg-dev
+Description: The Theora Compression Codec (development files)
+ Theora is a fully open, non-proprietary, patent-and-royalty-free,
+ general-purpose compressed video format.
+ .
+ This package contains the header files and documentation needed to develop
+ applications with libtheora.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644 (file)
index 0000000..4a875da
--- /dev/null
@@ -0,0 +1,38 @@
+This package was debianized by Christopher L Cheney <ccheney@debian.org> on
+Wed, 25 Sep 2002 21:00:00 -0500.
+
+It was downloaded from http://svn.xiph.org/trunk/theora/
+
+Upstream Authors: Xiph.Org Foundation
+
+Copyright:
+
+Copyright (c) 2002-2004, Xiph.org Foundation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+- Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+- Neither the name of the Xiph.org Foundation nor the names of its
+contributors may be used to endorse or promote products derived from
+this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
diff --git a/debian/libtheora-dev.install b/debian/libtheora-dev.install
new file mode 100644 (file)
index 0000000..f1773cd
--- /dev/null
@@ -0,0 +1,5 @@
+debian/tmp/usr/include/theora/theora.h
+debian/tmp/usr/lib/libtheora.a
+debian/tmp/usr/lib/libtheora.la
+debian/tmp/usr/lib/libtheora.so
+debian/tmp/usr/lib/pkgconfig/theora.pc
diff --git a/debian/libtheora0.install b/debian/libtheora0.install
new file mode 100644 (file)
index 0000000..9e8bdc0
--- /dev/null
@@ -0,0 +1,2 @@
+debian/tmp/usr/lib/libtheora.so.0
+debian/tmp/usr/lib/libtheora.so.0.0.0
diff --git a/debian/rules b/debian/rules
new file mode 100755 (executable)
index 0000000..f738c4d
--- /dev/null
@@ -0,0 +1,3 @@
+#!/usr/bin/make -f
+include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/class/autotools.mk
diff --git a/debian/watch b/debian/watch
new file mode 100644 (file)
index 0000000..033083d
--- /dev/null
@@ -0,0 +1,3 @@
+version=2
+
+http://downloads.xiph.org/releases/theora/libtheora-(.*)\.tar\.gz      debian uupdate
diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in
new file mode 100644 (file)
index 0000000..1a8abdd
--- /dev/null
@@ -0,0 +1,1142 @@
+# Doxyfile 1.3.7
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+#       TAG = value [value, ...]
+# For lists items can also be appended using:
+#       TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded 
+# by quotes) that should identify the project.
+
+PROJECT_NAME           = @PACKAGE@
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number. 
+# This could be handy for archiving the generated documentation or 
+# if some version control system is used.
+
+PROJECT_NUMBER         = @VERSION@
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) 
+# base path where the generated documentation will be put. 
+# If a relative path is entered, it will be relative to the location 
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY       = libtheora
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 
+# 2 levels of 10 sub-directories under the output directory of each output 
+# format and will distribute the generated files over these directories. 
+# Enabling this option can be useful when feeding doxygen a huge amount of source 
+# files, where putting all generated files in the same directory would otherwise 
+# cause performance problems for the file system.
+
+CREATE_SUBDIRS         = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all 
+# documentation generated by doxygen is written. Doxygen will use this 
+# information to generate all constant output in the proper language. 
+# The default language is English, other supported languages are: 
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, 
+# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en 
+# (Japanese with English messages), Korean, Korean-en, Norwegian, Polish, Portuguese, 
+# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian.
+
+OUTPUT_LANGUAGE        = English
+
+# This tag can be used to specify the encoding used in the generated output. 
+# The encoding is not always determined by the language that is chosen, 
+# but also whether or not the output is meant for Windows or non-Windows users. 
+# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES 
+# forces the Windows encoding (this is the default for the Windows binary), 
+# whereas setting the tag to NO uses a Unix-style encoding (the default for 
+# all platforms other than Windows).
+
+USE_WINDOWS_ENCODING   = NO
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will 
+# include brief member descriptions after the members that are listed in 
+# the file and class documentation (similar to JavaDoc). 
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC      = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 
+# the brief description of a member or function before the detailed description. 
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF           = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator 
+# that is used to form the text in various listings. Each string 
+# in this list, if found as the leading text of the brief description, will be 
+# stripped from the text and the result after processing the whole list, is used 
+# as the annotated text. Otherwise, the brief description is used as-is. If left 
+# blank, the following values are used ("$name" is automatically replaced with the 
+# name of the entity): "The $name class" "The $name widget" "The $name file" 
+# "is" "provides" "specifies" "contains" "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF       = 
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then 
+# Doxygen will generate a detailed section even if there is only a brief 
+# description.
+
+ALWAYS_DETAILED_SEC    = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited 
+# members of a class in the documentation of that class as if those members were 
+# ordinary class members. Constructors, destructors and assignment operators of 
+# the base classes will not be shown.
+
+INLINE_INHERITED_MEMB  = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full 
+# path before files name in the file list and in the header files. If set 
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES        = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag 
+# can be used to strip a user-defined part of the path. Stripping is 
+# only done if one of the specified strings matches the left-hand part of 
+# the path. The tag can be used to show relative paths in the file list. 
+# If left blank the directory from which doxygen is run is used as the 
+# path to strip.
+
+STRIP_FROM_PATH        = 
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of 
+# the path mentioned in the documentation of a class, which tells 
+# the reader which header file to include in order to use a class. 
+# If left blank only the name of the header file containing the class 
+# definition is used. Otherwise one should specify the include paths that 
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH    = 
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter 
+# (but less readable) file names. This can be useful is your file systems 
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES            = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen 
+# will interpret the first line (until the first dot) of a JavaDoc-style 
+# comment as the brief description. If set to NO, the JavaDoc 
+# comments will behave just like the Qt-style comments (thus requiring an 
+# explicit @brief command for a brief description.
+
+JAVADOC_AUTOBRIEF      = YES
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen 
+# treat a multi-line C++ special comment block (i.e. a block of //! or /// 
+# comments) as a brief description. This used to be the default behaviour. 
+# The new default is to treat a multi-line C++ comment block as a detailed 
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen 
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member 
+# documentation.
+
+DETAILS_AT_TOP         = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented 
+# member inherits the documentation from any documented member that it 
+# re-implements.
+
+INHERIT_DOCS           = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC 
+# tag is set to YES, then doxygen will reuse the documentation of the first 
+# member in the group (if any) for the other members of the group. By default 
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC   = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. 
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE               = 8
+
+# This tag can be used to specify a number of aliases that acts 
+# as commands in the documentation. An alias has the form "name=value". 
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to 
+# put the command \sideeffect (or @sideeffect) in the documentation, which 
+# will result in a user-defined paragraph with heading "Side Effects:". 
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES                = 
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources 
+# only. Doxygen will then generate output that is more tailored for C. 
+# For instance, some of the names that are used will be different. The list 
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C  = YES
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources 
+# only. Doxygen will then generate output that is more tailored for Java. 
+# For instance, namespaces will be presented as packages, qualified scopes 
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA   = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of 
+# the same type (for instance a group of public functions) to be put as a 
+# subgroup of that type (e.g. under the Public Functions section). Set it to 
+# NO to prevent subgrouping. Alternatively, this can be done per class using 
+# the \nosubgrouping command.
+
+SUBGROUPING            = YES
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in 
+# documentation are documented, even if no documentation was available. 
+# Private class members and static file members will be hidden unless 
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL            = NO
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class 
+# will be included in the documentation.
+
+EXTRACT_PRIVATE        = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file 
+# will be included in the documentation.
+
+EXTRACT_STATIC         = NO
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) 
+# defined locally in source files will be included in the documentation. 
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES  = YES
+
+# This flag is only useful for Objective-C code. When set to YES local 
+# methods, which are defined in the implementation section but not in 
+# the interface are included in the documentation. 
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS  = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all 
+# undocumented members of documented classes, files or namespaces. 
+# If set to NO (the default) these members will be included in the 
+# various overviews, but no documentation section is generated. 
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS     = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all 
+# undocumented classes that are normally visible in the class hierarchy. 
+# If set to NO (the default) these classes will be included in the various 
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES     = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all 
+# friend (class|struct|union) declarations. 
+# If set to NO (the default) these declarations will be included in the 
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS  = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any 
+# documentation blocks found inside the body of a function. 
+# If set to NO (the default) these blocks will be appended to the 
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS      = NO
+
+# The INTERNAL_DOCS tag determines if documentation 
+# that is typed after a \internal command is included. If the tag is set 
+# to NO (the default) then the documentation will be excluded. 
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS          = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate 
+# file names in lower-case letters. If set to YES upper-case letters are also 
+# allowed. This is useful if you have classes or files whose names only differ 
+# in case and if your file system supports case sensitive file names. Windows 
+# users are advised to set this option to NO.
+
+CASE_SENSE_NAMES       = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen 
+# will show members with their full class and namespace scopes in the 
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES       = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen 
+# will put a list of the files that are included by a file in the documentation 
+# of that file.
+
+SHOW_INCLUDE_FILES     = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] 
+# is inserted in the documentation for inline members.
+
+INLINE_INFO            = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen 
+# will sort the (detailed) documentation of file and class members 
+# alphabetically by member name. If set to NO the members will appear in 
+# declaration order.
+
+SORT_MEMBER_DOCS       = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the 
+# brief documentation of file, namespace and class members alphabetically 
+# by member name. If set to NO (the default) the members will appear in 
+# declaration order.
+
+SORT_BRIEF_DOCS        = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be 
+# sorted by fully-qualified names, including namespaces. If set to 
+# NO (the default), the class list will be sorted only by class name, 
+# not including the namespace part. 
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the 
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME     = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or 
+# disable (NO) the todo list. This list is created by putting \todo 
+# commands in the documentation.
+
+GENERATE_TODOLIST      = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or 
+# disable (NO) the test list. This list is created by putting \test 
+# commands in the documentation.
+
+GENERATE_TESTLIST      = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or 
+# disable (NO) the bug list. This list is created by putting \bug 
+# commands in the documentation.
+
+GENERATE_BUGLIST       = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or 
+# disable (NO) the deprecated list. This list is created by putting 
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional 
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS       = 
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines 
+# the initial value of a variable or define consists of for it to appear in 
+# the documentation. If the initializer consists of more lines than specified 
+# here it will be hidden. Use a value of 0 to hide initializers completely. 
+# The appearance of the initializer of individual variables and defines in the 
+# documentation can be controlled using \showinitializer or \hideinitializer 
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES  = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated 
+# at the bottom of the documentation of classes and structs. If set to YES the 
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES        = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated 
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET                  = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are 
+# generated by doxygen. Possible values are YES and NO. If left blank 
+# NO is used.
+
+WARNINGS               = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings 
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will 
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED   = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for 
+# potential errors in the documentation, such as not documenting some 
+# parameters in a documented function, or documenting parameters that 
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR      = YES
+
+# The WARN_FORMAT tag determines the format of the warning messages that 
+# doxygen can produce. The string should contain the $file, $line, and $text 
+# tags, which will be replaced by the file and line number from which the 
+# warning originated and the warning text.
+
+WARN_FORMAT            = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning 
+# and error messages should be written. If left blank the output is written 
+# to stderr.
+
+WARN_LOGFILE           = 
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain 
+# documented source files. You may enter file names like "myfile.cpp" or 
+# directories like "/usr/src/myproject". Separate the files or directories 
+# with spaces.
+
+INPUT                  = @top_srcdir@/include/theora
+
+# If the value of the INPUT tag contains directories, you can use the 
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
+# and *.h) to filter out the source-files in the directories. If left 
+# blank the following patterns are tested: 
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp 
+# *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm
+
+FILE_PATTERNS          = 
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories 
+# should be searched for input files as well. Possible values are YES and NO. 
+# If left blank NO is used.
+
+RECURSIVE              = NO
+
+# The EXCLUDE tag can be used to specify files and/or directories that should 
+# excluded from the INPUT source files. This way you can easily exclude a 
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE                = 
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories 
+# that are symbolic links (a Unix filesystem feature) are excluded from the input.
+
+EXCLUDE_SYMLINKS       = NO
+
+# If the value of the INPUT tag contains directories, you can use the 
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 
+# certain files from those directories.
+
+EXCLUDE_PATTERNS       = 
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or 
+# directories that contain example code fragments that are included (see 
+# the \include command).
+
+EXAMPLE_PATH           = 
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the 
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
+# and *.h) to filter out the source-files in the directories. If left 
+# blank all files are included.
+
+EXAMPLE_PATTERNS       = 
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be 
+# searched for input files to be used with the \include or \dontinclude 
+# commands irrespective of the value of the RECURSIVE tag. 
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE      = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or 
+# directories that contain image that are included in the documentation (see 
+# the \image command).
+
+IMAGE_PATH             = 
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should 
+# invoke to filter for each input file. Doxygen will invoke the filter program 
+# by executing (via popen()) the command <filter> <input-file>, where <filter> 
+# is the value of the INPUT_FILTER tag, and <input-file> is the name of an 
+# input file. Doxygen will then use the output that the filter program writes 
+# to standard output.
+
+INPUT_FILTER           = 
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using 
+# INPUT_FILTER) will be used to filter the input files when producing source 
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES    = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will 
+# be generated. Documented entities will be cross-referenced with these sources. 
+# Note: To get rid of all source code in the generated output, make sure also 
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER         = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body 
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES         = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 
+# doxygen to hide any special comment blocks from generated source code 
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS    = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES (the default) 
+# then for each documented function all documented 
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES (the default) 
+# then for each documented function all documented entities 
+# called/used by that function will be listed.
+
+REFERENCES_RELATION    = YES
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen 
+# will generate a verbatim copy of the header file for each class for 
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS       = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index 
+# of all compounds will be generated. Enable this if the project 
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX     = NO
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then 
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns 
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX    = 5
+
+# In case all classes in a project start with a common prefix, all 
+# classes will be put under the same header in the alphabetical index. 
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that 
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX          = 
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will 
+# generate HTML output.
+
+GENERATE_HTML          = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT            = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for 
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank 
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION    = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for 
+# each generated HTML page. If it is left blank doxygen will generate a 
+# standard header.
+
+HTML_HEADER            = 
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for 
+# each generated HTML page. If it is left blank doxygen will generate a 
+# standard footer.
+
+HTML_FOOTER            = 
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading 
+# style sheet that is used by each HTML page. It can be used to 
+# fine-tune the look of the HTML output. If the tag is left blank doxygen 
+# will generate a default style sheet. Note that doxygen will try to copy 
+# the style sheet file to the HTML output directory, so don't put your own 
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET        = 
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 
+# files or namespaces will be aligned in HTML using tables. If set to 
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS     = YES
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files 
+# will be generated that can be used as input for tools like the 
+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) 
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP      = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can 
+# be used to specify the file name of the resulting .chm file. You 
+# can add a path in front of the file if the result should not be 
+# written to the html output directory.
+
+CHM_FILE               = 
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can 
+# be used to specify the location (absolute path including file name) of 
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run 
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION           = 
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag 
+# controls if a separate .chi index file is generated (YES) or that 
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI           = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag 
+# controls whether a binary table of contents is generated (YES) or a 
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC             = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members 
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND             = NO
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at 
+# top of each HTML page. The value NO (the default) enables the index and 
+# the value YES disables it.
+
+DISABLE_INDEX          = NO
+
+# This tag can be used to set the number of enum values (range [1..20]) 
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE   = 4
+
+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
+# generated containing a tree-like index structure (just like the one that 
+# is generated for HTML Help). For this to work a browser that supports 
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, 
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are 
+# probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW      = NO
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be 
+# used to set the initial width (in pixels) of the frame in which the tree 
+# is shown.
+
+TREEVIEW_WIDTH         = 250
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 
+# generate Latex output.
+
+GENERATE_LATEX         = YES
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT           = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be 
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME         = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to 
+# generate index for LaTeX. If left blank `makeindex' will be used as the 
+# default command name.
+
+MAKEINDEX_CMD_NAME     = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact 
+# LaTeX documents. This may be useful for small projects and may help to 
+# save some trees in general.
+
+COMPACT_LATEX          = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used 
+# by the printer. Possible values are: a4, a4wide, letter, legal and 
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE             = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES         = 
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for 
+# the generated latex document. The header should contain everything until 
+# the first chapter. If it is left blank doxygen will generate a 
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER           = 
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated 
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will 
+# contain links (just like the HTML output) instead of page references 
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS         = NO
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of 
+# plain latex in the generated Makefile. Set this option to YES to get a 
+# higher quality PDF documentation.
+
+USE_PDFLATEX           = NO
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. 
+# command to the generated LaTeX files. This will instruct LaTeX to keep 
+# running if errors occur, instead of asking the user for help. 
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE        = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not 
+# include the index chapters (such as File Index, Compound Index, etc.) 
+# in the output.
+
+LATEX_HIDE_INDICES     = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output 
+# The RTF output is optimized for Word 97 and may not look very pretty with 
+# other RTF readers or editors.
+
+GENERATE_RTF           = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT             = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact 
+# RTF documents. This may be useful for small projects and may help to 
+# save some trees in general.
+
+COMPACT_RTF            = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated 
+# will contain hyperlink fields. The RTF file will 
+# contain links (just like the HTML output) instead of page references. 
+# This makes the output suitable for online browsing using WORD or other 
+# programs which support those fields. 
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS         = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's 
+# config file, i.e. a series of assignments. You only have to provide 
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE    = 
+
+# Set optional variables used in the generation of an rtf document. 
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE    = 
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will 
+# generate man pages
+
+GENERATE_MAN           = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT             = man
+
+# The MAN_EXTENSION tag determines the extension that is added to 
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION          = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output, 
+# then it will generate one additional man file for each entity 
+# documented in the real man page(s). These additional files 
+# only source the real man page, but without them the man command 
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS              = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will 
+# generate an XML file that captures the structure of 
+# the code including all documentation.
+
+GENERATE_XML           = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT             = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_SCHEMA             = 
+
+# The XML_DTD tag can be used to specify an XML DTD, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_DTD                = 
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will 
+# dump the program listings (including syntax highlighting 
+# and cross-referencing information) to the XML output. Note that 
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING     = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will 
+# generate an AutoGen Definitions (see autogen.sf.net) file 
+# that captures the structure of the code including all 
+# documentation. Note that this feature is still experimental 
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF   = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will 
+# generate a Perl module file that captures the structure of 
+# the code including all documentation. Note that this 
+# feature is still experimental and incomplete at the 
+# moment.
+
+GENERATE_PERLMOD       = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate 
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able 
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX          = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be 
+# nicely formatted so it can be parsed by a human reader.  This is useful 
+# if you want to understand what is going on.  On the other hand, if this 
+# tag is set to NO the size of the Perl module output will be much smaller 
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY         = YES
+
+# The names of the make variables in the generated doxyrules.make file 
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. 
+# This is useful so different doxyrules.make files included by the same 
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX = 
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor   
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will 
+# evaluate all C-preprocessor directives found in the sources and include 
+# files.
+
+ENABLE_PREPROCESSING   = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro 
+# names in the source code. If set to NO (the default) only conditional 
+# compilation will be performed. Macro expansion can be done in a controlled 
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION        = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES 
+# then the macro expansion is limited to the macros specified with the 
+# PREDEFINED and EXPAND_AS_PREDEFINED tags.
+
+EXPAND_ONLY_PREDEF     = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files 
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES        = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that 
+# contain include files that are not input files but should be processed by 
+# the preprocessor.
+
+INCLUDE_PATH           = 
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard 
+# patterns (like *.h and *.hpp) to filter out the header-files in the 
+# directories. If left blank, the patterns specified with FILE_PATTERNS will 
+# be used.
+
+INCLUDE_FILE_PATTERNS  = 
+
+# The PREDEFINED tag can be used to specify one or more macro names that 
+# are defined before the preprocessor is started (similar to the -D option of 
+# gcc). The argument of the tag is a list of macros of the form: name 
+# or name=definition (no spaces). If the definition and the = are 
+# omitted =1 is assumed.
+
+PREDEFINED             = 
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then 
+# this tag can be used to specify a list of macro names that should be expanded. 
+# The macro definition that is found in the sources will be used. 
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED      = 
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then 
+# doxygen's preprocessor will remove all function-like macros that are alone 
+# on a line, have an all uppercase name, and do not end with a semicolon. Such 
+# function macros are typically used for boiler-plate code, and will confuse the 
+# parser if not removed.
+
+SKIP_FUNCTION_MACROS   = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references   
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles. 
+# Optionally an initial location of the external documentation 
+# can be added for each tagfile. The format of a tag file without 
+# this location is as follows: 
+#   TAGFILES = file1 file2 ... 
+# Adding location for the tag files is done as follows: 
+#   TAGFILES = file1=loc1 "file2 = loc2" ... 
+# where "loc1" and "loc2" can be relative or absolute paths or 
+# URLs. If a location is present for each tag, the installdox tool 
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen 
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES               = 
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create 
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE       = 
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed 
+# in the class index. If set to NO only the inherited external classes 
+# will be listed.
+
+ALLEXTERNALS           = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed 
+# in the modules index. If set to NO, only the current project's groups will 
+# be listed.
+
+EXTERNAL_GROUPS        = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script 
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH              = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool   
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will 
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base or 
+# super classes. Setting the tag to NO turns the diagrams off. Note that this 
+# option is superseded by the HAVE_DOT option below. This is only a fallback. It is 
+# recommended to install and use dot, since it yields more powerful graphs.
+
+CLASS_DIAGRAMS         = YES
+
+# If set to YES, the inheritance and collaboration graphs will hide 
+# inheritance and usage relations if the target is undocumented 
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS   = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is 
+# available from the path. This tool is part of Graphviz, a graph visualization 
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section 
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT               = NO
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen 
+# will generate a graph for each documented class showing the direct and 
+# indirect inheritance relations. Setting this tag to YES will force the 
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH            = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen 
+# will generate a graph for each documented class showing the direct and 
+# indirect implementation dependencies (inheritance, containment, and 
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH    = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and 
+# collaboration diagrams in a style similar to the OMG's Unified Modeling 
+# Language.
+
+UML_LOOK               = NO
+
+# If set to YES, the inheritance and collaboration graphs will show the 
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS     = NO
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT 
+# tags are set to YES then doxygen will generate a graph for each documented 
+# file showing the direct and indirect include dependencies of the file with 
+# other documented files.
+
+INCLUDE_GRAPH          = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and 
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each 
+# documented header file showing the documented files that directly or 
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH      = YES
+
+# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will 
+# generate a call dependency graph for every global function or class method. 
+# Note that enabling this option will significantly increase the time of a run. 
+# So in most cases it will be better to enable call graphs for selected 
+# functions only using the \callgraph command.
+
+CALL_GRAPH             = NO
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen 
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY    = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images 
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT       = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be 
+# found. If left blank, it is assumed the dot tool can be found on the path.
+
+DOT_PATH               = 
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that 
+# contain dot files that are included in the documentation (see the 
+# \dotfile command).
+
+DOTFILE_DIRS           = 
+
+# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width 
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than 
+# this value, doxygen will try to truncate the graph, so that it fits within 
+# the specified constraint. Beware that most browsers cannot cope with very 
+# large images.
+
+MAX_DOT_GRAPH_WIDTH    = 1024
+
+# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height 
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than 
+# this value, doxygen will try to truncate the graph, so that it fits within 
+# the specified constraint. Beware that most browsers cannot cope with very 
+# large images.
+
+MAX_DOT_GRAPH_HEIGHT   = 1024
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the 
+# graphs generated by dot. A depth value of 3 means that only nodes reachable 
+# from the root by following a path via at most 3 edges will be shown. Nodes that 
+# lay further from the root node will be omitted. Note that setting this option to 
+# 1 or 2 may greatly reduce the computation time needed for large code bases. Also 
+# note that a graph may be further truncated if the graph's image dimensions are 
+# not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH and MAX_DOT_GRAPH_HEIGHT). 
+# If 0 is used for the depth value (the default), the graph is not depth-constrained.
+
+MAX_DOT_GRAPH_DEPTH    = 0
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will 
+# generate a legend page explaining the meaning of the various boxes and 
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND        = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will 
+# remove the intermediate dot files that are used to generate 
+# the various graphs.
+
+DOT_CLEANUP            = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine   
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be 
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE           = NO
diff --git a/doc/Makefile.am b/doc/Makefile.am
new file mode 100644 (file)
index 0000000..664bb14
--- /dev/null
@@ -0,0 +1,77 @@
+## Process this file with automake to produce Makefile.in
+
+SUBDIRS = #python
+
+docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)
+
+built_docs =
+
+static_docs = vp3-format.txt color.html \
+       draft-ietf-avt-rtp-theora-00.xml \
+       draft-ietf-avt-rtp-theora-00.txt
+
+doc_DATA = $(built_docs) $(static_docs) doxygen-build.stamp
+
+EXTRA_DIST = $(built_docs) $(static_docs) spec Doxyfile.in
+
+CLEANFILES = $(built_docs)
+
+if HAVE_DOXYGEN
+doxygen-build.stamp: Doxyfile $(top_srcdir)/include/theora/*.h
+       doxygen
+       touch doxygen-build.stamp
+else
+doxygen-build.stamp:
+       echo "*** Warning: Doxygen not found; documentation will not be built."
+       touch doxygen-build.stamp
+endif
+
+dist_docdir = $(distdir)/libtheora
+
+dist-hook:
+       if test -d libtheora; then \
+         mkdir $(dist_docdir); \
+         echo -n "copying built documenation..."; \
+         for dir in libtheora/*; do \
+           b=`basename $$dir`; \
+           if test $$b != ".svn"; then \
+             if test -d $$dir; then \
+               mkdir $(dist_docdir)/$$b; \
+               for f in $$dir/*; do \
+                 cp -p $$f $(dist_docdir)/$$b; \
+               done; \
+             fi; \
+           fi; \
+         done; \
+         echo "OK"; \
+       fi
+       for item in $(EXTRA_DIST); do \
+         if test -d $$item; then \
+           echo -n "cleaning $$item dir for distribution..."; \
+           rm -rf `find $(distdir)/$$item -name .svn`; \
+           echo "OK"; \
+         fi; \
+       done
+
+
+
+install-data-local: doxygen-build.stamp
+       $(mkinstalldirs) $(DESTDIR)$(docdir)
+       if test -d libtheora; then \
+         for dir in libtheora/*; do \
+           if test -d $$dir; then \
+             b=`basename $$dir`; \
+             $(mkinstalldirs) $(DESTDIR)$(docdir)/$$b; \
+             for f in $$dir/*; do \
+               $(INSTALL_DATA) $$f $(DESTDIR)$(docdir)/$$b; \
+             done \
+           fi \
+         done \
+       fi
+
+uninstall-local:
+       rm -rf $(DESTDIR)$(docdir)
+
+clean-local:
+       if test -d libtheora; then rm -rf libtheora; fi
+       if test -f doxygen-build.stamp; then rm -f doxygen-build.stamp; fi
diff --git a/doc/color.html b/doc/color.html
new file mode 100644 (file)
index 0000000..9bc2450
--- /dev/null
@@ -0,0 +1,602 @@
+<HTML>
+<HEAD><TITLE>xiph.org: Ogg Theora documentation</TITLE></HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#202020" LINK="#006666" VLINK="#000000">
+<H1><FONT COLOR="#000070">
+Ogg Theora I specification: color space conventions
+</FONT></H1>
+<H1>Overview</H1>
+<P>
+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.
+</P>
+<P>
+The Theora codec 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".
+All of them are Y'C<SUB>b</SUB>C<SUB>r</SUB> color spaces with one luma channel
+ and two chroma channels.
+Each channel contains 8-bit discrete values in the range 0-255, which represent
+ non-linear gamma pre-corrected signals.
+</P>
+<H2>color space parameters</H2>
+<P>
+The parameters which describe each color space are listed below.
+These are the parameters needed to map colors from the encoded
+ Y'C<SUB>b</SUB>C<SUB>r</SUB> representation to the device-independent color
+ space CIE XYZ (1931).
+</P>
+<DL>
+<DT>Y'C<SUB>b</SUB>C<SUB>r</SUB> to Y'P<SUB>b</SUB>P<SUB>r</SUB></DT>
+<DD>
+<P>
+This conversion takes 8-bit discrete values in the range 0-255 and maps them to
+ real values in the range [0,1] for Y and [-1/2,1/2] for P<SUB>b</SUB>
+ and P<SUB>r</SUB>.
+Because some values may fall outside the offset and excursion defined for each
+ channel in the Y'C<SUB>b</SUB>C<SUB>r</SUB> space, the results may fall
+ outside these ranges in Y'P<SUB>b</SUB>P<SUB>r</SUB> space.
+No clamping should be done at this stage.
+</P>
+<P>
+Parameters: <EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>,
+ <EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB>,</SUB></EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">Y'<SUB>out</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(Y'<SUB>in</SUB>-<EM>Offset<SUB>Y</SUB></EM>)/
+ <EM>Excursion<SUB>Y</SUB></EM>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">P<SUB>b</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(C<SUB>b</SUB>-<EM>Offset<SUB>C<SUB>b</SUB></SUB></EM>)/
+ <EM>Excursion<SUB>C<SUB>b</SUB></SUB></EM>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">P<SUB>r</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(C<SUB>r</SUB>-<EM>Offset<SUB>C<SUB>r</SUB></SUB></EM>)/
+ <EM>Excursion<SUB>C<SUB>r</SUB></SUB></EM>
+</TD>
+</TR>
+</TABLE>
+</DD>
+<DT>Y'P<SUB>b</SUB>P<SUB>r</SUB> to R'G'B'</DT>
+<DD>
+<P>
+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,1] after this stage.
+<P>
+Parameters: <EM>K<SUB>b</SUB></EM>, <EM>K<SUB>r</SUB></EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">Y' + 2(1-<EM>K<SUB>r</SUB></EM>)P<SUB>r</SUB></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+Y' +
+ 2((<EM>K<SUB>b</SUB></EM>-1)<EM>K<SUB>b</SUB></EM>/
+ (1-<EM>K<SUB>b</SUB></EM>-<EM>K<SUB>r</SUB></EM>))P<SUB>b</SUB> +
+ 2((<EM>K<SUB>r</SUB></EM>-1)<EM>K<SUB>r</SUB></EM>/
+ (1-<EM>K<SUB>b</SUB></EM>-<EM>K<SUB>r</SUB></EM>))P<SUB>r</SUB>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">Y' + 2(1-<EM>K<SUB>b</SUB></EM>)P<SUB>b</SUB></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>R'G'B' to RGB (Output device gamma correction)</DT>
+<DD>
+<P>
+This conversion takes the non-linear R'G'B' voltage levels and maps it to the
+ 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</EM> 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.
+</P>
+<P>
+For calibration with actual output devices, the model
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">L</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">(E'+&Delta;)<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+</TABLE>
+should be used, with &Delta; the free parameter and <EM>&gamma;</EM> held
+ fixed to the value specified in this document.
+The conversion function presented here is an idealized version with &Delta;=0.
+</P>
+<P>
+Parameters: <EM>&gamma;</EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">R'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">G'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">B'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>RGB to R'G'B' (Input device gamma correction)</DT>
+<DD>
+<P>
+This conversion takes linear light levels and maps them to the non-linear
+ voltage levels used to drive the actual output 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.
+</P>
+<P>
+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.
+</P>
+<P>
+Parameters: <EM>&beta;</EM>, <EM>&alpha;</EM>, <EM>&delta;</EM>,
+ <EM>&epsilon;</EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)R<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; R &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>R</TD>
+<TD>for 0 &le; R &lt; <EM>&delta;</EM></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)G<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; G &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>G</TD>
+<TD>for 0 &le; G &lt; <EM>&delta;</EM></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)B<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; B &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>B</TD>
+<TD>for 0 &le; B &lt; <EM>&delta;</EM></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>RGB to CIE XYZ (1931)</DT>
+<DD>
+<P>
+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.
+</P>
+<P>
+Parameters: <EM>x<SUB>r,g,b,w</SUB></EM>, <EM>y<SUB>r,g,b,w</SUB></EM>
+</P>
+<TABLE>
+<TR>
+<TD ALIGN="RIGHT">F</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR>
+<TD ALIGN="CENTER"><EM>x<SUB>r</SUB></EM>/<EM>y<SUB>r</SUB></EM></TD>
+<TD ALIGN="CENTER"><EM>x<SUB>g</SUB></EM>/<EM>y<SUB>g</SUB></EM></TD>
+<TD ALIGN="CENTER"><EM>x<SUB>b</SUB></EM>/<EM>y<SUB>b</SUB></EM></TD>
+</TR>
+<TR>
+<TD ALIGN="CENTER">1</TD>
+<TD ALIGN="CENTER">1</TD>
+<TD ALIGN="CENTER">1</TD>
+</TR>
+<TR>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>r</SUB></EM>-<EM>y<SUB>r</SUB></EM>)/<EM>y<SUB>r</SUB></EM>
+</TD>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>g</SUB></EM>-<EM>y<SUB>g</SUB></EM>)/<EM>y<SUB>g</SUB></EM>
+</TD>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>b</SUB></EM>-<EM>y<SUB>b</SUB></EM>)/<EM>y<SUB>b</SUB></EM>
+</TD>
+</TR>
+</TABLE></TD>
+<TD<FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+<TR>
+<TD ALIGN="RIGHT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">s<SUB>r</SUB></TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>g</SUB></TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>b</SUB></TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD>F<SUP>-1</SUP><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER"><EM>x<SUB>w</SUB></EM>/<EM>y<SUB>w</SUB></EM></TD></TR>
+<TR><TD ALIGN="CENTER">1</TD></TR>
+<TR><TD ALIGN="CENTER">
+(1-<EM>x<SUB>w</SUB></EM>-<EM>y<SUB>w</SUB></EM>)/<EM>y<SUB>w</SUB></EM>
+</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+<TR>
+<TD ALIGN="RIGHT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">X</TD></TR>
+<TR><TD ALIGN="CENTER">Y</TD></TR>
+<TR><TD ALIGN="CENTER">Z</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD>F<FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">s<SUB>r</SUB>R</TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>g</SUB>G</TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>b</SUB>B</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+</TABLE>
+</DD>
+</DL>
+<H2>available color spaces</H2>
+<P>
+These are the color spaces currently defined for use by Ogg 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 Ogg Theora video.
+<H3>Rec 470M (Rec. ITU-R BT.470-6 System M/NTSC with Rec. ITU-R BT.601-5)</H3>
+<P>
+This color space is used by broadcast television and DVDs in much of the
+ Americas, Japan, Korea, and the Union of Myanmar
+ [<A HREF="#Rec470">Rec470</A>].
+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 the Rec 470BG section for an appropriate gamma value to assume for M/PAL
+ input.
+</P>
+<P>
+In the US, studio monitors are adjusted to a D65 white point
+ (<EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>=0.313,0.329).
+In Japan, studio monitors are adjusted to a D white of 9300K
+ (<EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>=0.285,0.293).
+</P>
+<P>
+Rec 470 does not specify a digital encoding of the color signals.
+For Ogg Theora, Rec. ITU-R BT.601-5 is used, starting from the R'G'B' signals
+ specified by Rec 470 [<A HREF="#Rec601">Rec601</A>].
+</P>
+<P>
+<P>
+Rec 470 does not specify an input gamma function.
+For Ogg Theora, the Rec 709 input function is used.
+This is the same as that specified by SMPTE 170M, which claims to reflect
+ modern practice in the creation of NTSC signals (c. 1994)
+ [<A HREF="#SMPTE170M">SMPTE170M</A>].
+</P>
+<H4>parameters</H4>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(16,128,128)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+<EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>
+</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(219,224,224)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.114</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.299</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&gamma;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">2.2</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&beta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.45</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&alpha;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">4.5</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&delta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.018</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&epsilon;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.099</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>r</SUB></EM>,<EM>y<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.67,</TD>
+<TD>0.33</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>g</SUB></EM>,<EM>y<SUB>g</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.21,</TD>
+<TD>0.71</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>b</SUB></EM>,<EM>y<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.14,</TD>
+<TD>0.08</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+(Illuminant C) <EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>
+</TD>
+<TD>=</TD>
+<TD>0.310,</TD>
+<TD>0.316</TD>
+</TR>
+</TABLE>
+<H3>
+Rec 470BG (Rec. ITU-R BT.470-6 Systems B and G with Rec. ITU-R BT.601-5)
+</H3>
+<P>
+This color space is used by the PAL and SECAM systems in much of the rest of
+ the world [<A HREF="#Rec470">Rec470</A>].
+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.
+</P>
+<P>
+Note that 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 US 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.
+</P>
+<P>
+Rec 470 provisionally permits the use of the NTSC chromaticity values (given
+ above) with legacy PAL and SECAM equipment.
+In Ogg 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.
+</P>
+<P>
+The official Rec 470BG specifies a gamma value of <EM>&gamma;</EM>=2.8.
+However, in practice this value is unrealistically high
+ [<A HREF="#RefPoy97">Poy97</A>].
+Rec 470BG states that the overall system gamma should be approximately
+ <EM>&gamma;</EM>/<EM>&beta;</EM>=1.2.
+However, most cameras pre-correct with a gamma value of <EM>&beta;</EM>=0.45,
+ which suggests an output device gamma of approximately <EM>&gamma;</EM>=2.67.
+This is the value recommended for use with PAL systems in Ogg Theora.
+</P>
+<P>
+Rec 470 does not specify a digital encoding of the color signals.
+For Ogg Theora, Rec. ITU-R BT.601-5 is used, starting from the R'G'B' signals
+ specified by Rec 470 [<A HREF="#Rec601">Rec601</A>].
+</P>
+<P>
+Rec 470 does not specify an input gamma function.
+For Ogg Theora, the Rec 709 input function is used.
+</P>
+<H4>parameters</H4>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(16,128,128)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+<EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>
+</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(219,224,224)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.114</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.299</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&gamma;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">2.67</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&beta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.45</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&alpha;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">4.5</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&delta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.018</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&epsilon;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.099</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>r</SUB></EM>,<EM>y<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.64,</TD>
+<TD>0.33</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>g</SUB></EM>,<EM>y<SUB>g</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.29,</TD>
+<TD>0.60</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>b</SUB></EM>,<EM>y<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.15,</TD>
+<TD>0.06</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+(D65) <EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>
+</TD>
+<TD>=</TD>
+<TD>0.313,</TD>
+<TD>0.329</TD>
+</TR>
+</TABLE>
+<H2>references</H2>
+<DL>
+<DT>[<A NAME="Poy97">Poy97</A>]</DT>
+<DD>
+Poynton, Charles, <I>Frequently-Asked Questions about Gamma</I>.
+ <A HREF="http://www.poynton.com/GammaFAQ.html">http://www.poynton.com/GammaFAQ/html</A>,
+ Feb. 1997.
+</DD>
+<DT>[<A NAME="Rec470">Rec470</A>]</DT>
+<DD>
+Recommendation ITU-R BT.470-6, <I>Conventional Television Systems</I>
+ (1970, revised 1998). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="Rec601">Rec601</A>]</DT>
+<DD>
+Recommendation ITU-R BT.601-5, <I>Studio Encoding Parameters of
+ Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios</I>
+ (1982, revised 1995). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="Rec709">Rec709</A>]</DT>
+<DD>
+Recommendation ITU-R BT.709-5, <I>Parameter values for the
+ HDTV standards for production and international programme exchange</I>
+ (1990, revised 2002). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="SMPTE170M">SMPTE170M</A>]</DT>
+<DD>
+Society of Motion Picture and Television Engineers, <I>Television &mdash;
+ Composite Analog Video Signal &mdash; NTSC for Studio Applications</I>.
+ SMPTE-170M, 1994
+</DD>
+<DT>[<A NAME="SMPTE240M">SMPTE240M</A>]</DT>
+<DD>
+Society of Motion Picture and Television Engineers, <I>Television &mdash;
+ Signal Parameters &mdash; 1125-Line High-Definition Production</I>.
+ SMPTE-240M, 1999.
+</DD>
+</DL>
+</BODY>
+</HTML>
diff --git a/doc/draft-ietf-avt-rtp-theora-00.txt b/doc/draft-ietf-avt-rtp-theora-00.txt
new file mode 100644 (file)
index 0000000..f759aef
--- /dev/null
@@ -0,0 +1,1400 @@
+
+
+
+AVT Working Group                                             L. Barbato
+Internet-Draft                                                  Xiph.Org
+Expires: January 22, 2007                                  July 21, 2006
+
+
+                      draft-ietf-avt-rtp-theora-00
+              RTP Payload Format for Theora Encoded Video
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 22, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a RTP payload format for transporting Theora
+   encoded video.  It details the RTP encapsulation mechanism for raw
+   Theora data and configuration headers necessary to configure the
+   decoder.
+
+   Also included within the document are the necessary details for the
+   use of Theora with MIME and Session Description Protocol (SDP).
+
+Editors Note
+
+
+
+Barbato                 Expires January 22, 2007                [Page 1]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   All references to RFC XXXX are to be replaced by references to the
+   RFC number of this memo, when published.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  RTP Header . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Payload Header . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Payload Data . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4.  Example RTP Packet . . . . . . . . . . . . . . . . . . . .  7
+   3.  Configuration Headers  . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  In-band Header Transmission  . . . . . . . . . . . . . . .  9
+       3.1.1.  Packed Configuration . . . . . . . . . . . . . . . . .  9
+     3.2.  Out of Band Transmission . . . . . . . . . . . . . . . . . 10
+       3.2.1.  Packed Headers . . . . . . . . . . . . . . . . . . . . 11
+     3.3.  Loss of Configuration Headers  . . . . . . . . . . . . . . 13
+   4.  Comment Headers  . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.  Frame Packetizing  . . . . . . . . . . . . . . . . . . . . . . 14
+     5.1.  Example Fragmented Theora Packet . . . . . . . . . . . . . 15
+     5.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 17
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+     6.1.  Mapping MIME Parameters into SDP . . . . . . . . . . . . . 19
+       6.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 20
+     6.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 20
+   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     7.1.  Stream Video . . . . . . . . . . . . . . . . . . . . . . . 21
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007                [Page 2]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+1.  Introduction
+
+   Theora is a general purpose, lossy video codec.  It is based on the
+   VP3 video codec produced by On2 Technologies and has been donated to
+   the Xiph.org Foundation.
+
+   Theora I is a block-based lossy transform codec that utilizes an 8 x
+   8 Type-II Discrete Cosine Transform and block-based motion
+   compensation.  This places it in the same class of codecs as MPEG-1,
+   MPEG-2, MPEG-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).
+
+   Theora provides none of its own framing, synchronization, or
+   protection against transmission errors.  Instead, the codec expects
+   to receive a discrete sequence of data packets.  Theora is a free-
+   form variable bit rate (VBR) codec, and these 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 [1] or RTP/AVP
+   [3].
+
+   Theora I currently supports progressive video data of arbitrary
+   dimensions at a constant frame rate in one of several Y'CbCr color
+   spaces.  Three different chroma subsampling formats are supported:
+   4:2:0, 4:2:2, and 4:4:4.  The Theora I 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.  For performance reason, arbitrary frame sizes will be
+   encoded rounding both dimensions to the upper multiple of 16.  The
+   original width and height will be encoded in the header and the
+   decoder will use this information to clip the decoded frame to the
+   right dimensions.
+
+   Theora is similar to the Vorbis audio [10] in that the decoder reads
+   the probability model for the entropy coder and all quantization
+   parameters from special "header" packets at the start of the
+   compressed data.  It is therefore impossible to decode any video data
+   without having previously fetched the codec info and codec setup
+   headers, although Theora can begin to decode at an arbitrary intra-
+   frame packet so long as the codec has been initialized with the
+   associated headers.
+
+
+
+
+
+Barbato                 Expires January 22, 2007                [Page 3]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+
+2.  Payload Format
+
+   For RTP based transportation of Theora encoded video the standard RTP
+   header is followed by a 4 octets payload header, then the payload
+   data.  The payload headers are used to associate the Theora data with
+   its associated decoding codebooks as well as indicating if the
+   following packet contains fragmented Theora data and/or the number of
+   whole Theora data frames.  The payload data contains the raw Theora
+   bitstream information.
+
+   For RTP based transport of Theora encoded video the standard RTP
+   header is followed by a 4 octets payload header, then the payload
+   data.
+
+2.1.  RTP Header
+
+   The format of the RTP header is specified in [3] and shown in Figure
+   1.  This payload format uses the fields of the header in a manner
+   consistent with that specification.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 1: RTP Header
+
+   The RTP header begins with an octet of fields (V, P, X, and CC) to
+   support specialized RTP uses (see [3] and [4] for details).  For
+   Theora RTP, the following values are used.
+
+   Version (V): 2 bits
+
+
+
+
+Barbato                 Expires January 22, 2007                [Page 4]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   This field identifies the version of RTP.  The version used by this
+   specification is two (2).
+
+   Padding (P): 1 bit
+
+   Padding MAY be used with this payload format according to section 5.1
+   of [3].
+
+   Extension (X): 1 bit
+
+   The Extension bit is used in accordance with [3].
+
+   CSRC count (CC): 4 bits
+
+   The CSRC count is used in accordance with [3].
+
+   Marker (M): 1 bit
+
+   The Marker bit is used in accordance with [3].
+
+   Payload Type (PT): 7 bits
+
+   An RTP profile for a class of applications is expected to assign a
+   payload type for this format, or a dynamically allocated payload type
+   SHOULD be chosen which designates the payload as Theora.
+
+   Sequence number: 16 bits
+
+   The sequence number increments by one for each RTP data packet sent,
+   and may be used by the receiver to detect packet loss and to restore
+   packet sequence.  This field is detailed further in [3].
+
+   Timestamp: 32 bits
+
+   A timestamp representing the presentation time of the first sample of
+   the first Theora packet in the RTP packet.  The clock frequency MUST
+   be set to 90kHz.
+
+   SSRC/CSRC identifiers:
+
+   These two fields, 32 bits each with one SSRC field and a maximum of
+   16 CSRC fields, are as defined in [3].
+
+2.2.  Payload Header
+
+   The 4 octets following the RTP Header section represent the Payload
+   Header.  This header is split into a number of bitfields detailing
+   the format of the following Payload Datagrams.
+
+
+
+Barbato                 Expires January 22, 2007                [Page 5]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Configuration Ident             | F |TDT|# pkts.|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      +-+-+-+-+-+-+-+-+
+
+   Figure 2: Payload Header
+
+   Configuration Ident: 24 bits
+
+   This 24 bit field is used to associate the Theora data to a decoding
+   Packed Configuration.
+
+   Fragment type (F): 2 bit
+
+   This field is set according to the following list
+
+      0 = Not Fragmented
+      1 = Start Fragment
+      2 = Continuation Fragment
+      3 = End Fragment
+
+   This field must be zero if the number of packets field is non-zero.
+
+   Theora Data Type (TDT): 2 bits
+
+   This field sets the packet payload type for the Theora data.  There
+   are currently three Theora payload types currently used and one
+   reserved for future use.
+
+      0 = Raw Theora payload
+      1 = Theora Packed Configuration payload
+      2 = Legacy Theora Comment payload
+      3 = Reserved
+
+   The packets with a TDT of value 3 MUST be ignored
+
+   The last 4 bits represent the number of complete packets in this
+   payload.  This provides a maximum number of 15 Theora packets in the
+   payload.  If the packet contains fragmented data the number of
+   packets MUST be set to 0.
+
+2.3.  Payload Data
+
+   Each Theora payload section starts with a two octets length header
+   that is used to represent the size of the following data payload,
+
+
+
+Barbato                 Expires January 22, 2007                [Page 6]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   followed by the raw Theora packet data.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Payload Length         |          Theora Data         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 3: Payload Data
+
+   The Theora codec uses relatively unstructured raw packets containing
+   binary integer fields of arbitrary width that often do not fall on an
+   octet boundary.  When a Theora encoder produces packets, 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 zeros.
+
+   For payloads which consist of multiple Theora packets the payload
+   data consists of the payload length field followed by the first
+   Theora packet's data, then the payload length followed by the second
+   Theora packet, and so on for each of the Theora packets in the
+   payload.
+
+2.4.  Example RTP Packet
+
+   Here is an example RTP packet containing two Theora packets.
+
+   RTP Packet Header:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | 2 |0|0|  0    |0|      PT     |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          synchronisation source (SSRC) identifier             |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 4: Example RTP Packet
+
+   Payload Data:
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007                [Page 7]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Configuration Ident             | 0 | 0 | 2 pks |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Payload Length         |                              ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..           data               |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Theora data                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 5: Example Theora Payload Packet
+
+   The payload portion of the packet begins with the 24 bit
+   Configuration ident field followed by 8 bits describing the payload.
+   The Fragment type field is set to 0, indicating that this packet
+   contains whole Theora frame data.  The Data type field is set to 0
+   (theora raw data).  The number of whole Theora data packets is set to
+   2.
+
+   Each of the payload blocks starts with the two octets length field
+   followed by the variable length Theora packet data.
+
+
+3.  Configuration Headers
+
+   To decode a Theora stream three configuration header packets are
+   needed.  The first (Identification Header) indicates frame
+   dimensions, quality, blocks used and Theora encoder version.  The
+   second (Comment Header) contains stream metadata and the third (Setup
+   Header) contains details of the dequantization and Huffman tables.
+
+   Since this information must be transmitted reliably, and as the RTP
+   stream may change certain configuration data mid-session, there are
+   different methods for delivering this configuration data to a client,
+   both in-band and out-of-band, which are detailed below.  SDP delivery
+   is used to set up an initial state for the client application.  The
+   changes may be due to different dequantization and Huffman tables as
+   well as different bitrates of the stream.
+
+   The delivery vectors in use are specified by an SDP attribute that
+   indicates the method and the optional URI where the Theora Packed
+   Configuration (Section 3.1.1) Packets could be fetched.  Different
+   delivery methods MAY be advertised for the same session.  The in-band
+   codebook delivery SHOULD be considered as baseline, out-of-band
+
+
+
+Barbato                 Expires January 22, 2007                [Page 8]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   delivery methods that don't use RTP will not be described in this
+   document.  For non chained streams, the RECOMMENDED Configuration
+   delivery method is inline the Packed Configuration (Section 3.1.1) in
+   the SDP as explained in the IANA considerations (Section 6.1)
+
+   The 24 bit Ident field is used to map which Configuration will be
+   used to decode a packet.  When the Ident field changes, it indicates
+   that a change in the stream has taken place.  The client application
+   MUST have in advance the correct configuration and if the client
+   detects a change in the Ident value and does not have this
+   information it MUST NOT decode the raw data associated until it has
+   fetched the correct Configuration.
+
+3.1.  In-band Header Transmission
+
+   The Packed Configuration (Section 3.1.1) Payload is sent in-band with
+   the packet type bits set to match the payload type.  Clients MUST be
+   capable of dealing with periodic re-transmission of the configuration
+   headers.
+
+3.1.1.  Packed Configuration
+
+   A Theora Packed Configuration is identified by a payload type field
+   of 1.  Of the three headers, defined in the Theora I specification
+   [16], the identification and the setup will be packed together, while
+   the comment header will be completely suppressed.  It is up to the
+   client to provide a minimal size comment header to the decoder if
+   required by the implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007                [Page 9]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Configuration Ident             | 0 | 1 |      1|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             length            |          Identification      ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Identification                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Identification                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Identification                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..              |                      Setup                   ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                            Setup                            ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                            Setup                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 6: Packed Configuration Figure
+
+   The Ident field is set with the value that will be used by the Raw
+   Payload Packets to address this Configuration.  The Fragment type is
+   set to 0 since the packet bears full Packed configuration, the number
+   of packet is set to 1.  In practice, Packed Headers usually need to
+   be fragmented to fit the path MTU.
+
+3.2.  Out of Band Transmission
+
+   This section, as stated above, does not cover all the possible out-
+   of-band delivery methods since they rely on different protocols and
+   are linked to specific applications.  The following packet definition
+   SHOULD be used in out-of-band delivery and MUST be used when
+   Configuration is inlined in the SDP.
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 10]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+3.2.1.  Packed Headers
+
+   As mentioned above, the recommended delivery vector for Theora
+   configuration data is via a retrieval method that can be performed
+   using a reliable transport protocol.  As the RTP headers are not
+   required for this method of delivery the structure of the
+   configuration data is slightly different.  The packed header starts
+   with a 32 bit count field which details the number of packed headers
+   that are contained in the bundle.  Next is the Packed header payload
+   for each setup id.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Number of packed headers                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 7: Packed Headers Overview
+
+   Since the Configuration Ident and the Identification Header are fixed
+   length there is only a 16bit Length tag to define the length of the
+   packed headers.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Configuration Ident              |              ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..   Length     |              Identification Header           ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                    Identification Header                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Setup Header                         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Setup Header                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 8: Packed Headers Detail
+
+   The key difference from the in-band format is that there is no need
+   for the payload header octet.
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 11]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+3.2.1.1.  Packed Headers IANA Considerations
+
+   The following IANA considerations MUST only be applied to the packed
+   headers.
+
+   MIME media type name: audio
+
+   MIME subtype: theora-config
+
+   Required Parameters:
+
+      None
+
+   Optional Parameters:
+
+      None
+
+   Encoding considerations:
+
+      This media type contains binary data.
+
+   Security Considerations:
+
+      See Section 6 of RFC XXXX.
+
+   Interoperability considerations:
+
+      None
+
+   Published specification:
+
+      RFC XXXX [RFC Editor: please replace by the RFC number of this
+      memo, when published]
+
+   Applications which use this media type:
+
+      Theora encoded video, configuration data.
+
+   Additional information:
+
+      None
+
+   Person & email address to contact for further information:
+
+      Luca Barbato: <lu_zero@gentoo.org>
+      IETF Audio/Video Transport Working Group
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 12]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   Intended usage: COMMON
+
+   Restriction on usage:
+
+      This media type does not depend on the transport.
+
+   Author:
+
+      Luca Barbato
+
+   Change controller:
+
+      IETF AVT Working Group
+
+3.3.  Loss of Configuration Headers
+
+   Unlike the loss of raw Theora payload data, the loss of a
+   configuration header can lead to a situation where it will not be
+   possible to successfully decode the stream.
+
+   A loss of a Configuration Packet causes the stream decoder to halt
+   and SHOULD be reported to the client as well as a loss report sent
+   via RTCP.
+
+
+4.  Comment Headers
+
+   When the payload type is set to 2, the packet contains comment
+   metadata such as artist name, track title and so on.  These metadata
+   messages are not intended to be fully descriptive but to offer basic
+   title information.  Clients MAY choose to completely ignore them.
+   The details on the comments format can be found in the Theora
+   documentation [16].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 13]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Configuration Ident              | 0 | 2 |      1|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            length             |            Comment           ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                           Comment                           ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                           Comment                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 9: Comment Packet
+
+   The 2 byte length field is necessary since this Theora packet could
+   be fragmented.
+
+
+5.  Frame Packetizing
+
+   Each RTP packet contains either one complete Theora packet, one
+   Theora packet fragment, or an integer number of complete Theora
+   packets (up to a maximum of 15 packets, since the number of packets
+   is defined by a 4 bit value).
+
+   Any Theora data packet that is less than path MTU SHOULD be bundled
+   in the RTP packet with as many Theora packets as will fit, up to a
+   maximum of 15.  Path MTU is detailed in [7] and [8].
+
+   A fragmented packet has a zero in the last four bits of the payload
+   header.  The RTP packet containing the first fragment will set the
+   Fragment type to 1.  Each RTP packet after the first will set the
+   Fragment type to 2 in the payload header.  The RTP packet containing
+   the last fragment of the Theora packet will have the Fragment type
+   set to 3.  If the fragmented Theora packet spans only two RTP
+   packets, the first will set the Fragment type field to 1 and the
+   second will set it to 2.  To maintain the correct sequence for
+   fragmented packet reception the timestamp field of fragmented packets
+
+
+
+Barbato                 Expires January 22, 2007               [Page 14]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   MUST be the same as the first packet sent, with the sequence number
+   incremented as normal for the subsequent RTP packets.
+
+5.1.  Example Fragmented Theora Packet
+
+   Here is an example fragmented Theora packet split over three RTP
+   packets.  Each packet contains the standard RTP headers as well as
+   the 4 octets Theora headers.
+
+      Packet 1:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1000                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Configuration Ident              | 1 | 0 |      0|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Payload Length         |           Theora data        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 10: Example Fragmented Packet (Packet 1)
+
+   In this packet the initial sequence number is 1000 and the timestamp
+   is xxxxx.  The Fragment type field is set to one, indicating it is
+   the start packet of a serie of fragments.  The number of packets
+   field is set to 0, and as the payload is raw Theora data the Theora
+   payload type field is set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 15]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+      Packet 2:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1001                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Configuration Ident              | 2 | 0 |      0|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Payload Length         |              ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 11: Example Fragmented Packet (Packet 2)
+
+   The Fragment type field is set to 2 and the number of packets field
+   is set to 0.  For large Theora fragments there can be several of
+   these type of payload packets.  The maximum RTP packet size SHOULD be
+   no greater than the path MTU, including all RTP and payload headers.
+   The sequence number has been incremented by one but the timestamp
+   field remains the same as the initial packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 16]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+      Packet 3:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1002                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Configuration Ident              | 3 | 0 |      0|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Payload Length         |                              ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                         Theora data                         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 12: Example Fragmented Packet (Packet 3)
+
+   This is the last Theora fragment packet.  The Fragment type filed is
+   set to 3 and the packet count remains set to 0.  As in the previous
+   packets the timestamp remains set to the first packet in the sequence
+   and the sequence number has been incremented.
+
+5.2.  Packet Loss
+
+   As there is no error correction within the Theora stream, packet loss
+   will result in a loss of signal.  Packet loss is more of an issue for
+   fragmented Theora packets as the client will have to cope with the
+   handling of the Fragment type field.  If we use the fragmented Theora
+   packet example above and the first packet is lost the client MUST
+   detect that the next packet has the packet count field set to 0 and
+   the Fragment type is set to 2 and MUST drop it.  The next packet,
+   which is the final fragmented packet, MUST be dropped in the same
+   manner.  Feedback reports on lost and dropped packets MUST be sent
+   back via RTCP.[note: reordering]
+
+   If a particular multicast session has a large number of participants
+   care must be taken to prevent an RTCP feedback implosion, [9], in the
+   event of packet loss from a large number of participants.
+
+   Loss of any of the Configuration fragment will result in the loss of
+   the full Configuration packet as detailed in the Loss of
+
+
+
+Barbato                 Expires January 22, 2007               [Page 17]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   Configuration Headers (Section 3.3) section.
+
+
+6.  IANA Considerations
+
+   MIME media type name: video
+
+   MIME subtype: theora
+
+   Required Parameters:
+
+      sampling: Determines the chroma subsampling format.
+
+      width: Determines the number of pixels per line.  This is an
+         integer between 1 and 1048561 and MUST be in multiples of 16.
+
+      height: Determines the number of lines per frame encoded.  This is
+         an integer between 1 and 1048561 and MUST be in multiples of
+         16.
+
+      delivery-method: indicates the delivery methods in use, the
+         possible values are: inline, in_band, out_band/specific_name
+         Where "specific_name" is the name of the out of band delivery
+         method.
+
+      configuration: the base16 [11] (hexadecimal) representation of the
+         Packed Headers (Section 3.2.1).
+
+   Optional Parameters:
+
+      configuration-uri: the URI of the configuration headers in case of
+         out of band transmission.  In the form of
+         "protocol://path/to/resource/".  Depending on the specific
+         method the single ident packets could be retrived by their
+         number or aggregated in a single stream, aggregates MAY be
+         compressed using gzip [12] or bzip2 [14] and an sha1 [13]
+         checksum MAY be provided in the form of
+         "protocol://path/to/resource/aggregated.bz2!sha1hash"
+
+   Encoding considerations:
+
+      This media type is framed and contains binary data.
+
+   Security Considerations:
+
+      See Section 6 of RFC XXXX.
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 18]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   Interoperability considerations:
+
+      None
+
+   Published specification:
+
+      RFC XXXX [RFC Editor: please replace by the RFC number of this
+      memo, when published]
+
+      Ogg Theora I specification: Codec setup and packet decode.
+      Available from the Xiph website, http://www.xiph.org
+
+   Applications which use this media type:
+
+      Audio streaming and conferencing tools
+
+   Additional information:
+
+      None
+
+   Person & email address to contact for further information:
+
+      Luca Barbato: <lu_zero@gentoo.org>
+      IETF Audio/Video Transport Working Group
+
+   Intended usage:
+
+      COMMON
+
+   Restriction on usage:
+
+      This media type depends on RTP framing, and hence is only defined
+      for transfer via RTP [3]
+
+   Author:
+
+      Luca Barbato
+
+   Change controller:
+
+      IETF AVT Working Group
+
+
+6.1.  Mapping MIME Parameters into SDP
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [6], which is commonly used to describe RTP sessions.  When SDP is
+
+
+
+Barbato                 Expires January 22, 2007               [Page 19]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   used to specify sessions the mapping are as follows:
+
+   o  The MIME type ("video") goes in SDP "m=" as the media name.
+
+   o  The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding
+      name.
+
+   o  The clock rate in the "a=rtpmap" line MUST be 90000
+
+   o  The mandated parameters "delivery-method" and "configuration" MUST
+      be included in the SDP "a=fmpt" attribute.
+
+   o  The optional parameter "configuration-uri", when present, MUST be
+      included in the SDP "a=fmpt" attribute and MUST follow the
+      delivery-method that applies.
+
+   If the stream uses multiple decoder setup configurations and all of
+   them are known in advance, the Configuration Packet for each file
+   SHOULD be packaged together and passed to the client using the
+   configuration attribute.
+
+   The URI specified in the configuration-uri attribute MUST point to a
+   location where all of the Configuration Packets needed for the life
+   of the session reside.
+
+6.1.1.  SDP Example
+
+   The following example shows a basic SDP for a single stream.  The
+   first configuration packet is inlined in the sdp, other
+   configurations could be fetched at any time from the first provided
+   uri using or all the known configuration could be downloaded using
+   the second uri.  The inline base16 [11] configuration string is
+   omitted because of the lenght.
+      c=IN IP4 192.0.0.1
+      m=video RTP/AVP 98
+      a=rtpmap:98 theora/90000
+      a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-
+      method=inline; configuration=base16string1; delivery-
+      method=out_band/rtsp; delivery-method=out_band/rtsp;
+      configuration-uri=rtsp://path/to/resource/; delivery-
+      method=out_band/http; configuration-uri=http://another/path/to/
+      resource/aggregate.bz2!sha1hash;
+
+6.2.  Usage with the SDP Offer/Answer Model
+
+   The offer, as described in An Offer/Answer Model Session Description
+   Protocol [5], may contain a large number of delivery methods per
+   single fmtp attribute, the answerer MUST remove every delivery-method
+
+
+
+Barbato                 Expires January 22, 2007               [Page 20]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   and configuration-uri not supported.  All the parameters MUST not be
+   altered on answer otherwise.
+
+
+7.  Examples
+
+   The following examples are common usage patterns that MAY be applied
+   in such situations, the main scope of this section is to explain
+   better usage of the transmission vectors.
+
+7.1.  Stream Video
+
+   This is one of the most common situation: one single server streaming
+   content in multicast, the clients may start a session at random time.
+   The content itself could be a mix of live stream, as the wj's voice
+   or studio scenes, and stored streams, as the music she plays.
+
+   In this situation we don't know in advance how many codebooks we will
+   use.  The clients can join anytime and users expect to start the
+   fruition of the content in a short time.
+
+   On join the client will receive the current Configuration necessary
+   to decode the current streams inlined in the SDP so that the decoding
+   will start immediately after.
+
+   When the streamed content changes the new Configuration is sent in-
+   band before the actual stream, and the Configuration that has to be
+   sent inline in the SDP updated.  Since the inline method is
+   unreliable, an out of band fallback is provided.
+
+   The client could choose to fetch the Configuration from the alternate
+   source as soon it discovers a Configuration packet got lost inline or
+   use selective retransmission [17], if the server supports the
+   feature.
+
+   A serverside optimization would be to keep an hash list of the
+   Configurations per session to avoid packing all of them and send the
+   same Configuration with different Ident tags
+
+   A clientside optimization would be to keep a tag list of the
+   Configurations per session and don't process configuration packets
+   already known.
+
+
+8.  Security Considerations
+
+   RTP packets using this payload format are subject to the security
+   considerations discussed in the RTP specification [3].  This implies
+
+
+
+Barbato                 Expires January 22, 2007               [Page 21]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+   that the confidentiality of the media stream is achieved by using
+   encryption.  Because the data compression used with this payload
+   format is applied end-to-end, encryption may be performed on the
+   compressed data.  Where the size of a data block is set care MUST be
+   taken to prevent buffer overflows in the client applications.
+
+
+9.  Acknowledgments
+
+   This document is a continuation of draft-kerr-avt-theora-rtp-00.txt
+
+   Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
+   Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann,
+   Alessandro Salvatori, Politecnico di Torino (LS)^3/IMG Group in
+   particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
+   Juan Carlos De Martin.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+         RFC 3533.
+
+   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", RFC 2119.
+
+   [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+         "RTP: A Transport Protocol for real-time applications",
+         RFC 3550.
+
+   [4]   Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
+         Conferences with Minimal Control.", RFC 3551.
+
+   [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+         Session Description Protocol (SDP)", RFC 3264.
+
+   [6]   Handley, M. and V. Jacobson, "SDP: Session Description
+         Protocol", RFC 2327.
+
+   [7]   Mogul et al., J., "Path MTU Discovery", RFC 1063.
+
+   [8]   McCann et al., J., "Path MTU Discovery for IP version 6",
+         RFC 1981.
+
+   [9]   Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
+         "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
+
+
+
+Barbato                 Expires January 22, 2007               [Page 22]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+         Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
+         progress).
+
+   [10]  Barbato, L., "RTP Payload Format for Vorbis Encoded Audio -
+         draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
+         progress).
+
+   [11]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548.
+
+   [12]  Deutsch, P., "GZIP file format specification version 4.3",
+         RFC 1952.
+
+   [13]  National Institute of Standards and Technology, "Secure Hash
+         Standard", May 1993.
+
+   [14]  Seward, J., "libbz2 and bzip2".
+
+10.2.  Informative References
+
+   [15]  "libTheora: Available from the Xiph website,
+         http://www.xiph.org".
+
+   [16]  "Theora I specification:  Codec setup and packet decode.
+         http://www.xiph.org/theora/doc/Theora_I_spec.pdf".
+
+   [17]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+         Extended Reports (RTCP XR)", RFC 3611, November 2003.
+
+   [18]  "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
+         Procedures for DCEs Using Asynchronous-to-Synchronous
+         Conversion. International Telecommunications Union. Available
+         from the ITU website, http://www.itu.int".
+
+   [19]  "ISO 3309, October 1984, 3rd Edition. Information Processing
+         Systems--Data Communication High-Level Data Link Control
+         Procedure--Frame Structure. International Organization for
+         Standardization.".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 23]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+Author's Address
+
+   Luca Barbato
+   Xiph.Org
+
+   Email: lu_zero@gentoo.org
+   URI:   http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 24]
+\f
+Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Barbato                 Expires January 22, 2007               [Page 25]
+\f
diff --git a/doc/draft-ietf-avt-rtp-theora-00.xml b/doc/draft-ietf-avt-rtp-theora-00.xml
new file mode 100644 (file)
index 0000000..2f8af39
--- /dev/null
@@ -0,0 +1,1146 @@
+<?xml version='1.0'?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
+<?rfc toc="yes" ?>
+<?rfc compact='yes'?>
+
+<rfc ipr="full3978" docName="RTP Payload Format for Theora Encoded Video">
+
+<front>
+<title>draft-ietf-avt-rtp-theora-00</title>
+
+<author initials="L" surname="Barbato" fullname="Luca Barbato">
+<organization>Xiph.Org</organization>
+<address>
+<email>lu_zero@gentoo.org</email>
+<uri>http://www.xiph.org/</uri>
+</address>
+</author>
+
+<date day="21" month="July" year="2006" /> 
+<area>General</area>
+<workgroup>AVT Working Group</workgroup>
+<keyword>I-D</keyword>
+
+<keyword>Internet-Draft</keyword>
+<keyword>Theora</keyword>
+<keyword>RTP</keyword>
+
+<abstract>
+<t>
+This document describes a RTP payload format for transporting Theora encoded video. It details the RTP encapsulation mechanism for raw Theora data and configuration headers necessary to configure the decoder.
+</t>
+
+<t>
+Also included within the document are the necessary details for the use of Theora with MIME and Session Description Protocol (SDP).
+</t>
+
+</abstract>
+
+<note title="Editors Note">
+<t>
+All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
+</t>
+</note>
+
+</front>
+
+<middle>
+
+<section anchor="Introduction" title="Introduction">
+<t>
+Theora is a general purpose, lossy video codec. It is based on the VP3 video codec produced by On2 Technologies and has been donated to the Xiph.org Foundation.</t>
+
+<t>
+Theora I is a block-based lossy transform codec that utilizes an 8 x 8 Type-II Discrete Cosine Transform and block-based motion compensation.  This places it in the same class of codecs as MPEG-1, MPEG-2, MPEG-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).
+</t>
+
+<t>
+Theora provides none of its own framing, synchronization, or protection against transmission errors. Instead, the codec expects to receive a discrete sequence of data packets. Theora is a free-form variable bit rate (VBR) codec, and these 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 <xref target="rfc3533"></xref> or RTP/AVP <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Theora I currently supports progressive video data of arbitrary dimensions at a constant frame rate in one of several Y'CbCr color spaces.
+Three different chroma subsampling formats are supported: 4:2:0, 4:2:2, and 4:4:4. The Theora I 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. For performance reason, arbitrary frame sizes will be encoded rounding both dimensions to the upper multiple of 16. The original width and height will be encoded in the header and the decoder will use this information to clip the decoded frame to the right dimensions.
+</t>
+
+<t>
+Theora is similar to the Vorbis audio <xref target="vorbisrtp"></xref> in that the decoder reads the probability model for the entropy coder and all quantization parameters from special "header" packets at the start of the compressed data. It is therefore impossible to decode any video data without having previously fetched the codec info and codec setup headers, although Theora can begin to decode at an arbitrary intra-frame packet so long as the codec has been initialized with the associated headers.
+</t>
+
+<section anchor="Terminology" title="Terminology">
+
+<t>
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
+and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
+</t>
+
+</section>
+</section>
+
+<section anchor="Payload Format" title="Payload Format">
+
+<t>
+For RTP based transportation of Theora encoded video the standard RTP header is followed by a 4 octets payload header, then the payload data. The payload headers are used to associate the Theora data with its associated decoding codebooks as well as indicating if the following packet contains fragmented Theora data and/or the number of whole Theora data frames. The payload data contains the raw Theora bitstream information.
+</t>
+
+<t>
+For RTP based transport of Theora encoded video the standard RTP header is followed by a 4 octets payload header, then the payload data.
+</t>
+
+<section anchor="RTP Header" title="RTP Header">
+
+<t>
+The format of the RTP header is specified in <xref target="rfc3550"></xref> and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification. 
+</t>
+
+<figure anchor="RTP Header Figure" title="RTP Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           timestamp                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see <xref target="rfc3550"></xref> and <xref target="rfc3551"></xref> for details). For Theora RTP, the following values are used.
+</t>
+
+<t>
+Version (V): 2 bits</t><t>
+This field identifies the version of RTP. The version used by this specification is two (2).
+</t>
+
+<t>
+Padding (P): 1 bit</t><t>
+Padding MAY be used with this payload format according to section 5.1 of <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Extension (X): 1 bit</t><t>
+The Extension bit is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+CSRC count (CC): 4 bits</t><t>
+The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Marker (M): 1 bit</t><t>
+The Marker bit is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Payload Type (PT): 7 bits</t><t>
+An RTP profile for a class of applications is expected to assign a payload type for this format, or a dynamically allocated payload type SHOULD be chosen which designates the payload as Theora.
+</t>
+
+<t>
+Sequence number: 16 bits</t><t>
+The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. This field is detailed further in <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Timestamp: 32 bits</t><t>
+A timestamp representing the presentation time of the first sample of the first Theora packet in the RTP packet. The clock frequency MUST be set to 90kHz.
+</t>
+
+<t>
+SSRC/CSRC identifiers: </t><t>
+These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in <xref target="rfc3550"></xref>.
+</t>
+
+</section>
+
+<section anchor="Payload Header" title="Payload Header">
+
+<t>
+The 4 octets following the RTP Header section represent the Payload Header. This header is split into a number of bitfields detailing the format of the following Payload Datagrams.
+</t>
+
+<figure anchor="Payload Header Figure" title="Payload Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Configuration Ident             | F |TDT|# pkts.| 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   
+   +-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Configuration Ident: 24 bits</t>
+<t>
+This 24 bit field is used to associate the Theora data to a decoding Packed Configuration.
+</t>
+
+<t>
+Fragment type (F): 2 bit</t>
+<t>
+This field is set according to the following list
+</t>
+<vspace blankLines="1" />
+<list style="empty">
+<t>      0 = Not Fragmented</t>
+<t>      1 = Start Fragment</t>
+<t>      2 = Continuation Fragment</t>
+<t>      3 = End Fragment</t>
+</list>
+
+<t>This field must be zero if the number of packets field is non-zero.</t>
+
+<t>
+Theora Data Type (TDT): 2 bits</t>
+<t>
+This field sets the packet payload type for the Theora data.  There are currently three Theora payload types currently used and one reserved for future use. 
+</t>
+
+<vspace blankLines="1" />
+<list style="empty">
+<t>      0 = Raw Theora payload</t>
+<t>      1 = Theora Packed Configuration payload</t>
+<t>      2 = Legacy Theora Comment payload</t>
+<t>      3 = Reserved</t>
+</list>
+
+<t> The packets with a TDT of value 3 MUST be ignored </t>
+
+<t>
+The last 4 bits represent the number of complete packets in this payload. This provides a maximum number of 15 Theora packets in the payload. If the packet contains fragmented data the number of packets MUST be set to 0.
+</t>
+
+</section>
+
+<section anchor="Payload Data" title="Payload Data">
+
+<t>
+Each Theora payload section starts with a two octets length header that is used to represent the size of the following data payload, followed by the raw Theora packet data.
+</t>
+
+<figure anchor="Payload Data Figure" title="Payload Data">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Payload Length         |          Theora Data         ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The Theora codec uses relatively unstructured raw packets containing binary integer fields of arbitrary width that often do not fall on an octet boundary. When a Theora encoder produces packets, 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 zeros.
+</t>
+
+<t>
+For payloads which consist of multiple Theora packets the payload data consists of the payload length field followed by the first Theora packet's data, then the payload length followed by the second Theora packet, and so on for each of the Theora packets in the payload.
+</t>
+
+</section>
+
+<section anchor="Example RTP Packet" title="Example RTP Packet">
+
+<t>
+Here is an example RTP packet containing two Theora packets.
+</t>
+<t>
+RTP Packet Header:
+</t>
+
+<figure anchor="Example RTP Packet Figure" title="Example RTP Packet">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | 2 |0|0|  0    |0|      PT     |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           timestamp                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          synchronisation source (SSRC) identifier             |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+
+<t>
+Payload Data:
+</t>
+
+<figure anchor="Example Theora Payload Figure" title="Example Theora Payload Packet">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Configuration Ident             | 0 | 0 | 2 pks |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Payload Length         |                              ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..           data               |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Theora data                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The payload portion of the packet begins with the 24 bit Configuration ident field followed by 8 bits describing the payload. The Fragment type field is set to 0, indicating that this packet contains whole Theora frame data. The Data type field is set to 0 (theora raw data). The number of whole Theora data packets is set to 2.
+</t>
+
+<t>
+Each of the payload blocks starts with the two octets length field followed
+by the variable length Theora packet data.
+</t>
+
+</section>
+</section>
+
+<section anchor="Configuration Headers" title="Configuration Headers">
+
+<t>
+To decode a Theora stream three configuration header packets are needed.  The first (Identification Header) indicates frame dimensions, quality, blocks used and Theora encoder version. The second (Comment Header) contains stream metadata and the third (Setup Header) contains details of the dequantization and Huffman tables.
+</t>
+
+<t>
+Since this information must be transmitted reliably, and as the RTP stream may change certain configuration data mid-session, there are different methods for delivering this configuration data to a client, both in-band and out-of-band, which are detailed below. SDP delivery is used to set up an initial state for the client application. The changes may be due to different dequantization and Huffman tables as well as different bitrates of the stream.
+</t>
+
+<t>
+The delivery vectors in use are specified by an SDP attribute that indicates the method and the optional URI where the Theora <xref target="Packed Configuration">Packed Configuration</xref> Packets could be fetched. Different delivery methods MAY be advertised for the same session. The in-band codebook delivery SHOULD be considered as baseline, out-of-band delivery methods that don't use RTP will not be described in this document. For non chained streams, the RECOMMENDED Configuration delivery method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping MIME Parameters into SDP"> IANA considerations</xref>
+</t>
+
+<t>
+The 24 bit Ident field is used to map which Configuration will be used to decode a packet. When the Ident field changes, it indicates that a change in the stream has taken place. The client application MUST have in advance the correct configuration and if the client detects a change in the Ident value and does not have this information it MUST NOT decode the raw data associated until it has fetched the correct Configuration.
+</t>
+
+
+<section anchor="In-band Header Transmission" title="In-band Header Transmission">
+
+<t>
+The <xref target="Packed Configuration">Packed Configuration</xref> Payload is sent in-band with the packet type bits set to match the payload type. Clients MUST be capable of dealing with periodic re-transmission of the configuration headers.
+</t>
+
+<section anchor="Packed Configuration" title="Packed Configuration">
+
+<t>
+A Theora Packed Configuration is identified by a payload type field of 1. Of the three headers, defined in the <xref target="theora-spec-ref">Theora I specification</xref>, the identification and the setup will be packed together, while the comment header will be completely suppressed. It is up to the client to provide a minimal size comment header to the decoder if required by the implementation.
+</t>
+
+<figure anchor="Packed Configuration Figure" title="Packed Configuration Figure">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Configuration Ident             | 0 | 1 |      1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             length            |          Identification      ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Identification                       ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Identification                       ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Identification                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..              |                      Setup                   ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                            Setup                            ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                            Setup                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+<t>The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 since the packet bears full Packed configuration, the number of packet is set to 1. In practice, Packed Headers usually need to be fragmented to fit the path MTU.
+</t>
+
+</section>
+
+</section>
+
+<section anchor="Out of Band Transmission" title="Out of Band Transmission">
+
+<t>
+This section, as stated above, does not cover all the possible out-of-band delivery methods since they rely on different protocols and are linked to specific applications. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+</t>
+
+<section anchor="Packed Headers" title="Packed Headers"> 
+
+<t>
+As mentioned above, the recommended delivery vector for Theora configuration data is via a retrieval method that can be performed using a reliable transport protocol. As the RTP headers are not required for this method of delivery the structure of the configuration data is slightly different. The packed header starts with a 32 bit count field which details the number of packed headers that are contained in the bundle. Next is the Packed header payload for each setup id.
+</t>
+
+<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
+<artwork><![CDATA[
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Number of packed headers                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packed header                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packed header                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Since the Configuration Ident and the Identification Header are fixed length there is only a 16bit Length tag to define the length of the packed headers.
+</t>
+
+<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Configuration Ident              |              ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..   Length     |              Identification Header           ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                    Identification Header                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Setup Header                         ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Setup Header                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork></figure>
+
+<t>The key difference from the in-band format is that there is no need for the payload header octet.
+</t>
+
+<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations"> 
+
+<t>
+The following IANA considerations MUST only be applied to the packed headers.
+</t>
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="MIME media type name:"> video </t>
+
+<vspace blankLines="1" />
+
+<t hangText="MIME subtype:"> theora-config </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Required Parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Optional Parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Encoding considerations:">
+<vspace blankLines="1" />
+This media type contains binary data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Security Considerations:">
+<vspace blankLines="1" />
+See Section 6 of RFC XXXX.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Interoperability considerations:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Published specification:">
+<vspace blankLines="1" />
+RFC XXXX [RFC Editor: please replace by the RFC number of  this memo,
+       when published]
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Applications which use this media type:">
+<vspace blankLines="1" />
+Theora encoded video, configuration data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Additional information:"> 
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Person &amp; email address to contact for further information:">
+<vspace blankLines="1" />
+Luca Barbato: &lt;lu_zero@gentoo.org&gt;
+<vspace blankLines="0" />
+IETF Audio/Video Transport Working Group
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Intended usage:">
+COMMON
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Restriction on usage:">
+<vspace blankLines="1" />
+This media type does not depend on the transport.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Author:">
+<vspace blankLines="1" />
+Luca Barbato</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Change controller:">
+<vspace blankLines="1" />
+IETF AVT Working Group</t>
+</list>
+
+</section>
+</section>
+
+</section>
+
+<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers"> 
+
+<t>
+Unlike the loss of raw Theora payload data, the loss of a configuration header can lead to a situation where it will not be possible to successfully decode the stream.
+</t>
+
+<t>
+A loss of a Configuration Packet causes the stream decoder to halt and SHOULD be reported to the client as well as a loss report sent via RTCP.
+</t>
+
+</section>
+
+</section>
+
+<section anchor="Comment Headers" title="Comment Headers">
+
+<t>
+When the payload type is set to 2, the packet contains comment metadata such as artist name, track title and so on. These metadata messages are not intended to be fully descriptive but to offer basic title information. Clients MAY choose to completely ignore them. The details on the comments format can be found in the <xref target="theora-spec-ref">Theora documentation</xref>.
+</t>
+
+<figure anchor="Comment Packet Figure" title="Comment Packet">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Configuration Ident              | 0 | 2 |      1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            length             |            Comment           ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                           Comment                           ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                           Comment                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>The 2 byte length field is necessary since this Theora packet could be fragmented.</t>
+
+</section>
+
+<section anchor="Frame Packetizing" title="Frame Packetizing">
+
+<t>
+Each RTP packet contains either one complete Theora packet, one Theora packet fragment, or an integer number of complete Theora packets (up to a maximum of 15 packets, since the number of packets is defined by a 4 bit value).
+</t>
+
+<t>
+Any Theora data packet that is less than path MTU SHOULD be bundled in the RTP packet with as many Theora packets as will fit, up to a maximum of 15.  Path MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
+</t>
+
+<t>
+A fragmented packet has a zero in the last four bits of the payload header. The RTP packet containing the first fragment will set the Fragment type to 1. Each RTP packet after the first will set the Fragment type to 2 in the payload header.  The RTP packet containing the last fragment of the Theora packet will have the Fragment type set to 3. If the fragmented Theora packet spans only two RTP packets, the first will set the Fragment type field to 1 and the second will set it to 2.  To maintain the correct sequence for fragmented packet reception the timestamp field of fragmented packets MUST be the same as the first packet sent, with the sequence number incremented as normal for the subsequent RTP packets.</t>
+
+<section anchor="Example Fragmented Theora Packet" title="Example Fragmented Theora Packet">
+
+<t>
+Here is an example fragmented Theora packet split over three RTP packets.  Each packet contains the standard RTP headers as well as the 4 octets Theora headers.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
+<artwork><![CDATA[
+   Packet 1:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1000                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Configuration Ident              | 1 | 0 |      0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Payload Length         |           Theora data        ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+In this packet the initial sequence number is 1000 and the timestamp is xxxxx.  The Fragment type field is set to one, indicating it is the start packet of a serie of fragments. The number of packets field is set to 0, and as the payload is raw Theora data the Theora payload type field is set to 0.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
+<artwork><![CDATA[
+   Packet 2:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1001                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Configuration Ident              | 2 | 0 |      0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Payload Length         |              ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The Fragment type field is set to 2 and the number of packets field is set to 0. For large Theora fragments there can be several of these type of payload packets. The maximum RTP packet size SHOULD be no greater than the path MTU, including all RTP and payload headers. The sequence number has been incremented by one but the timestamp field remains the same as the initial packet.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
+<artwork><![CDATA[
+   Packet 3:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1002                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Configuration Ident              | 3 | 0 |      0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Payload Length         |                              ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                         Theora data                         ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+This is the last Theora fragment packet. The Fragment type filed is set to 3 and the packet count remains set to 0. As in the previous packets the timestamp remains set to the first packet in the sequence and the sequence number has been incremented.
+</t>
+
+</section>
+
+<section anchor="Packet Loss" title="Packet Loss">
+
+<t>
+As there is no error correction within the Theora stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Theora packets as the client will have to cope with the handling of the Fragment type field. If we use the fragmented Theora packet example above and the first packet is lost the client MUST detect that the next packet has the packet count field set to 0 and the Fragment type is set to 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. Feedback reports on lost and dropped packets MUST be sent back via RTCP.[note: reordering]
+</t>
+
+<t>
+If a particular multicast session has a large number of participants care must be taken to prevent an RTCP feedback implosion, <xref target="rtcp-feedback"></xref>, in the event of packet loss from a large number of participants.
+</t>
+
+<t>
+Loss of any of the Configuration fragment will result in the loss of the full Configuration packet as detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
+</t>
+
+</section>
+</section>
+
+<section anchor="IANA Considerations" title="IANA Considerations"> 
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="MIME media type name:"> video </t>
+
+<vspace blankLines="1" />
+
+<t hangText="MIME subtype:"> theora </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Required Parameters:">
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+
+<t hangText="sampling:"> Determines the chroma subsampling format.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="width:"> Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16. 
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="height:">Determines the number of lines per frame encoded. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band/specific_name<vspace blankLines="0" />
+Where "specific_name" is the name of the out of band delivery method.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="configuration:"> the <xref target="rfc3548">base16</xref> (hexadecimal) representation of the <xref target="Packed Headers">Packed Headers</xref>.
+</t>
+</list>
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Optional Parameters:">
+
+<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="configuration-uri:"> the URI of the configuration headers in case of out of band transmission.  In the form of "protocol://path/to/resource/".  Depending on the specific method the single ident packets could be retrived by their number or aggregated in a single stream, aggregates MAY be compressed using <xref target="rfc1952">gzip</xref> or <xref target="BZ2">bzip2</xref> and an <xref target="FIPS180">sha1</xref> checksum MAY be provided in the form of "protocol://path/to/resource/aggregated.bz2!sha1hash"</t>
+</list>
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Encoding considerations:">
+<vspace blankLines="1" />
+This media type is framed and contains binary data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Security Considerations:">
+<vspace blankLines="1" />
+See Section 6 of RFC XXXX.</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Interoperability considerations:">
+<vspace blankLines="1" />
+None</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Published specification:">
+
+<vspace blankLines="1" />
+
+<t> RFC XXXX [RFC Editor: please replace by the RFC number of  this memo, when published]</t>
+<vspace blankLines="1" />
+<t>Ogg Theora I specification:  Codec setup and packet decode. Available from the Xiph website, http://www.xiph.org</t>
+
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Applications which use this media type:">
+<vspace blankLines="1"/>
+Video streaming and conferencing tools </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Additional information:">
+<vspace blankLines="1" />
+None </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Person &amp; email address to contact for further information:">
+
+<vspace blankLines="1" />
+
+<t>Luca Barbato: &lt;lu_zero@gentoo.org&gt;</t>
+<t>IETF Audio/Video Transport Working Group</t>
+
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Intended usage:">
+<vspace blankLines="1" />
+COMMON</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Restriction on usage:">
+<vspace blankLines="1" />
+This media type depends on RTP framing, and hence is only defined for transfer via <xref target="rfc3550">RTP</xref></t>
+
+<vspace blankLines="1" />
+
+<t hangText="Author:">
+<vspace blankLines="1"/>Luca Barbato</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Change controller:"><vspace blankLines="1"/> IETF AVT Working Group</t>
+
+<vspace blankLines="1" />
+
+</list>
+
+<section anchor="Mapping MIME Parameters into SDP" title="Mapping MIME Parameters into SDP"> 
+
+<t>
+The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) <xref target="rfc2327"></xref>, which is commonly used to describe RTP sessions.  When SDP is used to specify sessions the mapping are as follows:
+</t>
+
+<vspace blankLines="1" />
+<list style="symbols">
+
+<t>The MIME type ("video") goes in SDP "m=" as the media name.</t>
+<vspace blankLines="1" />
+
+<t>The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding name.</t>
+<vspace blankLines="1" />
+
+<t>The clock rate in the "a=rtpmap" line MUST be 90000</t>
+<vspace blankLines="1" />
+
+<t>The mandated parameters "delivery-method" and "configuration" MUST be included in the SDP "a=fmpt" attribute.</t>
+<vspace blankLines="1" />
+
+<t>The optional parameter "configuration-uri", when present, MUST be included in the SDP "a=fmpt" attribute and MUST follow the delivery-method that applies.</t>
+</list>
+
+
+<t>
+If the stream uses multiple decoder setup configurations and all of them are known in advance, the Configuration Packet for each file SHOULD be packaged together and passed to the client using the configuration attribute.
+</t>
+
+<t>
+The URI specified in the configuration-uri attribute MUST point to a location where all of the Configuration Packets needed for the life of the session reside.
+</t>
+
+<section anchor="SDP Example" title="SDP Example">
+<t>The following example shows a basic SDP for a single stream. The first configuration packet is inlined in the sdp, other configurations could be fetched at any time from the first provided uri using or all the known configuration could be downloaded using the second uri. The inline <xref target="rfc3548">base16</xref> configuration string is omitted because of the lenght.</t>
+
+<list style="empty">
+<t>c=IN IP4 192.0.0.1</t>
+<t>m=video  RTP/AVP 98</t>
+<t>a=rtpmap:98 theora/90000</t>
+<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-method=inline; configuration=base16string1; delivery-method=out_band/rtsp; delivery-method=out_band/rtsp; configuration-uri=rtsp://path/to/resource/; delivery-method=out_band/http; configuration-uri=http://another/path/to/resource/aggregate.bz2!sha1hash;</t>
+</list>
+</section>
+
+</section>
+
+<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
+
+<t>
+The offer, as described in <xref target="rfc3264">An Offer/Answer Model Session Description Protocol</xref>, may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method and configuration-uri not supported. All the parameters MUST not be altered on answer otherwise.
+</t>
+
+</section>
+
+</section>
+
+<section anchor="Examples" title="Examples">
+
+<t>
+The following examples are common usage patterns that MAY be applied in such situations, the main scope of this section is to explain better usage of the transmission vectors.
+</t>
+<!--
+
+<section anchor="Peer to Peer Internet Messaging" title="Peer to Peer Internet Messaging">
+
+<t>This scenario implies two peers linked through a best effort network, the bandwidth isn't guaranteed and may have large variance, in order to keep the latency low enough dynamic adaptation tecniques [missing reference] are required.</t>
+
+<t>Each peer will receive 2 streams (voice and video) from the other. To determine the quality of the stream and ensure the latency is bearable [put maximum latency here] a form of handshake is required. SIP or Jingle or TINS could be used in this phase.</t>
+
+<t>Since changes in the bitrates will reflect on the setup header, the simplest way to get dynamic adaptation is to consider each stream as a completely different coded, have a payload number for each of them and use the dynamic coding change tecniques.</t>
+
+<t>Due the latency requirement even if sending the Configuration in-band MAY be possible, usually it SHOULD be avoided. Other out of band methods that send Configuration on demand, since they would affect latency as the in-band method, SHOULD be avoided as well. Agree on a set of Configurations related to different bitrates during the session initiation is the best method.</t>
+
+</section>
+-->
+<section anchor="Stream Video" title="Stream Video">
+
+<t>This is one of the most common situation: one single server streaming content in multicast, the clients may start a session at random time. The content itself could be a mix of live stream, as the wj's voice or studio scenes, and stored streams, as the music she plays.</t>
+
+<t>In this situation we don't know in advance how many codebooks we will use. The clients can join anytime and users expect to start the fruition of the content in a short time.</t>
+
+<t>On join the client will receive the current Configuration necessary to decode the current streams inlined in the SDP so that the decoding will start immediately after.</t>
+
+<t>When the streamed content changes the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inline in the SDP updated. Since the inline method is unreliable, an out of band fallback is provided.</t>
+
+<t>The client could choose to fetch the Configuration from the alternate source as soon it discovers a Configuration packet got lost inline or use <xref target="rfc3611">selective retransmission</xref>, if the server supports the feature.</t>
+
+<t>A serverside optimization would be to keep an hash list of the Configurations per session to avoid packing all of them and send the same Configuration with different Ident tags</t>
+
+<t>A clientside optimization would be to keep a tag list of the Configurations per session and don't process configuration packets already known.</t>
+
+</section>
+
+</section>
+
+<section anchor="Security Considerations" title="Security Considerations"> 
+<t>
+RTP packets using this payload format are subject to the security considerations discussed in the RTP specification <xref target="rfc3550"></xref>. This implies that the confidentiality of the media stream is achieved by using encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data. Where the size of a data block is set care MUST be taken to prevent buffer overflows in the client applications.
+</t>
+
+</section> 
+
+<section anchor="Acknowledgments" title="Acknowledgments"> 
+
+<t>This document is a continuation of draft-kerr-avt-theora-rtp-00.txt</t>
+
+<t>
+Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann, Alessandro Salvatori, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
+</t>
+
+</section> 
+
+</middle>
+
+<back>
+
+<references title="Normative References">
+
+<reference anchor="rfc3533">
+<front>
+<title>The Ogg Encapsulation Format Version 0</title>
+<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"></author>
+</front>
+<seriesInfo name="RFC" value="3533" />
+</reference>
+
+<reference anchor="rfc2119">
+<front>
+<title>Key words for use in RFCs to Indicate Requirement Levels </title>
+<author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
+</front>
+<seriesInfo name="RFC" value="2119" />
+</reference> 
+
+<reference anchor="rfc3550">
+<front>
+<title>RTP: A Transport Protocol for real-time applications</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+<author initials="R." surname="Frederick" fullname=""></author>
+<author initials="V." surname="Jacobson" fullname=""></author>
+</front>
+<seriesInfo name="RFC" value="3550" />
+</reference> 
+
+<reference anchor="rfc3551">
+<front>
+<title>RTP Profile for video and Video Conferences with Minimal Control.</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+</front>
+<date month="July" year="2003" />
+<seriesInfo name="RFC" value="3551" />
+</reference> 
+
+<reference anchor="rfc3264">
+<front>
+<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
+<author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg"></author>
+<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne"></author>
+</front>
+<seriesInfo name="RFC" value="3264" />
+</reference> 
+
+<reference anchor="rfc2327">
+<front>
+<title>SDP: Session Description Protocol</title>
+<author initials="M." surname="Handley" fullname="Mark Handley"></author>
+<author initials="V." surname="Jacobson" fullname="Van Jacobson"></author>
+</front>
+<seriesInfo name="RFC" value="2327" />
+</reference>
+
+<reference anchor="rfc1063">
+<front>
+<title>Path MTU Discovery</title>
+<author initials="J." surname="Mogul et al." fullname="J. Mogul et al."></author>
+</front>
+<seriesInfo name="RFC" value="1063" />
+</reference> 
+
+<reference anchor="rfc1981">
+<front>
+<title>Path MTU Discovery for IP version 6</title>
+<author initials="J." surname="McCann et al." fullname="J. McCann et al."></author>
+</front>
+<seriesInfo name="RFC" value="1981" />
+</reference> 
+
+<reference anchor="rtcp-feedback">
+<front>
+<title>Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)</title>
+<author initials="J." surname="Ott" fullname="Joerg Ott"></author>
+<author initials="S." surname="Wenger" fullname="Stephan Wenger"></author>
+<author initials="N." surname="Sato" fullname="Noriyuki Sato"></author>
+<author initials="C." surname="Burmeister" fullname="Carsten Burmeister"></author>
+<author initials="J." surname="Rey" fullname="Jose Rey"></author>
+</front>
+<seriesInfo name="Internet Draft" value="(draft-ietf-avt-rtcp-feedback-11: Work in progress)" />
+</reference> 
+
+<reference anchor="vorbisrtp">
+<front>
+<title>RTP Payload Format for Vorbis Encoded Audio - draft-ietf-avt-vorbis-rtp-00</title>
+<author initials="L." surname="Barbato" fullname="Luca Barbato"></author>
+</front>
+<seriesInfo name="Internet Draft" value="(Work in progress)" />
+</reference> 
+
+<reference anchor="rfc3548">
+<front>
+<title>The Base16, Base32, and Base64 Data Encodings</title>
+<author initials="S." surname="Josefsson" fullname="Simon Josefsson"></author>
+</front>
+<seriesInfo name="RFC" value="3548" />
+</reference>
+
+<reference anchor="rfc1952">
+<front>
+<title>GZIP file format specification version 4.3</title>
+<author initials="P" surname="Deutsch" fullname="L. Peter Deutsch"></author>
+</front>
+<seriesInfo name="RFC" value="1952" />
+</reference>
+
+<reference anchor="FIPS180">
+<front>
+<title>Secure Hash Standard</title>
+<author>
+<organization>National Institute of Standards and Technology</organization>
+</author>
+<date month="May" year="1993"/>
+</front>
+</reference>
+
+<reference anchor="BZ2">
+<front>
+<title>libbz2 and bzip2</title>
+<author initials="J" surname="Seward" fullname="Julian Seward" />
+</front>
+</reference>
+
+</references>
+
+<references title="Informative References">
+<reference anchor="libTheora">
+<front>
+<title>libTheora: Available from the Xiph website, http://www.xiph.org</title>
+</front>
+</reference>
+
+<reference anchor="theora-spec-ref">
+<front>
+<title>Theora I specification:  Codec setup and packet decode.  http://www.xiph.org/theora/doc/Theora_I_spec.pdf</title>
+</front>
+</reference> 
+
+<reference anchor='rfc3611'>
+
+<front>
+<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
+<author initials='T.' surname='Friedman' fullname='T. Friedman'>
+<organization /></author>
+<author initials='R.' surname='Caceres' fullname='R. Caceres'>
+<organization /></author>
+<author initials='A.' surname='Clark' fullname='A. Clark'>
+<organization /></author>
+<date year='2003' month='November' /></front>
+<seriesInfo name='RFC' value='3611' />
+</reference>
+
+
+<reference anchor="ITU-T V42">
+<front>
+<title>
+ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion. International Telecommunications Union. Available from the ITU website, http://www.itu.int
+</title>
+</front>
+</reference>
+
+<reference anchor="ISO 3309">
+<front>
+<title>ISO 3309, October 1984, 3rd Edition. Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure. International Organization for Standardization.
+</title>
+</front>
+</reference>
+</references>
+</back>
+</rfc>
diff --git a/doc/draft-kerr-avt-theora-rtp-00.txt b/doc/draft-kerr-avt-theora-rtp-00.txt
new file mode 100644 (file)
index 0000000..5126152
--- /dev/null
@@ -0,0 +1,1512 @@
+
+
+AVT Working Group                                                P. Kerr
+Internet-Draft                                                  Xiph.Org
+Expires: August 1, 2005                                 January 31, 2005
+
+
+                      draft-kerr-avt-theora-rtp-00
+              RTP Payload Format for Theora Encoded Video
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 1, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a RTP payload format for transporting Theora
+   encoded video.  It details the RTP encapsulation mechanism for raw
+   Theora data and configuration headers consisting of the quantization
+   matrices and the Huffman codebooks for the DCT coefficients, and a
+   table of limit values for the deblocking filter.
+
+   Also included within the document are the necessary details for the
+   use of Theora with MIME and Session Description Protocol (SDP).
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 1]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+Editors Note
+
+   All references to RFC XXXX are to be replaced by references to the
+   RFC number of this memo, when published.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1   RTP Header . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2   Payload Header . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3   Payload Data . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4   Example RTP Packet . . . . . . . . . . . . . . . . . . . .  7
+   3.  Frame Packetizing  . . . . . . . . . . . . . . . . . . . . . .  8
+     3.1   Example Fragmented Theora Packet . . . . . . . . . . . . .  9
+   4.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   5.  Configuration Headers  . . . . . . . . . . . . . . . . . . . . 13
+     5.1   In-band Header Transmission  . . . . . . . . . . . . . . . 13
+       5.1.1   Identification Header  . . . . . . . . . . . . . . . . 13
+       5.1.2   Comment Header . . . . . . . . . . . . . . . . . . . . 15
+       5.1.3   Setup Header . . . . . . . . . . . . . . . . . . . . . 16
+     5.2   Packed Headers Delivery  . . . . . . . . . . . . . . . . . 18
+       5.2.1   Packed Headers IANA Considerations . . . . . . . . . . 21
+     5.3   Setup Header Caching . . . . . . . . . . . . . . . . . . . 22
+     5.4   Loss of Configuration Headers  . . . . . . . . . . . . . . 22
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+     6.1   Mapping MIME Parameters into SDP . . . . . . . . . . . . . 24
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 25
+   9.2   Informative References . . . . . . . . . . . . . . . . . . . 26
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
+       Intellectual Property and Copyright Statements . . . . . . . . 27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 2]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+1.  Introduction
+
+   Theora is a general purpose, lossy video codec.  It is based on the
+   VP3.1 video codec produced by On2 Technologies and has been donated
+   to the Xiph.org Foundation.
+
+   Theora I is a block-based lossy transform codec that utilizes an 8 x
+   8 Type-II Discrete Cosine Transform and block-based motion
+   compensation.  This places it in the same class of codecs as MPEG-1,
+   MPEG-2, MPEG-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).
+
+   Theora provides none of its own framing, synchronization, or
+   protection against transmission errors.  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 [1].  or
+   RTP/AVP [3].
+
+   Theora I currently supports progressive video data of arbitrary
+   dimensions at a constant frame rate in one of several YCbCr color
+   spaces.  Three different chroma subsampling formats are supported:
+   4:2:0, 4:2:2, and 4:4:4.  The Theora I 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.
+
+   Theora is similar to Vorbis audio [9] in that it requires the
+   inclusion of the entire probability model for the DCT coefficients
+   and all the quantization parameters in the bitstream headers to be
+   sent ahead of the video data.  It is therefore impossible to decode
+   any frame in the stream without having previously fetched the codec
+   info and codec setup headers, although Theora can initiate decode at
+   an arbitrary intra-frame packet within a bitstream so long as the
+   codec has been initialized with the setup headers.
+
+1.1  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 3]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+2.  Payload Format
+
+   Each frame of digital video is packetized into one or more RTP
+   packets.  If the data for a complete frame exceeds the network MTU,
+   it SHOULD be fragmented into multiple RTP packets, each smaller than
+   the MTU.  A single RTP packet MAY contain data for more than one
+   Theora frame.
+
+   For RTP based transportation of Theora encoded video the standard RTP
+   header is followed by a 5 octet payload header, then the payload
+   data.
+
+2.1  RTP Header
+
+   The format of the RTP header is specified in [3] and shown in Figure
+   1.  This payload format uses the fields of the header in a manner
+   consistent with that specification.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                          Figure 1: RTP Header
+
+   The RTP header begins with an octet of fields (V, P, X, and CC) to
+   support specialized RTP uses (see [3] and [4] for details).  For
+   Theora RTP, the following values are used.
+
+   Version (V): 2 bits
+
+   This field identifies the version of RTP.  The version used by this
+   specification is two (2).
+
+   Padding (P): 1 bit
+
+   Padding MAY be used with this payload format according to section 5.1
+   of [3].
+
+   Extension (X): 1 bit
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 4]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+   The Extension bit is used in accordance with [3].
+
+   CSRC count (CC): 4 bits
+
+   The CSRC count is used in accordance with [3].
+
+   Marker (M): 1 bit
+
+   The Marker bit is used in accordance with [3].
+
+   Payload Type (PT): 7 bits
+
+   An RTP profile for a class of applications is expected to assign a
+   payload type for this format, or a dynamically allocated payload type
+   SHOULD be chosen which designates the payload as Theora.
+
+   Sequence number: 16 bits
+
+   The sequence number increments by one for each RTP data packet sent,
+   and may be used by the receiver to detect packet loss and to restore
+   packet sequence.  This field is detailed further in [3].
+
+   Timestamp: 32 bits
+
+   A timestamp representing the sampling time of the first sample of the
+   first Theora packet in the RTP packet.  The clock frequency MUST be
+   set to the sample rate of the encoded video data and is conveyed
+   out-of-band as an SDP attribute.
+
+   SSRC/CSRC identifiers:
+
+   These two fields, 32 bits each with one SSRC field and a maximum of
+   16 CSRC fields, are as defined in [3].
+
+2.2  Payload Header
+
+   After the RTP Header section the following five octets are the
+   Payload Header.  This header is split into a number of bitfields
+   detailing the format of the following Payload Data packets.
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 5]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |C|F|0|0|# pkts.|
+      +-+-+-+-+-+-+-+-+
+
+                        Figure 2: Payload Header
+
+   Setup Header Ident: 32 bits
+
+   This 32 bit field is used to associate the Theora data to a decoding
+   Setup Header.  It is created by making a CRC32 checksum of the Setup
+   Header required to decode the particular Theora video stream.
+
+   Continuation (C): 1 bit
+
+   Set to one if this is a continuation of a fragmented packet.
+
+   Fragmented (F): 1 bit
+
+   Set to one if the payload contains complete packets or if it contains
+   the last fragment of a fragmented packet.
+
+   The next two bits are currently reserved and MUST be set to 0.
+
+   The last 4 bits are the number of complete packets in this payload.
+   This provides for a maximum number of 15 Theora packets in the
+   payload.  If the packet contains fragmented data the number of
+   packets MUST be set to 0.
+
+2.3  Payload Data
+
+   Each Theora payload section starts with a three octet header.  The
+   first octet is used to denote what kind of Theora data follows.  Then
+   a two octet length header is used to represent the size of the
+   following data payload, followed by the raw Theora data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 6]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Data type   |        Payload Length         | Theora Data  ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 3: Payload Data
+
+   The data type octet is used to signify the payload data type.  If the
+   first bit is set to 0, this indicates the payload is Theora video
+   data.
+
+   The following values for the Theora payload type are valid:
+
+      0 = Raw Theora data
+      0x80 = Theora Identification header
+      0x81 = Theora Comment header
+      0x82 = Theora Setup header
+
+
+   The Theora packet length header is the length of the Theora data
+   block only and does not count the length octets and payload data type
+   octet.
+
+   The Theora codec uses relatively unstructured raw packets containing
+   binary integer fields of arbitrary width that often do not fall on an
+   octet boundary.  When this happens the bitstream is packed to an
+   octet boundary.  When a Theora encoder produces packets 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 zeros.
+
+   For payloads which consist of multiple Theora packets the payload
+   data consists of the data type field, the payload length field
+   followed by the payload data for each of the Theora packets in the
+   payload.
+
+2.4  Example RTP Packet
+
+   Here is an example RTP packet containing two Theora packets.
+
+   RTP Packet Header:
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 7]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | 2 |0|0|  0    |0|      PT     |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 timestamp (in sample rate units)              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          synchronisation source (SSRC) identifier             |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 4: Example RTP Packet
+
+   Payload Data:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1|0|0| 2 pks |      0x80     |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..    data      |        0      |        Payload Length        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Theora data                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 5: Example Theora Payload Packet
+
+   The payload portion of the packet starts with the 32 bit Setup Header
+   ident field followed by the 8 bit fragment/count fields.  The F bit
+   is set to 1, indicating that this packet contains whole Theora frame
+   data.  The number of whole Theora data packets is set to 2.
+
+   Each of the payload blocks starts with a Data type field, for the
+   first payload this is set to 0x80 indicating it is an Identification
+   header and the second payload is set to 0 indicating it is raw Theora
+   data.  Then the two octet length field is followed by the variable
+   length Theora data.
+
+3.  Frame Packetizing
+
+   Each RTP packet contains either one complete Theora packet, one
+   Theora packet fragment, or an integer number of complete Theora
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 8]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+   packets (up to a max of 15 packets, since the number of packets is
+   defined by a 4 bit value).
+
+   Any Theora data packet that is less than path MTU SHOULD be bundled
+   in the RTP packet with as many Theora packets as will fit, up to a
+   maximum of 15.  Path MTU is detailed in [6] and [7].
+
+   If a Theora packet is larger than 65535 octets it MUST be fragmented.
+   A fragmented packet has a zero in the last four bits of the payload
+   header.  Each fragment after the first will also set the Continued
+   (C) bit to one in the payload header.  The RTP packet containing the
+   last fragment of the Theora packet will have the Fragmented (F) bit
+   set to one.  To maintain the correct sequence for fragmented packet
+   reception the timestamp field of fragmented packets MUST be the same
+   as the first packet sent, with the sequence number incremented as
+   normal for the subsequent RTP packets.
+
+3.1  Example Fragmented Theora Packet
+
+   Here is an example fragmented Theora packet split over three RTP
+   packets.  Each packet contains the standard RTP headers as well as
+   the 5 octet Theora headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 9]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+      Packet 1:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1000                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|0|0|0|      0|       0       |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 6: Example Fragmented Packet (Packet 1)
+
+   In this packet the initial sequence number is 1000 and the timestamp
+   is xxxxx.  The Continuation (C) bit is set to one, indicating it is
+   not the continuation of a fragmented bit, and the Fragmentation (F)
+   is set to 0 indicating it is a fragmented packet.  The number of
+   packets field is set to 0, and as the payload is raw Theora data the
+   Theora payload type field is set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 10]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+      Packet 2:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1001                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1|0|0|0|      0|       0       |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 7: Example Fragmented Packet (Packet 2)
+
+   The C bit is set to 1 and the number of packets field is set to 0.
+   For large Theora fragments there can be several of these type of
+   payload packets.  The maximum packet size SHOULD be no greater than
+   the path MTU, including all RTP and payload headers.  The sequence
+   number has been incremented by one but the timestamp field remains
+   the same as the initial packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 11]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+      Packet 3:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |           1002                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1|1|0|0|      0|       0       |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Theora data                          ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 8: Example Fragmented Packet (Packet 3)
+
+   This is the last Theora fragment packet.  The C and F bits are set
+   and the packet count remains set to 0.  As in the previous packets
+   the timestamp remains set to the first packet in the sequence and the
+   sequence number has been incremented.
+
+4.  Packet Loss
+
+   As there is no error correction within the Theora stream, packet loss
+   will result in a loss of signal.  Packet loss is more of an issue for
+   fragmented Theora packets as the client will have to cope with the
+   handling of the C and F flags.  If we use the fragmented Theora
+   packet example above and the first packet is lost the client SHOULD
+   detect that the next packet has the packet count field set to 0 and
+   the C bit is set and MUST drop it.  The next packet, which is the
+   final fragmented packet, SHOULD be dropped in the same manner, or
+   buffered.  Feedback reports on lost and dropped packets MUST be sent
+   back via RTCP.
+
+   If a particular multicast session has a large number of participants
+   care must be taken to prevent an RTCP feedback implosion, [8], in the
+   event of packet loss from a large number of participants.
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 12]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+5.  Configuration Headers
+
+   To decode a Theora stream three configuration header blocks are
+   needed.  The first header, the Identification Header, indicates the
+   frame dimensions, quality, blocks used and the version of the Theora
+   encoder used.  The second header, the Comment Header, contains stream
+   metadata and the third header, the Setup Header, details which
+   contains dequantization and Huffman tables.
+
+   As the RTP stream may change certain configuration data mid-session
+   there are two different methods for delivering this configuration
+   data to a client, in-band and SDP which is detailed below.  SDP
+   delivery is used to set-up an initial state for the client
+   application and in-band is used to change state during the session.
+   The changes may be due to different metadata or Setup Header as well
+   as different bitrates of the stream.
+
+   Out of the two delivery vectors the use of an SDP attribute to
+   indicate an URI where the configuration and Setup Header data can be
+   obtained is preferred as they can be fetched reliably using TCP.  The
+   in-band Setup Header delivery SHOULD only be used in situations where
+   the link between the client is unidirectional or if the SDP-based
+   information is not available.
+
+   Synchronizing the configuration and Setup Header to the RTP stream is
+   critical.  The 32 bit Setup Header Ident field is used to indicate
+   when a change in the stream has taken place.  The client application
+   MUST have in advance the correct configuration and Setup Headers and
+   if the client detects a change in the Ident value and does not have
+   this information it MUST NOT decode the raw Theora data.
+
+5.1  In-band Header Transmission
+
+   The three header data blocks are sent in-band with the packet type
+   bits set to match the payload type.  Normally the Setup Header and
+   Identification Header are sent once per session if the stream is an
+   encoding of live video, as typically the encoder state will not
+   change, but the encoder state can change at the boundary of chained
+   Theora video files.  Metadata can be sent at the start as well as any
+   time during the life of the session.  Clients MUST be capable of
+   dealing with periodic re-transmission of the configuration headers.
+
+5.1.1  Identification Header
+
+   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.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 13]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1|0|0|      1|     0x80      |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     VMAJ      |     VMIN      |     VREV      |     FMBW      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     FMBW      |              FMBH             |     NSBS      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     NSBS                      |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       NBS                             | NMBS  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       NMBS                            | PICW  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              PICW             |             PICH              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | PICH  |     PICX      |      PICY     |         FRN           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                FRN                    |         FRD           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                FRD                    |         PARN          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         PARN          |               PARD                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | PARD  |      CS       |PF |             NOMBR                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   NOMBR   |   QUAL    | KFGSHIFT|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 9: Identification Header
+
+   The fields listed above have the following meanings:
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 14]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+      VMAJ     = The major version number.  8 bits.
+      VMIN     = The minor version number.  8 bits.
+      VREV     = The version revision number.  8 bits.
+      FMBW     = The width of the frame in macro blocks.  16 bits.
+      FMBH     = The height of the frame in macro blocks.  16 bits.
+      NSBS     = The total number of super blocks in a frame.  32 bits.
+      NBS      = The total number of blocks in a frame.  36 bits.
+      NMBS     = The total number of macro blocks in a frame.  32 bits.
+      PICW     = The width of the picture region in pixels.  20 bits.
+      PICH     = The height of the picture region in pixels.  20 bits.
+      PICX     = The X offset of the picture region in pixels.  8 bits.
+      PICY     = The Y offset of the picture region in pixels.  8 bits.
+      FRN      = The frame-rate numerator.  32 bits.
+      FRD      = The frame-rate denominator.  32 bits.
+      PARN     = The pixel aspect-ratio numerator.  24 bits.
+      PARD     = The pixel aspect-ratio denominator.  24 bits.
+      CS       = The color space.  8 bits.
+      PF       = The pixel format.  2 bits.
+      NOMBR    = The nominal bitrate of the stream, in bits per second.
+      24 bits.
+      QUAL     = The quality hint.  6 bits.
+      KFGSHIFT = The amount to shift the key frame number by in the
+      granule position.  5 bits.
+
+
+5.1.2  Comment Header
+
+   The Theora Comment Header is the second of three header packets that
+   begin a Theora stream.  It is meant for short text comments, not
+   arbitrary metadata; arbitrary metadata belongs in a separate logical
+   stream that provides greater structure and machine parseability.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 15]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1|0|0|      1|     0x81      |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    User comments list length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       User comment length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          User comment                        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                         User comment                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+                       Figure 10: Comment Header
+
+   The format for the data takes the form of a 32 bit field denoting the
+   number of user comments.  Each of the user comments is prefixed by a
+   32 bit length field followed by the comment text encoded in UTF-8.
+
+5.1.3  Setup Header
+
+   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.
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 16]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             xxxxx                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           synchronization source (SSRC) identifier            |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |            contributing source (CSRC) identifiers             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1|0|0|      1|     0x82      |        Payload Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Setup Header Length                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Setup Header                         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Setup Header                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 11: Setup Header
+
+
+5.1.3.1  Setup Header CRC32 Generation
+
+   In order for different implementations of Theora RTP clients and
+   servers to interoperate with each other a common format for the
+   production of the CRC32 hash is required.  The polynomial is
+   X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0.
+
+   The following C code function SHOULD be used by implementations, if
+   not then the code responsible for generating the CRC32 value MUST use
+   the polynomial function above.
+
+   unsigned int crc32 (int length, unsigned char *crcdata)
+   {
+       int index, loop;
+       unsigned int byte, crc, mask;
+
+       index = 0;
+       crc = 0xFFFFFFFF;
+
+       while (index < length) {
+           byte = crcdata [index];
+
+
+
+Kerr                     Expires August 1, 2005                [Page 17]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+           crc = crc ^ byte;
+
+           for (loop = 7; loop >= 0; loop--) {
+               mask = -(crc & 1);
+               crc = (crc >> 1) ^ (0xEDB88320 & mask);
+           }
+           index++;
+       }
+       return ~crc;
+   }
+
+
+5.2  Packed Headers Delivery
+
+   As mentioned above the RECOMMENDED delivery vector for Theora
+   configuration data is via an SDP attribute as this retrieval method
+   can be performed using a reliable transport protocol.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Number of packed headers                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 12: Packed Headers Overview
+
+   As the RTP headers are not required for this method of delivery the
+   structure of the configuration data is slightly different.  The
+   packed header starts with a 32 bit count field which details the
+   number of packed headers that are contained in the bundle.  Next is
+   the packed header payload for each chained Theora file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 18]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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 Length                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Setup Header Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Identification Header                    ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                    Identification Header                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Comment Header                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Comment Header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Setup Header                        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                         Setup Header                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 13: Packed Headers Detail
+
+   The key difference between the in-band format is there is no need for
+   the payload header octet and Setup Header Ident field.  Below are
+   examples of the packed headers format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 19]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     VMAJ      |     VMIN      |     VREV      |     FMBW      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     FMBW      |              FMBH             |     NSBS      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     NSBS                      |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       NBS                             | NMBS  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       NMBS                            | PICW  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              PICW             |             PICH              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | PICH  |     PICX      |      PICY     |         FRN           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                FRN                    |         FRD           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                FRD                    |         PARN          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         PARN          |               PARD                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | PARD  |      CS       |PF |             NOMBR                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   NOMBR   |   QUAL    | KFGSHIFT|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 14: Packed Identification Header
+
+   The alignment of the packed Identification Header is slightly
+   different from the RTP payload type as the payload header is not
+   used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 20]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    User comments list length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       User comment length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          User comment                        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                         User comment                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 15: Packed Comment Header
+
+   The packed Comment Header also as a slightly different structure to
+   that of the RTP payload type with the payload header not being used.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Setup Header Length                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Setup Header                         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Setup Header                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 16: Packed Setup Header
+
+   The packed Setup Header also has a slightly different structure to
+   that of the RTP payload type.  The Setup Header Ident field that is
+   normally part of this structure is moved to the second field of the
+   overall packed structure.
+
+5.2.1  Packed Headers IANA Considerations
+
+   The following IANA considerations MUST only be applied to the packed
+   headers.
+
+   MIME media type name: video
+
+   MIME subtype: theora-config
+
+   Required Parameters:
+
+   None.
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 21]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+   Optional Parameters:
+
+   None.
+
+   Encoding considerations:
+
+   This type is only defined for transfer via HTTP as specified in RFC
+   XXXX.
+
+   Security Considerations:
+
+   See Section 6 of RFC 3047.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+   See RFC XXXX for details.
+
+   Applications which use this media type:
+
+   Theora encoded video, configuration data.
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+
+   Phil Kerr: <phil@plus24.com>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+   Author: Phil Kerr
+
+   Change controller: IETF AVT Working Group
+
+5.3  Setup Header Caching
+
+   Setup Header caching allows clients that have previously connected to
+   a stream to re-use the associated Setup Header and configuration
+   data.  When a client receives a Setup Header it may store it locally
+   and can compare the CRC32 key with that of the new stream and begin
+   decoding before it has received any of the headers.
+
+5.4  Loss of Configuration Headers
+
+   Unlike the loss of raw Theora payload data, loss of a configuration
+
+
+
+Kerr                     Expires August 1, 2005                [Page 22]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+   header can lead to a situation where it will not be possible to
+   successfully decode the stream.
+
+   Out of the three headers, loss of either the Setup Header or
+   Identification Headers MUST result in the halting of stream decoding.
+   Loss of the Comment header SHOULD NOT be regarded as fatal for
+   decoding.  Loss of any of the headers SHOULD be reported to the
+   client as well as a loss report sent via RTCP.
+
+6.  IANA Considerations
+
+   MIME media type name: video
+
+   MIME subtype: theora
+
+   Required Parameters:
+
+   sampling: Determines the chroma subsampling format.
+
+   width: Determines the number of pixels per line.  This is an integer
+   between 1 and 1048561 and MUST be in multiples of 16.
+
+   height: Determines the number of lines per frame.  This is an integer
+   between 1 and 1048561 and MUST be in multiples of 16.
+
+   header: Indicates the URI of the decoding configuration headers.
+
+   Optional Parameters:
+
+   None.
+
+   Encoding considerations:
+
+   This type is only defined for transfer via RTP as specified in RFC
+   XXXX.
+
+   Security Considerations:
+
+   See Section 6 of RFC 3047.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+   See the Theora documentation [11] for details.
+
+   Applications which use this media type:
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 23]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+   Video streaming and conferencing tools
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+
+   Phil Kerr: <phil@plus24.com>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+   Author: Phil Kerr
+
+   Change controller: IETF AVT Working Group
+
+6.1  Mapping MIME Parameters into SDP
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [5], which is commonly used to describe RTP sessions.  When SDP is
+   used to specify sessions the mapping are as follows:
+
+   o  The MIME type ("video") goes in SDP "m=" as the media name.
+
+   o  The MIME subtype ("THEORA") goes in SDP "a=rtpmap" as the encoding
+      name.
+
+   o  The parameter "rate" also goes in "a=rtpmap" as clock rate.
+
+   o  The parameter "channels" also goes in "a=rtpmap" as channel count.
+
+   o  The parameter "header" goes in the SDP "a=fmpt" attribute.
+
+   If the stream comprises chained Theora files the configuration and
+   Setup Headers for each file SHOULD be packaged together and passed to
+   the client using the headers attribute if all the files to be played
+   are known in advance.
+
+   Example:
+
+      c=IN IP4/6
+      m=video  RTP/AVP 98
+      a=rtpmap:98 theora/90000
+      a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720;
+      header=<URI of configuration header>
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 24]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+7.  Security Considerations
+
+   RTP packets using this payload format are subject to the security
+   considerations discussed in the RTP specification [3].  This implies
+   that the confidentiality of the media stream is achieved by using
+   encryption.  Because the data compression used with this payload
+   format is applied end-to-end, encryption may be performed on the
+   compressed data.  Where the size of a data block is set care MUST be
+   taken to prevent buffer overflows in the client applications.
+
+8.  Acknowledgments
+
+   Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
+   Giles.
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC
+        3533.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119.
+
+   [3]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP: A Transport Protocol for real-time applications", RFC
+        3550.
+
+   [4]  Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
+        Conferences with Minimal Control.", RFC 3551.
+
+   [5]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327.
+
+   [6]  Mogul et al., J., "Path MTU Discovery", RFC 1063.
+
+   [7]  McCann et al., J., "Path MTU Discovery for IP version 6", RFC
+        1981.
+
+   [8]  Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey,
+        "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
+        Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
+        progress).
+
+   [9]  Kerr, P., "RTP Payload Format for Vorbis Encoded Audio -
+        draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
+        progress).
+
+
+
+Kerr                     Expires August 1, 2005                [Page 25]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+9.2  Informative References
+
+   [10]  "libTheora: Available from the Xiph website,
+         http://www.xiph.org".
+
+   [11]  "Ogg Theora I spec:  Codec setup and packet decode.
+         http://www.xiph.org/ogg/Theora/doc/Theora-spec-ref.html".
+
+
+Author's Address
+
+   Phil Kerr
+   Xiph.Org
+
+   EMail: phil@plus24.com
+   URI:   http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 26]
+\f
+Internet-Draft        draft-kerr-avt-theora-rtp-00          January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 27]
+\f
diff --git a/doc/draft-kerr-avt-theora-rtp-00.xml b/doc/draft-kerr-avt-theora-rtp-00.xml
new file mode 100644 (file)
index 0000000..dff7a26
--- /dev/null
@@ -0,0 +1,1277 @@
+<?xml version='1.0'?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
+<?rfc toc="yes" ?>
+<?rfc compact='yes'?>
+
+<rfc ipr="full3667" docName="RTP Payload Format for Theora Encoded Video">
+
+<front>
+<title>draft-kerr-avt-theora-rtp-00</title>
+
+<author initials="P" surname="Kerr" fullname="Phil Kerr">
+<organization>Xiph.Org</organization>
+<address>
+<email>phil@plus24.com</email>
+<uri>http://www.xiph.org/</uri>
+</address>
+</author>
+
+<date day="31" month="January" year="2005" />
+
+<area>General</area>
+<workgroup>AVT Working Group</workgroup>
+<keyword>I-D</keyword>
+
+<keyword>Internet-Draft</keyword>
+<keyword>Theora</keyword>
+<keyword>RTP</keyword>
+
+<abstract>
+<t>
+This document describes a RTP payload format for transporting Theora encoded video.  It details the RTP encapsulation mechanism 
+for raw Theora data and configuration headers consisting of the quantization matrices and the Huffman codebooks for the DCT 
+coefficients, and a table of limit values for the deblocking filter.
+</t>
+
+<t>
+Also included within the document are the necessary details for the use of Theora with MIME and Session Description Protocol 
+(SDP).
+</t>
+
+</abstract>
+
+<note title="Editors Note">
+<t>
+All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
+</t>
+</note>
+
+</front>
+
+<middle>
+
+<section anchor="Introduction" title="Introduction">
+<t>
+Theora is a general purpose, lossy video codec. It is based on the VP3.1 video codec produced by On2 Technologies and has been donated to the Xiph.org Foundation.  
+</t>
+
+<t>
+Theora I is a block-based lossy transform codec that utilizes an 8 x 8 Type-II Discrete Cosine Transform and block-based motion 
+compensation.  This places it in the same class of codecs as MPEG-1, MPEG-2, MPEG-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). 
+</t>
+
+<t>
+Theora provides none of its own framing, synchronization, or protection against transmission errors.  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 <xref target="rfc3533"></xref>. or RTP/AVP <xref target="rfc3550"></xref>. 
+</t>
+
+<t>
+Theora I currently supports progressive video data of arbitrary dimensions at a constant frame rate in one of several YCbCr color 
+spaces. 
+Three different chroma subsampling formats are supported: 4:2:0, 4:2:2, and 4:4:4.  The Theora I 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.
+</t>
+
+<t>
+Theora is similar to Vorbis audio <xref target="vorbisrtp"></xref> in that it requires the inclusion of the entire probability 
+model for the DCT coefficients and all the quantization parameters in the bitstream headers to be sent ahead of the video data.  It 
+is therefore impossible to decode any frame in the stream without having previously fetched the codec info and codec setup headers, 
+although Theora can initiate decode at an arbitrary intra-frame packet within a bitstream so long as the codec has been initialized 
+with the setup headers.
+</t>
+
+<section anchor="Terminology" title="Terminology">
+
+<t>
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
+and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
+</t>
+
+</section>
+</section>
+
+<section anchor="Payload Format" title="Payload Format">
+
+<t>
+Each frame of digital video is packetized into one or more RTP packets.  If the data for a complete frame exceeds the network
+MTU, it SHOULD be fragmented into multiple RTP packets, each smaller than the MTU.   A single RTP packet MAY contain 
+data for more than one Theora frame. 
+</t>
+
+<t>
+For RTP based transportation of Theora encoded video the standard RTP header is followed by a 5 octet payload header, then the 
+payload data.  
+</t>
+
+<section anchor="RTP Header" title="RTP Header">
+
+<t>
+The format of the RTP header is specified in <xref target="rfc3550"></xref> and shown in Figure 1.  This payload format uses 
+the fields of the header in a manner consistent with that specification. 
+</t>
+
+<figure anchor="RTP Header Figure" title="RTP Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           timestamp                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see <xref target="rfc3550">
+</xref> and <xref target="rfc3551"></xref> for details). For Theora RTP, the following values are used.
+</t>
+
+<t>
+Version (V): 2 bits</t><t>
+This field identifies the version of RTP. The version used by this specification is two (2).
+</t>
+
+<t>
+Padding (P): 1 bit</t><t>
+Padding MAY be used with this payload format according to section 5.1 of <xref target="rfc3550"></xref>.  
+</t>
+
+<t>
+Extension (X): 1 bit</t><t>
+The Extension bit is used in accordance with <xref target="rfc3550"></xref>. 
+</t>
+
+<t>
+CSRC count (CC): 4 bits</t><t>
+The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Marker (M): 1 bit</t><t>
+The Marker bit is used in accordance with <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Payload Type (PT): 7 bits</t><t>
+An RTP profile for a class of applications is expected to assign a payload type for this format, or a dynamically allocated 
+payload type SHOULD be chosen which designates the payload as Theora.
+</t>
+
+<t>
+Sequence number: 16 bits</t><t>
+The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and
+to restore packet sequence. This field is detailed further in <xref target="rfc3550"></xref>.
+</t>
+
+<t>
+Timestamp: 32 bits</t><t>
+A timestamp representing the sampling time of the first sample of the first Theora packet in the RTP packet.  The clock frequency 
+MUST be set to the sample rate of the encoded video data and is conveyed out-of-band as an SDP attribute.
+</t>
+
+<t>
+SSRC/CSRC identifiers: </t><t>
+These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in 
+<xref target="rfc3550"></xref>.  
+</t>
+
+</section>
+
+<section anchor="Payload Header" title="Payload Header">
+
+<t>
+After the RTP Header section the following five octets are the Payload Header.  
+This header is split into a number of bitfields detailing the format of the following Payload Data packets.
+</t>
+
+<figure anchor="Payload Header Figure" title="Payload Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |C|F|0|0|# pkts.|
+   +-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+Setup Header Ident: 32 bits</t>
+<t>
+This 32 bit field is used to associate the Theora data to a decoding Setup Header. It is created by making a CRC32 checksum 
+of the Setup Header required to decode the particular Theora video stream.
+</t>
+
+<t>
+Continuation (C): 1 bit</t>
+<t>
+Set to one if this is a continuation of a fragmented packet.
+</t>
+
+<t>
+Fragmented (F): 1 bit</t>
+<t>
+Set to one if the payload contains complete packets or if it contains the last fragment of a fragmented packet. 
+</t>
+
+<t>
+The next two bits are currently reserved and MUST be set to 0.
+</t>
+
+<t>
+The last 4 bits are the number of complete packets in this payload.  This provides for a maximum number of 15 Theora 
+packets in the payload.  If the packet contains fragmented data the number of packets MUST be set to 0.
+</t>
+
+</section>
+
+<section anchor="Payload Data" title="Payload Data">
+
+<t>
+Each Theora payload section starts with a three octet header.  The first octet is used to denote what kind of Theora data follows.  
+Then a two octet length header is used to represent the size of the following data payload, followed by the raw Theora data.
+</t>
+
+<figure anchor="Payload Data Figure" title="Payload Data">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Data type   |        Payload Length         | Theora Data  ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The data type octet is used to signify the payload data type.  If the first bit is set to 0, this indicates the payload is 
+Theora video data.
+</t>
+
+<t>
+The following values for the Theora payload type are valid:
+</t>
+<vspace blankLines="1" />
+<list style="empty">
+<t>      0 = Raw Theora data</t>
+<t>      0x80 = Theora Identification header</t>
+<t>      0x81 = Theora Comment header</t>
+<t>      0x82 = Theora Setup header</t>
+</list>
+<vspace blankLines="1" />
+
+<t>
+The Theora packet length header is the length of the Theora data block only and does not count the length octets and payload 
+data type octet.
+</t>
+
+<t>
+The Theora codec uses relatively unstructured raw packets containing binary integer fields of arbitrary width that often do not fall on an octet boundary.  When this happens the bitstream is packed to an octet boundary.  When a Theora encoder produces packets 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 zeros.
+</t>
+
+<t>
+For payloads which consist of multiple Theora packets the payload data consists of the data type field, the payload length field 
+followed by the payload data for each of the Theora packets in the payload.
+</t>
+
+</section>
+
+<section anchor="Example RTP Packet" title="Example RTP Packet">
+
+<t>
+Here is an example RTP packet containing two Theora packets.
+</t>
+<t>
+RTP Packet Header:
+</t>
+
+<figure anchor="Example RTP Packet Figure" title="Example RTP Packet">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | 2 |0|0|  0    |0|      PT     |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 timestamp (in sample rate units)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          synchronisation source (SSRC) identifier             |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+
+<t>
+Payload Data:
+</t>
+
+<figure anchor="Example Theora Payload Figure" title="Example Theora Payload Packet">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|1|0|0| 2 pks |      0x80     |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..    data      |        0      |        Payload Length        ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Theora data                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The payload portion of the packet starts with the 32 bit Setup Header ident field followed by the 8 bit fragment/count fields.  The F 
+bit is set to 1, indicating that this packet contains whole Theora frame data.  The number of whole Theora data packets is set to 
+2.  
+</t>
+
+<t>
+Each of the payload blocks starts with a Data type field, for the first payload this is set to 0x80 indicating it is an 
+Identification header and the second payload is set to 0 indicating it is raw Theora data.  Then the two octet length field is 
+followed by the variable length Theora data.
+</t>
+
+</section>
+</section>
+
+
+<section anchor="Frame Packetizing" title="Frame Packetizing">
+
+<t>
+Each RTP packet contains either one complete Theora packet, one Theora packet fragment, or an integer number of complete Theora 
+packets (up to a max of 15 packets, since the number of packets is defined by a 4 bit value).
+</t>
+
+<t>
+Any Theora data packet that is less than path MTU SHOULD be bundled in the RTP packet with as many Theora packets as will 
+fit, up to a maximum of 15.  Path MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
+</t>
+
+<t>
+If a Theora packet is larger than 65535 octets it MUST be fragmented.  A fragmented packet has a zero in the last four bits 
+of the payload header.  Each fragment after the first will also set the Continued (C) bit to one in the payload header.  The 
+RTP packet containing the last fragment of the Theora packet will have the Fragmented (F) bit set to one.  To maintain the 
+correct sequence for fragmented packet reception the timestamp field of fragmented packets MUST be the same as the first 
+packet sent, with the sequence number incremented as normal for the subsequent RTP packets.
+</t>
+
+<section anchor="Example Fragmented Theora Packet" title="Example Fragmented Theora Packet">
+
+<t>
+Here is an example fragmented Theora packet split over three RTP packets.  Each packet contains the standard RTP headers as 
+well as the 5 octet Theora headers.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
+<artwork><![CDATA[
+   Packet 1:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1000                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|0|0|0|      0|       0       |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+In this packet the initial sequence number is 1000 and the timestamp is xxxxx.  The Continuation (C) bit is set to one, 
+indicating it is not the continuation of a fragmented bit, and the Fragmentation (F) is set to 0 indicating it is a fragmented 
+packet.  The number of packets field is set to 0, and as the payload is raw Theora data the Theora payload type field is set to 0.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
+<artwork><![CDATA[
+   Packet 2:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1001                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1|0|0|0|      0|       0       |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The C bit is set to 1 and the number of packets field is set to 0.  For large Theora fragments there can be several of these type 
+of payload packets.  The maximum packet size SHOULD be no greater than the path MTU, including all RTP and payload headers.  The 
+sequence number has been incremented by one but the timestamp field remains the same as the initial packet.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
+<artwork><![CDATA[
+   Packet 3:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |           1002                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1|1|0|0|      0|       0       |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Theora data                          ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+This is the last Theora fragment packet.  The C and F bits are set and the packet count remains set to 0.  As in the previous 
+packets the timestamp remains set to the first packet in the sequence and the sequence number has been incremented.
+</t>
+
+</section>
+</section>
+
+
+<section anchor="Packet Loss" title="Packet Loss">
+
+<t>
+As there is no error correction within the Theora stream, packet loss will result in a loss of signal.  Packet loss is more of an 
+issue for fragmented Theora packets as the client will have to cope with the handling of the C and F flags.  If we use the 
+fragmented Theora packet example above and the first packet is lost the client SHOULD detect that the next packet has the packet
+count field set to 0 and the C bit is set and MUST drop it.  The next packet, which is the final fragmented packet, SHOULD 
+be dropped in the same manner, or buffered.  Feedback reports on lost and dropped packets MUST be sent back via RTCP.
+</t>
+
+<t>
+If a particular multicast session has a large number of participants care must be taken to prevent an RTCP feedback implosion, 
+<xref target="rtcp-feedback"></xref>, in the event of packet loss from a large number of participants.
+</t>
+
+</section>
+
+<section anchor="Configuration Headers" title="Configuration Headers">
+
+<t>
+To decode a Theora stream three configuration header blocks are needed.  The first header, the Identification Header, indicates 
+the frame dimensions, quality, blocks used and the version of the Theora encoder used.  The second header, the Comment Header, contains stream metadata and the third header, the Setup Header, details which contains dequantization and Huffman tables.
+</t>
+
+<t>
+As the RTP stream may change certain configuration data mid-session there are two different methods for delivering this 
+configuration data to a client, in-band and SDP which is detailed below.  SDP delivery is used to set-up an initial
+state for the client application and in-band is used to change state during the session.  The changes may be due to 
+different metadata or Setup Header as well as different bitrates of the stream.
+</t>
+
+<t>
+Out of the two delivery vectors the use of an SDP attribute to indicate an URI where the configuration and Setup Header data 
+can be obtained is preferred as they can be fetched reliably using TCP.  The in-band Setup Header delivery SHOULD 
+only be used in situations where the link between the client is unidirectional or if the SDP-based information is not available. 
+</t>
+
+<t>
+Synchronizing the configuration and Setup Header to the RTP stream is critical.  The 32 bit Setup Header Ident field is used 
+to indicate when a change in the stream has taken place.  The client application MUST have in advance the correct configuration 
+and Setup Headers and if the client detects a change in the Ident value and does not have this information it MUST NOT 
+decode the raw Theora data.
+</t>
+
+<section anchor="In-band Header Transmission" title="In-band Header Transmission">
+
+<t>
+The three header data blocks are sent in-band with the packet type bits set to match the payload type.  Normally the Setup Header 
+and Identification Header are sent once per session if the stream is an encoding of live video, as typically 
+the encoder state will not change, but the encoder state can change at the boundary of chained Theora video files.  Metadata 
+can be sent at the start as well as any time during the life of the session.  Clients MUST be capable of dealing with periodic 
+re-transmission of the configuration headers.
+</t>
+
+<section anchor="Identification Header" title="Identification Header">
+
+<t>
+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.</t>
+
+<figure anchor="Identification Header Figure" title="Identification Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|1|0|0|      1|     0x80      |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     VMAJ      |     VMIN      |     VREV      |     FMBW      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     FMBW      |              FMBH             |     NSBS      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     NSBS                      |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NBS                             | NMBS  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NMBS                            | PICW  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              PICW             |             PICH              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | PICH  |     PICX      |      PICY     |         FRN           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                FRN                    |         FRD           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                FRD                    |         PARN          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         PARN          |               PARD                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | PARD  |      CS       |PF |             NOMBR                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   NOMBR   |   QUAL    | KFGSHIFT|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The fields listed above have the following meanings:
+</t>
+
+<vspace blankLines="1" />
+<vspace blankLines="1" />
+<list style="empty">
+<t>      VMAJ     = The major version number.  8 bits.</t>
+<t>      VMIN     = The minor version number.  8 bits.</t>
+<t>      VREV     = The version revision number.  8 bits.</t>
+<t>      FMBW     = The width of the frame in macro blocks.  16 bits.</t>
+<t>      FMBH     = The height of the frame in macro blocks.  16 bits.</t>
+<t>      NSBS     = The total number of super blocks in a frame.  32 bits.</t>
+<t>      NBS      = The total number of blocks in a frame.  36 bits.</t>
+<t>      NMBS     = The total number of macro blocks in a frame.  32 bits.</t>
+<t>      PICW     = The width of the picture region in pixels.  20 bits.</t>
+<t>      PICH     = The height of the picture region in pixels.  20 bits.</t>
+<t>      PICX     = The X offset of the picture region in pixels.  8 bits.</t>
+<t>      PICY     = The Y offset of the picture region in pixels.  8 bits.</t>
+<t>      FRN      = The frame-rate numerator.  32 bits.</t>
+<t>      FRD      = The frame-rate denominator.  32 bits.</t>
+<t>      PARN     = The pixel aspect-ratio numerator.  24 bits.</t>
+<t>      PARD     = The pixel aspect-ratio denominator.  24 bits.</t>
+<t>      CS       = The color space.  8 bits.</t>
+<t>      PF       = The pixel format.  2 bits.</t>
+<t>      NOMBR    = The nominal bitrate of the stream, in bits per second.  24 bits.</t>
+<t>      QUAL     = The quality hint.  6 bits.</t>
+<t>      KFGSHIFT = The amount to shift the key frame number by in the granule position.  5 bits.</t>
+</list>
+<vspace blankLines="1" />
+
+</section>
+
+<section anchor="Comment Header" title="Comment Header">
+
+<t>
+The Theora Comment Header is the second of three header packets that begin a Theora stream. It is meant for short text comments, 
+not arbitrary metadata; arbitrary metadata belongs in a separate logical stream that provides greater structure and machine 
+parseability. 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.</t>
+
+
+<figure anchor="Comment Header Figure" title="Comment Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|1|0|0|      1|     0x81      |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    User comments list length                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       User comment length                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          User comment                        ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                         User comment                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+]]></artwork>
+</figure>
+
+<t>
+The format for the data takes the form of a 32 bit field denoting the number of user comments.  Each of the user comments is prefixed by a 32 bit length field followed by the comment text encoded in UTF-8.
+</t>
+
+</section>
+
+<section anchor="Setup Header" title="Setup Header">
+
+<t>
+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.
+</t>
+
+<figure anchor="Setup Header Figure" title="Setup Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |             xxxx              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             xxxxx                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |            contributing source (CSRC) identifiers             |
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|1|0|0|      1|     0x82      |        Payload Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Setup Header Length                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Setup Header                         ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Setup Header                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+
+<section anchor="Setup Header CRC32 Generation" title="Setup Header CRC32 Generation">
+
+<t>
+In order for different implementations of Theora RTP clients and servers to interoperate with each other a common format 
+for the production of the CRC32 hash is required.  The polynomial is X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0.
+</t>
+
+<t>
+The following C code function SHOULD be used by implementations, if not then the code responsible for generating the CRC32 
+value MUST use the polynomial function above.
+</t>
+
+<artwork><![CDATA[
+unsigned int crc32 (int length, unsigned char *crcdata)
+{
+    int index, loop;
+    unsigned int byte, crc, mask;
+    index = 0;
+    crc = 0xFFFFFFFF;
+    while (index < length) {
+        byte = crcdata [index];
+        crc = crc ^ byte;
+        for (loop = 7; loop >= 0; loop--) {
+            mask = -(crc & 1);
+            crc = (crc >> 1) ^ (0xEDB88320 & mask);
+        }
+        index++;
+    }
+    return ~crc;
+}
+]]></artwork>
+
+
+</section>
+
+</section>
+</section>
+
+<section anchor="Packed Headers Delivery" title="Packed Headers Delivery"> 
+
+<t>
+As mentioned above the RECOMMENDED delivery vector for Theora configuration data is via an SDP attribute as this retrieval method 
+can be performed using a reliable transport protocol.  
+</t>
+
+<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
+<artwork><![CDATA[
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Number of packed headers                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packed header                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Packed header                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+As the RTP headers are not required for this method of delivery the 
+structure of the configuration data is slightly different.  The packed header starts with a 32 bit count field which details the number of packed headers that are contained in the bundle.  Next is the packed header payload for each chained Theora file.
+</t>
+
+<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
+<artwork><![CDATA[
+    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 Length                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Setup Header Ident                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Identification Header                    ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                    Identification Header                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Comment Header                       ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Comment Header                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Setup Header                        ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                         Setup Header                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>The key difference between the in-band format is there is no need for the payload header octet and Setup Header Ident field.  
+Below are examples of the packed headers format.
+</t>
+
+<figure anchor="Packed Identification Header Figure" title="Packed Identification Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     VMAJ      |     VMIN      |     VREV      |     FMBW      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     FMBW      |              FMBH             |     NSBS      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     NSBS                      |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NBS                             | NMBS  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NMBS                            | PICW  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              PICW             |             PICH              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | PICH  |     PICX      |      PICY     |         FRN           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                FRN                    |         FRD           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                FRD                    |         PARN          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         PARN          |               PARD                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | PARD  |      CS       |PF |             NOMBR                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   NOMBR   |   QUAL    | KFGSHIFT|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The alignment of the packed Identification Header is slightly different from the RTP payload type as the payload header is not 
+used.
+</t>
+
+<figure anchor="Packed Comment Header Figure" title="Packed Comment Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    User comments list length                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       User comment length                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          User comment                        ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                         User comment                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The packed Comment Header also as a slightly different structure to that of the RTP payload type with the payload header not being 
+used.
+
+</t>
+
+<figure anchor="Packed Setup Header Figure" title="Packed Setup Header">
+<artwork><![CDATA[
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Setup Header Length                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Setup Header                         ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ..                        Setup Header                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The packed Setup Header also has a slightly different structure to that of the RTP payload type.  The Setup Header Ident field 
+that is normally part of this structure is moved to the second field of the overall packed structure.
+</t>
+
+<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations"> 
+
+<t>
+The following IANA considerations MUST only be applied to the packed headers.
+</t>
+
+<t>
+MIME media type name: video
+</t>
+<t>
+MIME subtype: theora-config
+</t>
+
+<t>
+Required Parameters:</t><t>
+None.
+</t>
+
+<t>
+Optional Parameters: </t><t>
+None.
+</t>
+
+<t>
+Encoding considerations:</t><t>
+This type is only defined for transfer via HTTP as specified in RFC XXXX.
+</t>
+
+<t>
+Security Considerations:</t><t>
+See Section 6 of RFC 3047.
+</t>
+
+<t>
+Interoperability considerations: none
+</t>
+
+<t>
+Published specification:</t>
+<t>See RFC XXXX for details.</t>
+
+<t>
+Applications which use this media type:</t><t>
+Theora encoded video, configuration data.
+</t>
+
+<t>
+Additional information: none
+</t>
+
+<t>
+Person &amp; email address to contact for further information:</t><t>
+Phil Kerr: &lt;phil@plus24.com&gt;
+</t>
+
+<t>
+Intended usage: COMMON
+</t>
+
+<t>Author/Change controller:</t>
+<t>Author: Phil Kerr</t>
+<t>Change controller: IETF AVT Working Group</t>
+
+
+</section>
+</section>
+
+<section anchor="Setup Header Caching" title="Setup Header Caching"> 
+
+<t>
+Setup Header caching allows clients that have previously connected to a stream to re-use the associated Setup Header and 
+configuration data.  When a client receives a Setup Header it may store it locally and can compare the CRC32 key with that of the 
+new stream and begin decoding before it has received any of the headers.
+</t>   
+
+</section>
+
+<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers"> 
+
+<t>
+Unlike the loss of raw Theora payload data, loss of a configuration header can lead to a situation where it will not be possible 
+to successfully decode the stream.  
+</t>
+
+<t>
+Out of the three headers, loss of either the Setup Header or Identification Headers MUST result in the halting of stream 
+decoding.  Loss of the Comment header SHOULD NOT be regarded as fatal for decoding.  Loss of any of the headers SHOULD be reported 
+to the client as well as a loss report sent via RTCP.
+</t>
+
+</section>
+</section>
+
+
+<section anchor="IANA Considerations" title="IANA Considerations"> 
+
+<t>MIME media type name: video</t>
+
+<t>MIME subtype: theora</t>
+
+<t>Required Parameters:</t>
+
+<t>
+sampling: Determines the chroma subsampling format.
+</t>
+<t>
+width: Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+</t>
+<t>
+height: Determines the number of lines per frame. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+</t>
+<t>
+header: Indicates the URI of the decoding configuration headers.
+</t>
+
+<t>
+Optional Parameters: </t><t>
+None.
+</t>
+
+<t>
+Encoding considerations:</t><t>
+This type is only defined for transfer via RTP as specified in RFC XXXX.
+</t>
+
+<t>
+Security Considerations:</t><t>
+See Section 6 of RFC 3047.
+</t>
+
+<t>
+Interoperability considerations: none
+</t>
+
+<t>
+Published specification:</t>
+<t>See the Theora documentation <xref target="Theora-spec-ref"></xref> for details.</t>
+
+<t>
+Applications which use this media type:</t><t>
+Video streaming and conferencing tools
+</t>
+
+<t>
+Additional information: none
+</t>
+
+<t>
+Person &amp; email address to contact for further information:</t><t>
+Phil Kerr: &lt;phil@plus24.com&gt;
+</t>
+
+<t>
+Intended usage: COMMON
+</t>
+
+<t>Author/Change controller:</t>
+<t>Author: Phil Kerr</t>
+<t>Change controller: IETF AVT Working Group</t>
+
+<section anchor="Mapping MIME Parameters into SDP" title="Mapping MIME Parameters into SDP"> 
+
+<t>
+The information carried in the MIME media type specification has a specific mapping to fields in the Session Description 
+Protocol (SDP) <xref target="rfc2327"></xref>, which is commonly used to describe RTP sessions.  When SDP is used to specify 
+sessions the mapping are as follows:
+</t>
+
+<vspace blankLines="1" />
+<list style="symbols">
+
+<t>The MIME type ("video") goes in SDP "m=" as the media name.</t>
+<vspace blankLines="1" />
+
+<t>The MIME subtype ("THEORA") goes in SDP "a=rtpmap" as the encoding name.</t>
+<vspace blankLines="1" />
+
+<t>The parameter "rate" also goes in "a=rtpmap" as clock rate.</t>
+<vspace blankLines="1" />
+
+<t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
+<vspace blankLines="1" />
+
+<t>The parameter "header" goes in the SDP "a=fmpt" attribute.</t>
+</list>
+
+
+<t>
+If the stream comprises chained Theora files the configuration and Setup Headers for each file SHOULD be packaged together 
+and passed to the client using the headers attribute if all the files to be played are known in advance.  
+</t>
+
+
+<t>Example:</t>
+
+<vspace blankLines="1" />
+
+<list style="empty">
+<t>c=IN IP4/6 </t>
+<t>m=video  RTP/AVP 98</t>
+<t>a=rtpmap:98 theora/90000</t>
+<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; header=&lt;URI of configuration header&gt;</t>
+</list>
+
+</section> 
+</section>
+
+
+<!--section anchor="IANA Considerations old" title="IANA Considerations old"> 
+
+<t>MIME media type name: video</t>
+
+<t>MIME subtype: theora</t>
+
+<t>Required Parameters:</t>
+
+<t>
+sampling: Determines the chroma subsampling format.
+</t>
+<t>
+width: Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+</t>
+<t>
+height: Determines the number of lines per frame. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+</t>
+<t>
+header: Indicates the URI of the decoding configuration headers.
+</t>
+
+<t>
+Optional Parameters: </t><t>
+None.
+</t>
+
+<t>
+Encoding considerations:</t><t>
+This type is only defined for transfer via RTP as specified in RFC XXXX.
+</t>
+
+<t>
+Security Considerations:</t><t>
+See Section 6 of RFC 3047.
+</t>
+
+<t>
+Interoperability considerations: none
+</t>
+
+<t>
+Published specification:</t>
+<t>See the Theora documentation <xref target="Theora-spec-ref"></xref> for details.</t>
+
+<t>
+Applications which use this media type:</t><t>
+video streaming and conferencing tools
+</t>
+
+<t>
+Additional information: none
+</t>
+
+<t>
+Person &amp; email address to contact for further information:</t><t>
+Phil Kerr: &lt;phil@plus24.com&gt;
+</t>
+
+<t>
+Intended usage: COMMON
+</t>
+
+<t>Author/Change controller:</t>
+<t>Author: Phil Kerr</t>
+<t>Change controller: IETF AVT Working Group</t>
+
+</section-->
+
+<section anchor="Security Considerations" title="Security Considerations"> 
+<t>
+RTP packets using this payload format are subject to the security considerations discussed in the RTP specification 
+<xref target="rfc3550"></xref>.  This implies that the confidentiality of the media stream is achieved by using
+encryption.  Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the 
+compressed data.  Where the size of a data block is set care MUST be taken to prevent buffer overflows in the client applications.
+</t>
+
+</section> 
+
+<section anchor="Acknowledgments" title="Acknowledgments"> 
+
+<t>
+Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph Giles.
+</t>
+
+</section> 
+
+</middle>
+
+<back>
+
+<references title="Normative References">
+
+<reference anchor="rfc3533">
+<front>
+<title>The Ogg Encapsulation Format Version 0</title>
+<author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"></author>
+</front>
+<seriesInfo name="RFC" value="3533" />
+</reference>
+
+<reference anchor="rfc2119">
+<front>
+<title>Key words for use in RFCs to Indicate Requirement Levels </title>
+<author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
+</front>
+<seriesInfo name="RFC" value="2119" />
+</reference>   
+
+<reference anchor="rfc3550">
+<front>
+<title>RTP: A Transport Protocol for real-time applications</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+<author initials="R." surname="Frederick" fullname=""></author>
+<author initials="V." surname="Jacobson" fullname=""></author>
+</fron